Flaw Made Public In OpenSSH Encryption 231
alimo20 writes "Researchers at the Royal Holloway, University of London have discovered a flaw in Version 4.7 of OpenSSH on Debian/GNU Linux. According to ISG lead professor Kenny Patterson, an attacker has a 2^{-18} (that is, one in 262,144) chance of success. Patterson tells that this is more significant than past discoveries because 'This is a design flaw in OpenSSH. The other vulnerabilities have been more about coding errors.' The vulnerability is possible by a man-in-the-middle intercepting blocks of encrypted material as it passes. The attacker then re-transmits the data back to the server and counts the number of bytes before the server to throws error messages and disconnects the attacker. Using this information, the attacker can work backwards to figure out the first 4 bytes of data before encryption. 'The attack relies on flaws in the RFC (Request for Comments) internet standards that define SSH, said Patterson. ... Patterson said that he did not believe this flaw had been exploited in the wild, and that to deduce a message of appreciable length could take days.'"
Old version = old news (Score:5, Informative)
OpenSSH 5.2 was released in February already which has builtin countermeasures against this form of "attack." Next.
SSH standard (Score:5, Informative)
And in other news it also appears that the word "chink" is banned in the comments section.
Re:Not much of a threat... (Score:5, Informative)
Did you read the article?
It indicates that it effects SSH in general, not only one particular implementation.
Re:Old version = old news (Score:3, Informative)
I agree. I just checked all the machines I have immediate access to, and they are all on 5.1. Why does a vulnrability in 4.7 matter?
How vulnerable? (Score:3, Informative)
According to TFA, "OpenSSH version 5.2 contain[s] countermeasures". For Ubuntu users, note that Ubuntu 8.04 LTS (Hardy) is using [ubuntu.com] the vulnerable version 4.7. Versions 8.10 (Intrepid) [ubuntu.com] and above [ubuntu.com] appear to use version 5.1.
Does anyone know whether 5.1 contains the flaw and/or the "countermeasures"?
Also, can any security gurus comment on the danger level here? It sounds like there is a low-probability to access a small amount of information... but the very existence of this vulnerability makes me uncomfortable. Also, why does it mention Debian specifically? Don't most distros use an OpenSSH package based on the exact same design? Shouldn't they all be vulnerable?
Re:OKay (Score:4, Informative)
Being able to determine the first four bytes is what makes it 2^-18 instead of something much much smaller.
Original advisory (Score:5, Informative)
Why so much press on this? (Score:5, Informative)
This flaw was published in Nov 2008 with simple configuration fix, and OpenSSH released a default fixed version in March 2009.
Also, this attack gives only 4 bytes of unencrypted output after crashing your session many thousands of times, which is sure to be noticed. If you were repeating the exact same network traffic in millions of SSH sessions, an attacker might get something interesting after weeks of crashing your sessions. It's just one of the lamest exploits I've seen, worth mitigating eventually, but not worth all the press it's getting, especially 6 months after release...
The fix is simple, just use CTR mode encryption instead of CBC, or upgrade to OpenSSH 5.2 or later.
For more details go to the OpenSSH security page. [openssh.com]
To those wondering why they mention Debian (Score:5, Informative)
It is because that happened to be the system that they found the vulnerability on.
Nothing more than that, really.
All versions from 4.7 to 5.2 are affected (Score:2, Informative)
"The flaw, which lies in version 4.7 of OpenSSH on Debian/GNU Linux"
"Patterson said his group had worked with OpenSSH developers to mitigate the flaw, and that OpenSSH version 5.2 contained countermeasures."
They are unclear on whether or not it's only debian's repos that are affected, so I'd suggest upgrading to 5.2 or later.
Re:Old version = old news (Score:5, Informative)
Re:Design flaw (Score:3, Informative)
Damnit, it's affect.
Re:Old version = old news (Score:5, Informative)
5.1 does not have the countermeasures. 5.2 does. Upgrade.
Though, while the leaked information is significant, the chance at getting it in tiny, so the risk is small.
How to check SSH version (Score:2, Informative)
Re:Design flaw (Score:3, Informative)
They have a history of fucking up packages (including openssh).
Re:How vulnerable? (Score:5, Informative)
That's the wrong way to check it.
Debian and Ubuntu are not going to upgrade to 5.2. They will take the security fix, backport it to 4.7, and release that as an update. If you check the version you'll get 4.7, even with the fix applied.
Re:Old version = old news (Score:1, Informative)
Debian and Ubuntu frequently backport fixes rather than upgrade package versions, although in this case the date is listed as Oct 2007 and it might be infeasible to backport a fix if it requires major design changes.
Re:OKay (Score:4, Informative)
On my Ubuntu boxes, it's already 5.1...
The fix is in 5.2
Re:Appreciable length? (Score:4, Informative)
> Patterson said that he did not believe this flaw > had been exploited in the wild, and that to > deduce a message of appreciable length could take > days.
Is my social security number a "message of appreciable length?"
Probably not on its own. Full packed it would take 33 bits, 11 bytes (88 bits, though if the attacker knew for sure that an SSN was being sent in those bytes the search space would not significantly greater than the 33 bits) if represented in pure ASCII text with separators.
As each attempt to read each 32 bits has a 11/2^18 chance of success, and assuming failure of one attempt does no extra clue as to which other patterns to try next, each 4 byte block is going to take on average 131,072 connections to infer from the server response so for the 11 byte ASCII string that is an average attack length of 393,216 connections.
While that isn't going to take long (at 4.5 connections per second you are looking at a day), any message being sent containing your SSN is going to be significatly longer than the SSN on its own so I wouldn't worry just yet.
We are still in "it would be a lot easier for the attacker to raid your bins, burgle your house, or steal records from your bank" territory here. Though there is the chance that someone improve the attack (or already has) so be vigilant and apply updated SSH packages as soon as practical once your distribution offers them.
Re:Wait, what? (Score:3, Informative)
This is not in the least insightful. If you read TFA, you'll see that since the flaw is in the standard specification, it does affect all implementations. The article doesn't say the flaw is only on Debian; it says that's where the flaw was found.
Re:How to check SSH version (Score:2, Informative)
Gentoo seems to be up to date, both for arch and ~arch.
Re:Old version = old news (Score:5, Informative)
eix-sync && emerge -auDNtv world && echo "Yay :D"
Re:How to check SSH version (Score:3, Informative)
Re:How to check SSH version (Score:5, Informative)
Re:Not much of a threat... (Score:4, Informative)
Yes. That's why we now have replaced telnet/rsh/rcp and authenticated FTP with ssh and scp, NIS with LDAP+Kerberos, /etc/shadow, authentication in NFS, support for other filesystems like CIFS, etc.
Microsoft, for their part, haven't changed all that much.
You're talking about changes since the tools developed in the 1980s. Microsoft completely replaced their consumer OS, moving from the Win95-based platform to the infinitely more secure NT-based platform, moved to AD, replaced an unsecure method of storing passwords with a secure one, invented CIFS, moved to a filesystem where all actions can be audited, etc.
The non-Linux Unixes, for their part, are mostly the same as they were in 1985 (that Oracle OS, Sol-something or other, being the one exception).
Re:How vulnerable? (Score:3, Informative)
Debian stable is stable. Once it gets released it doesn't upgrade software to new versions or get new features. It gets bug fixes and security updates and that's it.
If you want a newer version of anything on Debian stable, you have to switch to testing, use a mixed stable/testing system, wait for the next stable release, build it yourself, or use somebody else's packages.
There are distributions like Gentoo which don't follow this model and continously release new versions.
Re:Good Thing (Score:5, Informative)
It may sound funny, but the MIT Kerberos sources contain an version of telnet and telnetd that support encryption. There has not been a vulnerablity in that for a while that I know of. There was a stupid vulnerability in logind on Solaris though which that telnet used. Also there is an encrypted version of rsh, rshd, and klogind in that source code. That has not been anything reported on that in a while either, though I think you only get 3DES if I recall correctly.
Can you give any other examples of this? (Score:4, Informative)
My understanding is that one packager screwed up one package (openssl), which (while a _big_ screw-up) would hardly amount to a "history of fucking up packages".
Can you cite any other examples that would indicate such a trend?
TL;DR - mitigation here (Score:2, Informative)
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha1
To verify:
ssh -v host
look for the output:
debug1: kex: server->client aes128-ctr hmac-sha1 zlib@openssh.com
debug1: kex: client->server aes128-ctr hmac-sha1 zlib@openssh.com
You are particularly interested in the aesXXX-ctr segment. If that specifies a CBC mode, then you probably need to change that server's config. For the blowfish-using type, I'm uncertain of the attack's applicability to blowfish-cbc. YMMV. For server testing, you probably want to make sure your ssh client isn't forcing the CTR mode. To test that, do
ssh -v -o Ciphers=aes256-cbc,aes192-cbc,aes128-cbc,aes256-ctr,aes192-ctr,aes128-ctr
and look for similar debugging output as above.