Slashdot Mirror
Flaw Made Public In OpenSSH Encryption
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.'"
". . .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?
So is it a flaw in the design of SSH or in the Debian patched OpenSSH implementation? If it's the former (as the quote seems to imply), why does it matter what SSH implementation, OS they found it on? Shouldn't it affect everyone?
sic transit gloria mundi
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?
This is a technicality that no one cares about anymore I think even Stallman gave up on it.
The interesting part here is that more details have been released about what the flaw actually was. Before, it was merely "there is a flaw, and we have notified vendors", but now more details are available. In particular, that while 5.2 has countermeasures, it is a flaw in the protocol itself, and not the implementation. "Countermeasure" does not equal "completely solved".
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.
My blog
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.
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.
Normal people worry me!
And security scanners are going to misreport the systems with backported patches as being vulnerable :-/
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Very true, but utterly off-topic as this is not the case.
Debian would exist without this flaw, if fact I am sure it would prefer to exist without it.
And more seriously openssl which led to a lot of unlucky people having generated keys much weaker than they had expected.
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.
{{.sig}}
Any of them that have successfully set up IPSEC? I've used it to secure an application which screen-scrapes a telnet session and uses ftp to transfer files.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
replaced an unsecure method of storing passwords with a secure one
While that is true, the Microsoft default is to still have the old insecure methods enabled. You need to disable them with active directory policy or editing the registry.
That's NoLMHash = 1 and lmcompatibilitylevel = 5 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
I believe Microsoft finally changed the defaults in Vista.