SSH plaintext recovery vulnerability

A somewhat mysterious SSH vulnerability has been reported in a way that unfortunately looks a bit like partial disclosure. In this case, though, there is a workaround that is supposed to alleviate the problem, so there are good reasons—as opposed to publicity-oriented reasons—to announce the flaw. While it is difficult to exploit, it does expose up to 32-bits of plaintext from within an SSH session which is a failure mode that is rather worrisome.

The flaw has only been confirmed in OpenSSH 4.7p1, but the announcement indicates that it is likely to be much more widespread: "We expect any RFC-compliant SSH implementation to be vulnerable to some form of the attack." The flaw is in the design of SSH and can allow an attacker who has "control over the network"—presumably the ability to monitor and inject traffic—to recover 32 plaintext bits with a very low probability (2^-18). The bits recovered come from an attacker-selected block of ciphertext. The attack leads to the termination of the SSH connection, so iterative attacks will be difficult or impossible.

It is hard to get too worked up about that kind of attack, even with much of the details lacking, but typically these kinds of flaws can be expanded in various ways. The announcement mentions variants that recover 14 bits with a probability of 2^-14. It also carries the following warning: "The success probabilities for other implementations are unknown (but are potentially much higher)." It is a security tautology that vulnerabilities only get bigger over time, which we have seen in various contexts, notably in DNS cache poisoning flaws over the years.

Another bit of information provided by the Centre for the Protection of National Infrastructure (CPNI), the UK government agency who issued the advisory, is that the attack analyzes "the behaviour of the SSH connection when handling certain types of errors". This particular attack is also only applicable to the default cipher-block chaining (CBC) mode, so switching to counter (CTR) mode works around the flaw.

OpenSSH supports the use of AES in CTR mode, which is what the advisory recommends using:

There is quite a bit of information in the advisory that might lead a determined attacker in the "right" direction. It might also provide enough for someone to come up with attacks that are more probable and/or reveal more plaintext. So far, the Internet Storm Center is reporting that they have not seen any evidence that the flaw is being exploited in the wild.

OpenSSH has not, as yet, addressed the issue, at least on their security page. At least in its current form, there is probably very little to worry about from this flaw, but very security-conscious SSH users will want to apply the workaround.