

OpenSSH security advisory - 0x0
http://www.openssh.com/txt/gcmrekey.adv

======
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](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](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.

~~~
JshWright
I _think_ he's talking about whether or not OpenSSL supports AES-GCM.

e.g. Debian 7 has a version of OpenSSL that supports AES-GCM, but OpenSSH
isn't one of the affected versions.

------
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!

~~~
tikums
No. It's developed in-house by the OpenBSD project.

------
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.

~~~
mnarayan01
Thanks.

Is calloc(1, size) considered idiomatic for zeroing memory? While I haven't
used C much lately, back when I did I don't think I realized this, and could
see myself at least considering reverting the change during "code cleanup".

~~~
coldpie
Yeah, it's fairly common. calloc zeroes, malloc doesn't, and you shouldn't
make a significant change like that during code cleanup. I think it's somewhat
more common to see malloc followed by memset, as the intent is way more clear
to a reader than just calloc by itself.

~~~
tedunangst
calloc can be faster because it has internal knowledge of whether the memory
is already zero.

------
0x0
Debian Stable seems to be unaffected: [https://security-
tracker.debian.org/tracker/CVE-2013-4548](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.

~~~
pattt
"This vulnerability is mitigated by the difficulty of pre-loading the heap
with a useful callback address and by any platform address-space layout
randomisation applied to sshd and the shared libraries it depends upon."

Right. But in order for RoP explotation (say chain some libc function calls)
to work you'd still have to manipulate the stack arguments in some fancy way,
also it's not really sure how trivial is "pre-loading the heap" since it's a
post-authentication stage bug as the advisory mentions. Of course these are
just speculation, digging into the source code might change perspective :)

~~~
antocv
Yes it is quite comforting this is post-authentication, so in most cases no
big deal. Just tough luck for shared accounts.

I guess most people dont run sshd as root and capabilities either so that
minimizes damage too. Another reason to not run ssh on port 22, no root, no
special caps needed.

~~~
Nick_C
All my servers run sshd as root, including the FreeBSD ones. Is that ok? Or do
you mean that sshd drops privileges for the child after forking?

------
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...](https://github.com/ioerror/duraconf/blob/master/configs/sshd/sshd-
pfs_config)

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 aes256-gcm@openssh.com (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](http://www.openssh.com/txt/gcmrekey.adv)

~~~
bjeanes
"Unknown cipher type" for me, but close enough that it seems to mean the same
thing.

------
sramov
spiped, problem solved.

[http://www.tarsnap.com/spiped.html](http://www.tarsnap.com/spiped.html)

[http://www.daemonology.net/blog/2012-08-30-protecting-
sshd-u...](http://www.daemonology.net/blog/2012-08-30-protecting-sshd-using-
spiped.html)

~~~
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.

~~~
simgidacav
This bug is problematic for all those situations where the ssh protocol is not
used for telnet-style command line, but as a transport.

e.g. Git uses ssh as transport protocol, but github (and similar platforms)
don't support direct user login.

~~~
simgidacav
> What about git-shell over ssh ?

I guess that gives the same problem. The exploitation allows to execute
arbitrary code, as you would do by launching commands from, say, bash.

I don't know git-shell, but I guess (from the manpage) it restricts the
allowed commands. The exploitation of the bug would allow a malicious user to
execute a command instead of git-shell. A good example of command could be
/bin/bash.

------
gizzlon
Is OpenBSD unaffected?
[http://www.openbsd.org/security.html#53](http://www.openbsd.org/security.html#53)

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

[http://www.openbsd.org/errata54.html](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/](https://stable.mtier.org/)

[http://www.mtier.org/index.php/solutions/apps/openup/](http://www.mtier.org/index.php/solutions/apps/openup/)

~~~
gizzlon
SO that page isn't updated for the affected versions? Is that because they
only "support" (release patches for) the newest release? I was under the
impression they "supported" the two latest releases..

~~~
sramov
[http://www.openbsd.org/errata53.html](http://www.openbsd.org/errata53.html)

The page you linked to is not updated as often or as thoroughly. Errata
('Patches' link on the main page) is the page you want. Sorry for the
confusion.

~~~
gizzlon
Thanks, I thought it looked kind of empty. It's a little confusing though..

Also, maybe a warning the unsupported version could be on order?

------
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...](http://blog.cryptographyengineering.com/2012/05/how-to-choose-
authenticated-encryption.html)

------
nullc
[http://tools.ietf.org/html/rfc5647](http://tools.ietf.org/html/rfc5647)

