OpenSSH security advisory

[slipo]

Test against latest version of:

* Arch Linux -- Version match: OpenSSH_6.3p1, OpenSSL 1.0.1e 11 Feb 2013 (Supports AES-GCM)

CentOS 5.10 -- OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 (No AES-GCM support)

CentOS 6.4 -- OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010 (No AES-GCM support)

Debian 6 (squeeze) -- OpenSSH_5.5p1 Debian-6+squeeze4, OpenSSL 0.9.8o 01 Jun 2010 (No AES-GCM support)

Debian 7 (wheezy) -- OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013 (Supports AES-GCM)

Fedora 18 (Spherical Cow) -- OpenSSH_6.1p1, OpenSSL 1.0.0-fips 29 Mar 2010 (Supports AES-GCM)

* Fedora 19 (Schrödinger’s Cat) -- Version match: OpenSSH_6.2p2, OpenSSL 1.0.0-fips 29 Mar 2010 (Supports AES-GCM)

openSUSE 12.3 (Dartmouth) -- OpenSSH_6.1p1, OpenSSL 1.0.1e 11 Feb 2013 (Supports AES-GCM)

Ubuntu 10.04.4 LTS (Lucid) -- OpenSSH_5.3p1 Debian-3ubuntu7, OpenSSL 0.9.8k 25 Mar 2009 (No AES-GCM support)

Ubuntu 12.04.3 LTS (Precise) -- OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012 (Supports AES-GCM)

Ubuntu 12.10 (Quantal) -- OpenSSH_6.0p1 Debian-3ubuntu1, OpenSSL 1.0.1c 10 May 2012 (Supports AES-GCM)

* Ubuntu 13.10 (Saucy) -- Version match: OpenSSH_6.2p2 Ubuntu-6, OpenSSL 1.0.1e 11 Feb 2013 (Supports AES-GCM)

[eliasmacpherson]

I found your comment somewhat cryptic, the asterisks mean it's affected, right?

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729029

"AES-GCM support was introduced in 6.2, so oldstable and stable should be fine (from http://www.openssh.com/txt/release-6.2):"

Debian 7 (wheezy) -- OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013 (Supports AES-GCM)

If AES-GCM was introduced in 6.2, did someone patch 6.0 to support AES-GCM? I can't reconcile your list with the statement in the bug report otherwise. Could you explain?

I can't understand why AES-GCM was introduced in 6.2 and your list has many < 6.2 that support AES-GCM.

[ushi]

Arch Linux -- OpenSSH_6.4p1, OpenSSL 1.0.1e 11 Feb 2013 (Supports AES-GCM)

[simgidacav]

As side topic, it's quite awesome the level of auditing of this protocol. OpenBSD people deserve full respect.

[Bluerise]

OpenBSD people? OpenSSH people!

[mnarayan01]

From the diff:

  -	newkey = xmalloc(sizeof(*newkey));
  +	newkey = xcalloc(1, sizeof(*newkey));

The only change is that the allocated memory is zeroed, right? (Just wondering if I'm missing something.)

[djmdjm]

Nope. That's all.

The newkey struct in turn contains a bunch of OpenSSL context structures, and one of these includes a cleanup callback pointer for the MAC (message authentication code) in use. For most ciphers this was being initialised later but AES-GCM provides message integrity without the need for an external MAC and in this case the MAC context was being left uninitialised.

When the newkeys struct was later being cleaned up as part of a rekeying operation, the cleanup callback was called. It's address was whatever happened to be on the heap when this allocation occurred.

It certainly appears exploitable using standard techniques, though it may be complicated somewhat by OpenSSH's privilege separation architecture.

[zokier]

Yes. I believe the bug rises from some code like:

    if (newkey->callback != NULL) {
        newkey->callback()
    }

If newkey structure was not zeroed, then the callback would have had some contents from previous use and the NULL check would have passed and some unintended memory position would be called.

[marc_omorain]

It seems odd to see a commit in this day and age with no unit test. When you make a new newkey struct the clean-up callback should be NULL.

[0x0]

Debian Stable seems to be unaffected: https://security-tracker.debian.org/tracker/CVE-2013-4548

[martinml]

Note that testing/jessie and sid are vulnerable. Not that anybody should run a server with testing, but still :)

[pattt]

PoC ? Seriously with all the complex OS memory management access control, isolation and randomization features (like security features implemented by OpenBSD) writing a working exploit for this would be a real state of art ..

[antocv]

Linux by default doesnt do randomization features, at least not ArchLinux - the most security aware distro (sarcasm). Ubuntu doesnt do that either.

What do you mean by memory management access control?

As ssh contains or references code to open/read/write sockets, thats what I would do - return oriented programming or whatever its called - to use the functions already defined/within scope and memory, to open a reverse shell.

[vangale]

In the past I've had this in my sshd_config files:

  Ciphers aes256-ctr
  MACs hmac-sha2-512

This is one recommended way for forward secrecy https://github.com/ioerror/duraconf/blob/master/configs/sshd...

Unfortunately my favored Android SSH client (juiceSSH) couldn't handle that so I had to change to:

  Ciphers aes256-ctr,aes256-cbc
  MACs hmac-sha1

which is rather unfortunate, but still turned out to have been a good thing in light of this vulnerability (I'm running 6.2 on all my machines because of the DoS vulnerability in earlier versions).

[josteink]

    2. Affected configurations
    
    OpenSSH 6.2 and OpenSSH 6.3 when built against an OpenSSL that supports AES-GCM.

What would be a good/simple way to test if your system is one of these? How can I check which ciphers my build of OpenSSL supports?

Edit: The following command returns nada on all my systems. I guess that puts me in the clear?

    $ openssl --version 2>&1 | grep gcm

[mandalar12]

What I did is try to use the cipher : ssh -c [email protected] (host)

If you get "no cipher found", you're clear, if you can connect you can disable the cipher (while keeping others) with this line in you sshd_config:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc

Source: http://www.openssh.com/txt/gcmrekey.adv

[Schnouki]

I think this is a better test:

$ openssl enc --help 2>&1 | grep gcm -aes-128-ecb -aes-128-gcm -aes-128-ofb -aes-192-ecb -aes-192-gcm -aes-192-ofb -aes-256-ecb -aes-256-gcm -aes-256-ofb

(Tested on ArchLinux with OpenSSL 1.0.1.e-5)

[sramov]

spiped, problem solved.

http://www.tarsnap.com/spiped.html

http://www.daemonology.net/blog/2012-08-30-protecting-sshd-u...

[peterwwillis]

Uh. No.

Spiped just 'pipes' an SSH connection from one point to another. It's essentially a very thin VPN.

But this bug is exploited via authenticated users. If you're using ssh keys (...you are, aren't you?) you would basically already need a valid SSH login to use this vuln; if nobody but you has an ssh key login, you're safe. This vulnerability may still affect you - even with spiped - depending on who has an ssh key login to your box.

(And this thinking that you can just 'wrap another layer of encryption/abstraction' around a problem, is why we can't have nice things)

[j_s]

> this vulnerability might permit code execution with the privileges of the authenticated user

Yet another vote for secure authentication, which typically means requiring use of a private key and disabling root login.

[0x0]

Not sure what you're thinking about here, since the vulnerability is post-authentication?

A bug like this could be pretty devastating for github and bitbucket type setups where everyone in the world is using a shared, restricted "git" UNIX user authenticating with a private key, for git ssh push and pull.

[zokier]

I'd rather put this as a vote for proper os level privilege management/access control. You shouldn't need to trust OpenSSH to limit user privileges.

[djmdjm]

The authentication method used is completely orthogonal to this bug.

[dzhiurgis]

Perhaps you have got a good guide how to implement this?

[gizzlon]

Is OpenBSD unaffected? http://www.openbsd.org/security.html#53

[sramov]

That's for previous release. Look at the current errata:

http://www.openbsd.org/errata54.html

In places where -current is not an option, look into M:Tier binpatches and their `openup` utility:

https://stable.mtier.org/

http://www.mtier.org/index.php/solutions/apps/openup/

[simias]

I had never heard of this GCM mode for block ciphers, do any distro package OpenSSL with this mode activated by default?

[riquito]

Quoting Matthew Green

"the only people who hate GCM are those who've had to implement it. You see, GCM is CTR mode encryption with the addition of a Carter-Wegman MAC set in a Galois field. If you just went 'sfjshhuh?', you now understand what I'm talking about. Implementing GCM is a hassle in a way that most other AEADs are not. But if you have someone else's implementation -- say OpenSSL's -- it's a perfectly lovely mode."

From an interesting read

http://blog.cryptographyengineering.com/2012/05/how-to-choos...

[djmdjm]

It's https://en.wikipedia.org/wiki/Galois_Counter_Mode and IIRC it was added to OpenSSL in the 1.0.1 release.

Don't let my hazy recollection be a substitute for checking your platform though :) (see some good recipes in this thread)

[geofft]

GCM is one of the authenticated-encryption modes, which means that in addition to encrypting the data, it also generates an authentication tag. It is somewhat like using a plain-encryption mode like CTR or CBC and also using a MAC like HMAC, but a single algorithm, so there's less complexity. Other authenticated-encryption block cipher modes include OCB and EAX.

(Most of these are actually "authenticated encryption with associated data", which also let you add some cleartext data to the authentication tag without encrypting it.)

I believe GCM support is new as of OpenSSL 1.0.

[rb12345]

It's used in TLS 1.2, so I'd assume any distros using OpenSSL 1.0.1 (which added TLS 1.2 support) would have it enabled.

[nullc]

http://tools.ietf.org/html/rfc5647