9 ms·

OpenSSH security advisory

184 points by 0x0 13y ago

0x0 13y ago
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 13y ago
  Note that testing/jessie and sid are vulnerable. Not that anybody should run a server with testing, but still :)
josteink 13y ago
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 13y ago
  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 13y ago
    "Unknown cipher type" for me, but close enough that it seems to mean the same thing.
- Schnouki 13y ago
  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)
  - dingaling 13y ago
    Thanks! I've never understood why so many applications pipe help output to STDERR. It's not an error... I asked for the output! shrug
    - clarry 13y ago
      Traditionally applications will print usage (which is usually the same as --help) if arguments are missing or invalid flags are given. This is clearly an error condition, and it would be very bad to print the output to stdout in that case. --help will simply call usage(), so there's no difference in behavior. I think it would be feature bloat / overkill to have programs print usage to stdout or stderr depending on how it's invoked, even if it's easy to implement.
      - alextingle 13y ago
        It's not even one extra line of code. usage() should take the output stream as a parameter.
        jasomill 13y ago
        Even so, is it really advantageous to have "foo --help" send usage info to stdout, but for "foo -?" to send "Invalid switch '-?'" followed by usage info to stderr? More importantly, usage information doesn't conform to the structure of ordinary program output, and can therefore be annoying or even dangerous if inadvertently treated as such, so it really, really does belong on stderr for any program whose stdout might reasonably be used as input to another program.
- deleted 13y ago
  [deleted]
j_s 13y ago
> 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 13y ago
  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 13y ago
    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.
    - johnchristopher 13y ago
      What about git-shell over ssh ?
    - simgidacav 13y ago
      > 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.
  - j_s 13y ago
    Hopefully this clears it up for you: https://news.ycombinator.com/item?id=6696070 https://news.ycombinator.com/item?id=6696070
- 13y ago
simias 13y ago
I had never heard of this GCM mode for block ciphers, do any distro package OpenSSL with this mode activated by default?
- djmdjm 13y ago
  It's https://en.wikipedia.org/wiki/Galois_Counter_Mode 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)
- rb12345 13y ago
  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.
- riquito 13y ago
  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-choose-authenticated-encryption.html http://blog.cryptographyengineering.com/2012/05/how-to-choos...
- geofft 13y ago
  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.
slipo 13y ago
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 13y ago
  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 13y ago
    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.
- 13y ago
simgidacav 13y ago
As side topic, it's quite awesome the level of auditing of this protocol. OpenBSD people deserve full respect.
- Bluerise 13y ago
  OpenBSD people? OpenSSH people!
  - Nux 13y ago
    Same people.
  - tikums 13y ago
    No. It's developed in-house by the OpenBSD project.
    - deleted 13y ago
      [deleted]
      - djmdjm 13y ago
        No, there are at least three of us (myself, Markus and Darren are the most regular committers) and we all work on other stuff in OpenBSD with varying frequency.
        simgidacav 13y ago
        If I may ask... How much time per day do you guys spend in working on OpenBSD and how much of this is it on auditing?
sramov 13y ago
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-using-spiped.html http://www.daemonology.net/blog/2012-08-30-protecting-sshd-u...
- peterwwillis 13y ago
  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)
gizzlon 13y ago
Is OpenBSD unaffected? http://www.openbsd.org/security.html#53 http://www.openbsd.org/security.html#53
- sramov 13y ago
  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 13y ago
    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 13y ago
      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 13y ago
        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?
pattt 13y ago
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 13y ago
  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 13y ago
    "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 13y ago
      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 13y ago
        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?
mnarayan01 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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 13y ago
        calloc can be faster because it has internal knowledge of whether the memory is already zero.
nullc 13y ago
http://tools.ietf.org/html/rfc5647 http://tools.ietf.org/html/rfc5647
vangale 13y ago
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/sshd-pfs_config 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).

184 points by 0x0 13y ago

0x0 13y ago

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 13y ago
Note that testing/jessie and sid are vulnerable. Not that anybody should run a server with testing, but still :)

josteink 13y ago

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 13y ago
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 13y ago
  "Unknown cipher type" for me, but close enough that it seems to mean the same thing.
Schnouki 13y ago
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)
- dingaling 13y ago
  Thanks! I've never understood why so many applications pipe help output to STDERR. It's not an error... I asked for the output! shrug
  - clarry 13y ago
    Traditionally applications will print usage (which is usually the same as --help) if arguments are missing or invalid flags are given. This is clearly an error condition, and it would be very bad to print the output to stdout in that case. --help will simply call usage(), so there's no difference in behavior. I think it would be feature bloat / overkill to have programs print usage to stdout or stderr depending on how it's invoked, even if it's easy to implement.
    - alextingle 13y ago
      It's not even one extra line of code. usage() should take the output stream as a parameter.
      - jasomill 13y ago
        Even so, is it really advantageous to have "foo --help" send usage info to stdout, but for "foo -?" to send "Invalid switch '-?'" followed by usage info to stderr? More importantly, usage information doesn't conform to the structure of ordinary program output, and can therefore be annoying or even dangerous if inadvertently treated as such, so it really, really does belong on stderr for any program whose stdout might reasonably be used as input to another program.
deleted 13y ago
[deleted]

j_s 13y ago

> 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 13y ago
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 13y ago
  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.
  - johnchristopher 13y ago
    What about git-shell over ssh ?
  - simgidacav 13y ago
    > 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.
- j_s 13y ago
  Hopefully this clears it up for you: https://news.ycombinator.com/item?id=6696070 https://news.ycombinator.com/item?id=6696070
13y ago

simias 13y ago

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

djmdjm 13y ago
It's https://en.wikipedia.org/wiki/Galois_Counter_Mode 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)
rb12345 13y ago
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.
riquito 13y ago
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-choose-authenticated-encryption.html http://blog.cryptographyengineering.com/2012/05/how-to-choos...
geofft 13y ago
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.

slipo 13y ago

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 13y ago
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 13y ago
  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.
13y ago

simgidacav 13y ago

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

Bluerise 13y ago
OpenBSD people? OpenSSH people!
- Nux 13y ago
  Same people.
- tikums 13y ago
  No. It's developed in-house by the OpenBSD project.
  - deleted 13y ago
    [deleted]
    - djmdjm 13y ago
      No, there are at least three of us (myself, Markus and Darren are the most regular committers) and we all work on other stuff in OpenBSD with varying frequency.
      - simgidacav 13y ago
        If I may ask... How much time per day do you guys spend in working on OpenBSD and how much of this is it on auditing?

sramov 13y ago

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-using-spiped.html http://www.daemonology.net/blog/2012-08-30-protecting-sshd-u...

peterwwillis 13y ago
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)

gizzlon 13y ago

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

sramov 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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?

pattt 13y ago

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 13y ago
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 13y ago
  "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 13y ago
    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 13y ago
      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?

mnarayan01 13y ago

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 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      calloc can be faster because it has internal knowledge of whether the memory is already zero.

nullc 13y ago

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

vangale 13y ago

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/sshd-pfs_config 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).