Slashdot Log In
Flaw Made Public In OpenSSH Encryption
Posted by
timothy
on Thu May 21, 2009 01:41 PM
from the days-to-whom dept.
from the days-to-whom dept.
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.'"
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
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.
Re: (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?
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.
Parent
Re:Old version = old news (Score:5, Informative)
eix-sync && emerge -auDNtv world && echo "Yay :D"
Parent
Re:Old version = old news (Score:5, Funny)
eix-sync && emerge -auDNtv world; sleep 1374261893645973165479613; echo "FINALLY!"
Parent
Re:Old version = old news (Score:5, Funny)
O_o
$ ssh -V
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
Parent
Re:Old version = old news (Score:5, Funny)
More importantly: can you send me the output of "ifconfig" and "lynx -dump http://www.ipchicken.com/ [ipchicken.com]"
Parent
Re:Old version = old news (Score:5, Informative)
Parent
Re:Old version = old news (Score:5, Insightful)
Parent
Re:Old version = old news (Score:5, Insightful)
It may be the "old" version, but it is the version most readily available. I setup an Ubuntu server (9.04) a couple of months ago. I used apt to get OpenSSH on it last month. The version it retrieved is
OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007
Just because a new version is out doesn't mean people are using it. People who rely on package maintainers or "the community" to help them out and keep things up to date could very well be let down. Moral of the story, if you want something done right, you have to do it yourself.
Parent
Re:Old version = old news (Score:4, Insightful)
Why? Given the now public nature of this and the fact that there are countermeasures how long do you think it will be until an updated package is available for Debian and all it's children projects?
I'm guessing a few days to a week before these countermeasures are patched into Debian's version. The whole point of ditributions is because keeping every piece of software up to date manually on even a single linux box is an arduous task at best.
Parent
I wish people would try to understand CRYPTO hacks (Score:5, Interesting)
There are a whole suite of cyphers, including AES aka Rijhndael are configurable, have you done yours?, and not vulnerable.
Finally the protocol is trivially fixed.
Now I for one, whilst I have the highest respect for the work done by people like Ross Anderson and Schnieer am fed up to the back teeth with alarmism from governments, NGOs and academics -- all of which add up to give us more money.
If you dont know these researchers were working for the UK equivalent of Homeland Security and failed to inform SSH of the details of the attack, doubtless quoting National Security.
These people who parade nonsense should be tarred an feathered and sent on the next rail.
Parent
Good Thing (Score:5, Funny)
Whew. Glad I use Telnet.
Re:Good Thing (Score:5, Funny)
But telnet transmits your credentials unencrypted! To be super-secure I simply avoid transmitting them in the first place...
root@host# nc -l -p 1999 -c bash
user@otherhost: nc otherhost 1999
whoami
rm -fR /
(PS don't actually do this)
Parent
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.
Parent
SSH standard (Score:5, Informative)
And in other news it also appears that the word "chink" is banned in the comments section.
Re:SSH standard (Score:4, Funny)
Also, dude, chink is not the preferred nomenclature. Asian-American, please.
Parent
Re:SSH standard (Score:5, Funny)
Parent
Design flaw (Score:5, Interesting)
Re: (Score:3, Informative)
Damnit, it's affect.
Re:Design flaw (Score:5, Funny)
Why does this only effect Debian?
Damnit, it's affect.
Not if the openSSH flaw were causing Debian to exist. Then it would be effecting Debian.
http://crofsblogs.typepad.com/english/2005/08/effect_as_a_ver.html [typepad.com]
Parent
Re: (Score:3, Informative)
They have a history of fucking up packages (including openssh).
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?
Parent
OKay (Score:3, Funny)
The 2^-18 is _really_scary_
The 'first 4 bytes', not so much.
So, meh. Of course true hardcore cryptanalysts are sure to be already ditching OpenSSH or maybe piping it through GPG first.
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.
Parent
Re:OKay (Score:4, Informative)
On my Ubuntu boxes, it's already 5.1...
The fix is in 5.2
Parent
Re:OKay (Score:5, Funny)
The 2^-18 is _really_scary_
The 'first 4 bytes', not so much.
So, meh. Of course true hardcore cryptanalysts are sure to be already ditching OpenSSH or maybe piping it through GPG first.
Fuck gubfr onfgneqf, ebg13 vf tbbq rabhtu sbe nalbar.
Allow me to translate:
$ echo "Fuck gubfr onfgneqf, ebg13 vf tbbq rabhtu sbe nalbar." | caesar
Shpx those bastards, rot13 is good enough for anyone.
Parent
Wait, what? (Score:5, Insightful)
". . .discovered a flaw in Version 4.7 of OpenSSH on Debian/GNU Linux."
"The attack relies on flaws in the RFC (Request for Comments) internet standards that define SSH"
So which is it, is it an implementation specific bug, which is specific to OpenSSH on Linux specifically, OpenSSH on all O/Ses, or is it a flaw in the RFC, which should make it exploitable on *all* implementations of SSH, shouldn't it? How can a flaw in the standard only be exploitable in one version of one implementation of the standard on one specific target OS?
Re:Wait, what? (Score:5, Insightful)
I *did* read the TFA, and it really wasn't clear in the article at all. Why even bother mentioning Debian and Linux, if the problem was an SSH problem, and not at all specific to Debian or Linux? Seems like it was just a somewhat poorly written article, adding confusion where there didn't have to be. People will take away from this that this is a Linux problem, and might not consider the possibility that, e.g. Mac OS X (which I believe includes some version of OpenSSH) may *possibly* be shipping an affected version of the software (I'm not saying it is, I'm just saying that the article author wrote the article in such a way that it appears the problem is strongly linked to Linux, when it sounds, upon further examination, like it isn't).
It's really not definitive from the article whether or not other implementations are or might be affected, despite your assertion.
Parent
Re:Wait, what? (Score:4, Funny)
All those hippie OSs look the same. Take a bath, cut your hair, and use a secure OS like WIndows.
Parent
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: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.
Parent
Re:How vulnerable? (Score:5, Insightful)
If your security scanner reports a vulnerability based on banners instead of testing the real flaw, they are flawed.
Such security scanners feed the myth that changing/removing banners magically makes your network secure.
Parent
Original advisory (Score:5, Informative)
Which is it? (Score:3, Insightful)
Some Additional Perspective FTA (Score:4, Insightful)
FTA, this vulnerability is addressed in newer versions of OpenSSH, not by fixing the specification, but by employing some kind of workaround to make it impractical. I didn't know that from the summary, since I don't really keep current on where OpenSSH is with their releases.
It seems like this attack has an awfully small chance of success. I am wondering if there is that small chance of success to decode a message after many days, or if because of the small chance of success, it would take multiple days before you had anything.
If this is really something that has almost no chance of working at all--period, I'm not too worried. If it is something that makes the encryption breakable in a few days, that's a pretty big deal and am surprised that it didn't get outed sooner as a flaw.
Can/should the RFC be revised to close this hole? Are there other (perhaps more obvious) examples of weakness in the RFC that have implementation-specific fixes applied?
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]
Re:Why so much press on this? (Score:4, Interesting)
Noticed? A good firewall that is updated regularly by a traffic analyzer should have a rule set to drop or deny the retransmissions after the first few. I guess we could have a philosophical debate about whether running code "notices" something when it matches a pattern and crosses a threshold to trigger a rule. "Notice" to me usually connotes sentience, or at least animal consciousness.
Parent
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.
Re:To those wondering why they mention Debian (Score:4, Interesting)
The changelog for this version includes:
* Backport from upstream CVS (Markus Friedl):
- packet_disconnect() on padding error, too. Should reduce the success probability for the CPNI-957037 Plaintext Recovery Attack to 2^-18.
This implies that older versions are more vulnerable. Not sure if this is what people are referring to as 5.2's countermeasures.
Parent
Need to be worried? (Score:3, Interesting)
Of course, those numbers are regarding a specific distribution/ssh version, could be different for other versions, but still, looks somewhat hard to happen ever.
Re: (Score:3, Interesting)
Anyone else remember when Unix was the usual target, and MS/DOS the "safe" OS?
Re:Not much of a threat... (Score:5, Insightful)
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.
Parent
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).
Parent
Re: (Score:3, Funny)
This is not your lawn. The property line clearly indicates...
wait a minute...
you are on MY LAWN!
Re:Not much of a threat... (Score:4, Funny)
Anyone else remember when stone tablets were the usual target, and cave drawings considered "safe"?
Parent
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.
Parent
Re: (Score:3, Insightful)
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.
Parent
Re:How to check SSH version (Score:5, Informative)
Parent