OpenSSH 5.9 released [LWN.net]

From:		Damien Miller <djm-AT-cvs.openbsd.org>
To:		lwn-AT-lwn.net
Subject:		Announce: OpenSSH 5.9 released
Date:		Mon, 5 Sep 2011 23:29:50 -0600 (MDT)
Message-ID:		<201109060529.p865ToNN021625@cvs.openbsd.org>
Archive-link:		Article, Thread

OpenSSH 5.9 has just been released. It will be available from the
mirrors listed at http://www.openssh.com/ shortly.

OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
implementation and includes sftp client and server support.

Once again, we would like to thank the OpenSSH community for their
continued support of the project, especially those who contributed
code or patches, reported bugs, tested snapshots or donated to the
project. More information on donations may be found at:
http://www.openssh.com/donations.html

Changes since OpenSSH 5.8
=========================

Features:

 * Introduce sandboxing of the pre-auth privsep child using an optional
   sshd_config(5) "UsePrivilegeSeparation=sandbox" mode that enables
   mandatory restrictions on the syscalls the privsep child can perform.
   This intention is to prevent a compromised privsep child from being
   used to attack other hosts (by opening sockets and proxying) or
   probing local kernel attack surface.
    
   Three concrete sandbox implementation are provided (selected at
   configure time): systrace, seatbelt and rlimit.

   The systrace sandbox uses systrace(4) in unsupervised "fast-path"
   mode, where a list of permitted syscalls is supplied. Any syscall not
   on the list results in SIGKILL being sent to the privsep child. Note
   that this requires a kernel with the new SYSTR_POLICY_KILL option
   (only OpenBSD has this mode at present).
 
   The seatbelt sandbox uses OS X/Darwin sandbox(7) facilities with a
   strict (kSBXProfilePureComputation) policy that disables access to
   filesystem and network resources.

   The rlimit sandbox is a fallback choice for platforms that don't
   support a better one; it uses setrlimit() to reset the hard-limit
   of file descriptors and processes to zero, which should prevent
   the privsep child from forking or opening new network connections.

   Sandboxing of the privilege separated child process is currently
   experimental but should become the default in a future release.
   Native sandboxes for other platforms are welcome (e.g. Capsicum,
   Linux pid/net namespaces, etc.)

 * Add new SHA256-based HMAC transport integrity modes from
   http://www.ietf.org/id/draft-dbider-sha2-mac-for-ssh-02.txt
   These modes are hmac-sha2-256, hmac-sha2-256-96, hmac-sha2-512,
   and hmac-sha2-512-96, and are available by default in ssh(1) and
   sshd(8)

 * The pre-authentication sshd(8) privilege separation slave process
   now logs via a socket shared with the master process, avoiding the
   need to maintain /dev/log inside the chroot.

 * ssh(1) now warns when a server refuses X11 forwarding

 * sshd_config(5)'s AuthorizedKeysFile now accepts multiple paths,
   separated by whitespace. The undocumented AuthorizedKeysFile2
   option is deprecated (though the default for AuthorizedKeysFile
   includes .ssh/authorized_keys2)

 * sshd_config(5): similarly deprecate UserKnownHostsFile2 and
   GlobalKnownHostsFile2 by making UserKnownHostsFile and
   GlobalKnownHostsFile accept multiple options and default to
   include known_hosts2

 * Retain key comments when loading v.2 keys. These will be visible
   in "ssh-add -l" and other places. bz#439

 * ssh(1) and sshd(8): set IPv6 traffic class from IPQoS (as well as
   IPv4 ToS/DSCP). bz#1855

 * ssh_config(5)'s ControlPath option now expands %L to the host
   portion of the destination host name.

 * ssh_config(5) "Host" options now support negated Host matching, e.g.
     
     Host *.example.org !c.example.org
        User mekmitasdigoat
     
   Will match "a.example.org", "b.example.org", but not "c.example.org"

 * ssh_config(5): a new RequestTTY option provides control over when a
   TTY is requested for a connection, similar to the existing -t/-tt/-T
   ssh(1) commandline options.

 * sshd(8): allow GSSAPI authentication to detect when a server-side
   failure causes authentication failure and don't count such failures
   against MaxAuthTries; bz#1244

 * ssh-keygen(1): Add -A option. For each of the key types (rsa1, rsa,
   dsa and ecdsa) for which host keys do not exist, generate the host
   keys with the default key file path, an empty passphrase, default
   bits for the key type, and default comment. This is useful for
   system initialisation scripts.

 * ssh(1): Allow graceful shutdown of multiplexing: request that a mux
   server removes its listener socket and refuse future multiplexing
   requests but don't kill existing connections. This may be requested
   using "ssh -O stop ..."

 * ssh-add(1) now accepts keys piped from standard input. E.g.
   "ssh-add - < /path/to/key"
 
 * ssh-keysign(8) now signs hostbased authentication
   challenges correctly using ECDSA keys; bz#1858

 * sftp(1): document that sftp accepts square brackets to delimit
   addresses (useful for IPv6); bz#1847a

 * ssh(1): when using session multiplexing, the master process will
   change its process title to reflect the control path in use and
   when a ControlPersist-ed master is waiting to close; bz#1883 and
   bz#1911

 * Other minor bugs fixed: 1849 1861 1862 1869 1875 1878 1879 1892
   1900 1905 1913

Portable OpenSSH Bugfixes:

 * Fix a compilation error in the SELinux support code. bz#1851

 * This release removes support for ssh-rand-helper. OpenSSH now
   obtains its random numbers directly from OpenSSL or from
   a PRNGd/EGD instance specified at configure time.

 * sshd(8) now resets the SELinux process execution context before
   executing passwd for password changes; bz#1891

 * Since gcc >= 4.x ignores all -Wno-options options, test only the
   corresponding -W-option when trying to determine whether it is
   accepted; bz#1901

 * Add ECDSA key generation to the Cygwin ssh-{host,user}-config
   scripts.

 * Updated .spec and init files for Linux; bz#1920

 * Improved SELinux error messages in context change failures and
   suppress error messages when attempting to change from the
   "unconfined_t" type; bz#1924 bz#1919

 * Fix build errors on platforms without dlopen(); bz#1929

Checksums:
==========

 - SHA1 (openssh-5.9.tar.gz) = bc0cb728bbc394769f9a2ce5b8cd99dc41e12632
 - SHA1 (openssh-5.9p1.tar.gz) = be8878869bb80ce12ca79282768ffa73cc3f05fc

Reporting Bugs:
===============

- Please read http://www.openssh.com/report.html
  Security bugs should be reported directly to openssh@openssh.com

OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt,
Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and
Ben Lindstrom.

(Log in to post comments)

OpenSSH 5.9 released

Posted Sep 6, 2011 14:24 UTC (Tue) by rvfh (subscriber, #31018) [Link]

Which leads to the question: should this sandboxing really be dealt with at application level, or should it be a global framework's job?

OpenSSH 5.9 released

Posted Sep 6, 2011 15:17 UTC (Tue) by butlerm (subscriber, #13312) [Link]

>Which leads to the question: should this sandboxing really be dealt with at application level, or should it be a global framework's job?

Who knows better what an application process shouldn't be allowed to do under any circumstances than the application developer? There is no safe way to delegate that job away. You can protect an application from other applications, but not from itself.

OpenSSH 5.9 released

Posted Sep 6, 2011 17:22 UTC (Tue) by iabervon (subscriber, #722) [Link]

The system administrator probably knows better; the application developer knows what it needs to be able to do in order to work, and what it could provide additional functionality if it were able to do, but doesn't know system policy or local security mechanisms. (For that matter, an application that links against PAM may not have a static policy which would be acceptable on all systems; the question of whether it should be allowed to read /etc/shadow depends on configuration.) An application developer can declare that certain operations won't be performed in the course of ordinary operation, and an attempt to perform them indicates that the application has been subverted in some way, but it is rarely the case that an application can really restrict itself to a degree that it would be okay if it did absolutely anything that it was still able to do.

For that matter, the purpose of this application is to authenticate a user; an attacker who subverts it inside the sandbox can presumably get it to allow access, log in as the system administrator, and take control of the account.

OpenSSH 5.9 released

Posted Sep 6, 2011 17:48 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

It may be trickier than that, depending on how exactly OpenSSH is designed. It's certainly conceivable that authentication is never used unless OpenSSH has determined that it's possible it would allow a login. So if root logins are forbidden anyway, maybe subverting the authentication step doesn't help you become root, it just means you can become any ordinary user of your choice.

Of course there's an excellent chance that such sophisticated bad guys know a user escalation on the target system that will work once they get a shell, but defence in depth is what it's all about, if we kept them from instantly becoming root we may have bought ourselves a little more time to notice something is wrong, or forced them to take steps that are traceable in the logs [ here we assume the logs are somehow immutable, either there's a physical line printer somewhere with reams of paper, or a remote machine managed separately ]

OpenSSH 5.9 released

Posted Sep 7, 2011 12:56 UTC (Wed) by vonbrand (subscriber, #4458) [Link]

Sorry, but "sysadmin knows best" is nonsense. The usually too thinly spread sysadmin mostly has no clue on security (seen with the reflex "disable SELinux" on any minor problem, and even much more troubling sledgehammer "solutions" I've witnessed), and even when they have a clue, they mostly don't have the detailed knowledge and expertise to make the right call. A strong default must be in place, if the sysadmin can tweak it sensibly much the better.

OpenSSH 5.9 released

Posted Sep 7, 2011 15:44 UTC (Wed) by iabervon (subscriber, #722) [Link]

Individual administrators of systems tend not to know much, but the distinction I'm making is between "system" and "application", and I think that the best security that most installations get is from distros, which I would consider to be on the "system" side. In general, whoever configures PAM on the system ought to be writing the rules for openssh's capabilities.

OpenSSH 5.9 released

Posted Sep 7, 2011 20:50 UTC (Wed) by nix (subscriber, #2304) [Link]

Yeah, because they've audited SSH's source code and know exactly which syscalls it should be making under normal circumstances -- sorry, no, which syscalls its *privileged half* should be making under normal circumstances.

Sorry, but that's ridiculous. If the OpenSSH package maintainer knows this, you have a better OpenSSH package maintainer than 99% of distros (and probably one in need of therapy). Worse yet, it is a continuing maintenance burden, because the set of syscalls made may change at any time.

The only way this could be practical is if the OpenSSH developers themselves track the set of syscalls the privileged half of the process can make, and keep a list updated -- but if they're doing that, they might as well have the list be automatically enforced as well, which means not leaving it to the distro vendors to add it to SELinux rules or whatever. (Can SELinux even *do* syscall-by-syscall enforcement? I didn't think it could.)

OpenSSH 5.9 released

Posted Sep 7, 2011 21:44 UTC (Wed) by iabervon (subscriber, #722) [Link]

SSH's source code is entirely irrelevant, and auditing it is misguided in this case. They should determine what syscalls the system ought to make available for the purpose of performing authentication, and allow only those. The question of whether SSH uses mmap or read or pread or whatever in a particular version shouldn't affect the policy of what it ought to be allowed to do, which should be based exclusively on the intended function of SSH in the system, and not on implementation details.

Any SSH implementation shouldn't need to use ioctl or dnotify. It should only need to open certain filename patterns. Assuming hardware authentication tokens are managed by a separate task, it shouldn't need to open any devices aside from having ttys allocated to it. The authentication code should only need to do what the distro's PAM configuration expects to do (and, if a particular system have a different PAM configuration, it needs the policy to correspond; not so much to the PAM code, but to the configuration).

You're not going to catch any attacks based on flagging the fact that the process is doing something that is reasonable but that it never happened to do while running in warn mode. You're much more likely to identify problems by noticing that it actually does something (even in normal operation) that you wouldn't expect it to do. And if dropbear and openssh don't have identical policies, you should be very suspicious that either one is overfitting or the other is allowing something inappropriate.

OpenSSH 5.9 released

Posted Sep 7, 2011 22:07 UTC (Wed) by iabervon (subscriber, #722) [Link]

I should mention that this is very much related to the idea that comments in your code should never say what your code does. They should always say what your code is supposed to do, and they should very much ignore what it actually does. (In extreme cases, you might include an argument that what it actually does is equivalent to what it's supposed to do.) The code itself already says what it actually does, and it may have bugs; the last thing you want is to copy the bugs into the documentation. Likewise, if there's a bug in your service, you don't want your security policy to accept it just because that's what the code does; you should say, "This code does something the documentation doesn't suggest that it does, why is that?"

OpenSSH 5.9 released

Posted Sep 8, 2011 0:51 UTC (Thu) by nix (subscriber, #2304) [Link]

SSH's source code is entirely irrelevant, and auditing it is misguided in this case. They should determine what syscalls the system ought to make available for the purpose of performing authentication, and allow only those. The question of whether SSH uses mmap or read or pread or whatever in a particular version shouldn't affect the policy of what it ought to be allowed to do, which should be based exclusively on the intended function of SSH in the system, and not on implementation details.

That's not at all practical if you want your SSH daemon to actually work.

OpenSSH 5.9 released

Posted Sep 8, 2011 2:22 UTC (Thu) by geofft (subscriber, #59789) [Link]

> Any SSH implementation shouldn't need to use ioctl

TIOCGWINSZ seems useful, for instance. I'm sure it uses FIONREAD in a few places.

I recommend trying to sandbox any SSH implementation at all in this way and seeing how well it works and how much work it takes to get a usable implementation before making claims that it is sandboxable as such. (If it were that easy, we would have done it.)

I did a quick test of xpdf's ability to be sandboxed in this way a while back; it's an easy test. See http://geofft.mit.edu/blog/sipb/24 for my results. I've changed my conclusions since, and decided that pure syscall restrictions aren't actually practical.

OpenSSH 5.9 released

Posted Sep 8, 2011 9:45 UTC (Thu) by renox (subscriber, #23785) [Link]

Could you elaborate?
It's quite confusing when you say something in your blog and say that you changed your mind without explanation: we're not mind-readers you know..

OpenSSH 5.9 released

Posted Sep 8, 2011 13:45 UTC (Thu) by butlerm (subscriber, #13312) [Link]

Perhaps the dynamic linker should have an option that disables all syscalls that aren't present on first load. That ought to work for anything that doesn't use dlopen.

OpenSSH 5.9 released

Posted Sep 8, 2011 22:12 UTC (Thu) by nix (subscriber, #2304) [Link]

Um, what does 'an option that disables all syscalls that aren't present on first load' mean? The dynamic linker has no idea what syscalls a process may need to use, nor can I see any way (without an ABI addition) for it to work this out.

OpenSSH 5.9 released

Posted Sep 6, 2011 18:03 UTC (Tue) by cmccabe (guest, #60281) [Link]

False dichotomy. Sandboxing should be done both at the application level and at the framework level.

As a rule, it's generally best to push all the application-specific stuff into the application itself. This minimizes the amount of wheel-reinvention going on between various different Linux distributions. But of course, there are always going to be a few things that really are distro specific and that need to be dealt with by SELinux or a similar framework.

OpenSSH 5.9 released

Posted Sep 6, 2011 14:43 UTC (Tue) by nix (subscriber, #2304) [Link]

Only if you're using SELinux. A lot of distros and others aren't.

OpenSSH 5.9 released

Posted Sep 6, 2011 16:50 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

AppArmor can't provide a sandbox for this?

-jef