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.'"
Anyone else remember when Unix was the usual target, and MS/DOS the "safe" OS?
-Space for rent
If the flaw is in the design of SSH, wouldn't all OS's be effected? Why does this only effect Debian?
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.
Implies man-in-the-middle already, and the odds of figuring 32 bits of a particular packet are somewhat low. The worst case i could think about is when i pass my password or a very specific short data (cc number?). That particular data must be the decripted one, and in the 1/256k odds of happening, IF i have someone in the middle actively trying to get it. With that chances, the attacker well could expend his time playing lotto that have more chances to win.
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.
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.
This was never a real threat, just another piece of Academic FUD. To be vulnerable as an interactive ssh user you would have to ignore 100,000 aborted sessions to expose 14 bits of plaintext, I think I would notice, and block the attacker.
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.
I assume the parent failed every numerate course he ever took, and never took any kind of statistics for idiots course, and has not bothered to read and understand the attack.
... then I have to tolerate 100000 failures/connection.
An continues to spread FUD.
The attack requires a Man in the Middle scenario, if I ssh into a random machine the MiM is __VERY__ unlikely to work unless the NSA and my ISP are in cahoots and I dont notice that connection takes a nonsensically longer time (15min v 3s),
Now comes the idiot who talks about rsync, and scripted connections, which, for brevity I did not address and tries to use multipicative probability leveling to try to convince us we have a problem; sorry now you need 1000+ MiM attacks, and fail to notice that they are failing, so you also dont notice a net cable kicked out, or a cable cut by a backhoe.
Look guys, get real, if you want to use statistics or probability learn some and understand contingent probability which is essential to risk evaluation.
Are you kidding? Security scanners can't go around overflowing buffers as part of a routine test. This could take down your entire network! Honestly...
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
But where did those details get released? They are not on the zdnet article in the link. Based on the vague description, I have a guess about what the problem probably is. You take cipher block you want to get decrypted and send it in the position in the stream where the length of a message would be. The server then decrypts it and finds the length. If the length is a 32 bit field but only lengths up to 2^14 are valid, then it would explain the numbers in the description. If the length is invalid, the receiver will immediately break the connection and all you know is, that the 32 bit value was larger than a valid length. If the length is valid, the attacker starts sending garbage one byte at a time to the recipient, until the recipient breaks the connection. Then the attacker knows the 32 bits.
This could be fixed by not breaking the connection immediately. A fix could work like this. First you find out after how many bytes the connection would be broken for the longest valid size of a packet. If you receive a message with invalid length or invalid checksum, you receive more bytes and throw them away until you have received the maximum number of bytes for a message. Only then you report the problem (and make sure not to tell the peer if it was invalid length or invalid checksum). If your peer interrupts the connection before you receive all the additional bytes, you behave exactly as if they had done so before you had enough bytes to verify the checksum.
Do you care about the security of your wireless mouse?