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
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
A switch to AES in counter
mode could most easily be enforced by limiting which encryption
algorithms are offered during the ciphersuite negotiation that takes
place as part of the SSH key exchange (see RFC 4253, Section 7.1).
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.
to post comments)