Unixy on the fruity side

Fixing OpenSSH CVE-2016-0777, CVE-2016-0778 on OS X

CVE-2016-0777/CVE-2016-0778 affects all OpenSSH clients since 5.4 up to, and including, 7.1. This means that the Apple provided SSH of the following OS X releases is vulnerable:

  • OS X 10.7 (Lion): OpenSSH_5.6p1, OpenSSL 0.9.8za 5 Jun 2014
  • OS X 10.8 (Mountain Lion): OpenSSH_5.9p1, OpenSSL 0.9.8zc 15 Oct 2014
  • OS X 10.9 (Mavericks): OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
  • OS X 10.10 (Yosemite): OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
  • OX X 10.11 (El Capitan): OpenSSH_6.9p1, LibreSSL 2.1.7

You can easily check if you’re running an Apple provided, vulnerable version of OpenSSH by issuing the following command in a terminal. This checks the Apple provided OpenSSH binary!

/usr/bin/ssh -V

On OS X Yosemite you’ll get an output like this.

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011

Beware that you might not be using the Apple provided ssh(1) but a self-compiled one, like from fink, MacPorts or Homebrew for your client connections. This applies to all OS X Versions, even ancient ones on PowerPC.

To check which ssh(1) your shell is using use:

type ssh

I use the MacPorts provided SSH package which gives me this output:

ssh is /opt/local/bin/ssh

Until an update for a patched package is provided, I get this version string.

OpenSSH_7.1p1, OpenSSL 1.0.2e 3 Dec 2015

There is now an updated package which also includes the +hpn variant which will give you this version string.

OpenSSH_7.1p2, OpenSSL 1.0.2e 3 Dec 2015

Changing all your ssh_config files is still recommended, even if you have an updated OpenSSH package on your system since the Apple provided OpenSSH may not get an update for a long time or even at all.

To make sure your system is fully patched you have to apply the fixes to all ssh_config files used by all your ssh(1) binaries.

  • Apple OS X 10.7 - 10.10: /etc/ssh_config
  • Apple OS X 10.11: /etc/ssh/ssh_config
  • MacPorts: /opt/local/etc/ssh/ssh_config
  • HomeBrew: Not sure if this one is correct! /usr/local/etc/ssh/ssh_config
  • Fink: /sw/etc/ssh_config

These are the default locations used by the package managers, your path may differ if you’ve used a different $prefix for installation.

To find out which config file your ssh(1) binary is using, try this command, provided by @teilweise

strings $(which ssh) | grep ssh_config

To fix ssh(1) clients add these two lines to all ssh_config files with your favourite text editor under the general Host * section, or you might miss some hosts.

# Fixing CVE-2016-0777
UseRoaming no

Yes, one is a comment, but in a year or two you’ll be happy to know why you put that parameter there.

The UseRoaming parameter is undocumented and considered experimental. It’s quite astonishing that it is on by default. We’ll see if there are more of these undocumented parameters lurking in OpenSSH.

If you absolutely cannot change the system wide ssh_config file, since that requires root permissions, you must add this to your ~/.ssh/config under the global Host setting.

Host *
    # Fixing CVE-2016-0777
    UseRoaming no

If you do not already have a ~/.ssh/config file, just create one and make yourself familiar with man 5 ssh_config. You won’t regret that!

If you have connected to a malicious SSH server with one of the vulnerable versions you probably have lost private key material.
It’s recommended that you regenerate all SSH keys on your clients. This is a good opportunity to move away from older RSA keys to the newer Ed25519 keys, provided your endpoints already support that. (Available since SSH 6.5)

Further reading

CVE-2016-0777 (Mitre)
CVE-2016-0778 (Mitre)
OpenBSD Journal: OpenSSH: client bug
Theo de Raadt on openbsd-misc Mailing list
OpenSSH 7.1p2 Release notes
Qualys Security Advisory: Roaming through the OpenSSH client: CVE-2016-0777 and CVE-2016-0778


Update 1 (2016-01-14 19:49):

The path of ssh_config changed with OS X 10.11 (El Capitan). Thanks to @chrisridd for pointing me to it.

Update 2 (2016-01-14 20:16):

An updated OpenSSH Package to 7.1p2 is available from MacPorts. You still must apply the fix to the Apple provided SSH. If you’re using the openssh +hpn variant, you still need to wait for a patch or switch to the vanilla openssh package in the meantime.

Update 3 (2016-01-15 13:10)

Rainer Müller has updated the OpenSSH +HPN Variant for MacPorts in Ticket 144686.

Update 4 (2016-02-11 21:20)

Incorporated feedback by Stephen Dowdy