bleh -- this doesn't seem particularly groundbreaking. As others have noted for their respective schools, Harvard has had this system in place for years. They keep pretty mum on its inner workings, but we know that it does more than straight text matching, probably using some of the parsing internals of the compiler to break the code down into a canonical form, and then do the necessary comparisons.
While Rob's summary is fairly accurate, I disagree with a few points.
The paper only estimates the information leaked at 1.2 bits/character for random passwords. It does not leak that much information for English passwords (mainly because there is not that much information to leak -- if it leaked that many bits, then using ssh would be tantamount to sending your password in cleartext -- that is not the case here). There was a question about this during Dawn's talk, and she admitted that they had not estimated the information leaked for English passwords.
Also, some people have suggested adding a random timer to the packets. This would not really help, because with sufficient data, you could filter out the noise associated with the random timer.
Basically, this attack gives you a very nice probability distribution that you can use to launch a brute-force attack against a password. The results in the paper show that for random passwords, you can often find the real password in the first 1% of the search space. While this is a serious attack, it is not equivalent to using telnet, as Rob suggests.
Sending packets at certain intervals would weaken this attack. It would be nice if ssh send the same sized packets at constant intervals, but that would be an egregious waste of bandwidth and infeasible for a whole slew of reasons. The papers suggests a number of fixes for ssh which would mitigate the damage caused by this attack. The solutions are reasonable, and I hope they are implemented soon.
-mike
Slashdot Mirror
bleh -- this doesn't seem particularly groundbreaking. As others have noted for their respective schools, Harvard has had this system in place for years. They keep pretty mum on its inner workings, but we know that it does more than straight text matching, probably using some of the parsing internals of the compiler to break the code down into a canonical form, and then do the necessary comparisons.
-mike
While Rob's summary is fairly accurate, I disagree with a few points. The paper only estimates the information leaked at 1.2 bits/character for random passwords. It does not leak that much information for English passwords (mainly because there is not that much information to leak -- if it leaked that many bits, then using ssh would be tantamount to sending your password in cleartext -- that is not the case here). There was a question about this during Dawn's talk, and she admitted that they had not estimated the information leaked for English passwords. Also, some people have suggested adding a random timer to the packets. This would not really help, because with sufficient data, you could filter out the noise associated with the random timer. Basically, this attack gives you a very nice probability distribution that you can use to launch a brute-force attack against a password. The results in the paper show that for random passwords, you can often find the real password in the first 1% of the search space. While this is a serious attack, it is not equivalent to using telnet, as Rob suggests. Sending packets at certain intervals would weaken this attack. It would be nice if ssh send the same sized packets at constant intervals, but that would be an egregious waste of bandwidth and infeasible for a whole slew of reasons. The papers suggests a number of fixes for ssh which would mitigate the damage caused by this attack. The solutions are reasonable, and I hope they are implemented soon. -mike