Re: OpenSSH security advisory: cbc.adv

On Mon, Nov 24, 2008 at 11:39 PM, Damien Miller <djm@xxxxxxxxxxx> wrote:

On Mon, 24 Nov 2008, Nick Boyce wrote:

Could someone please help the uncomprehending [i.e. me :-)] understand
why or whether this is anything to be worried about at all ?

Yes, the attack is very unlikely to work against an interactive

The usage pattern where the attack is most likely to succeed is where an
automated connection is configured to retry indefinitely in the event of
errors. In this case, it might be possible to recover as much as 14 bits
of plaintext per hour
Given the amount of data pumped down the typical automated connection
per hour, this is hardly anything to worry about .. surely ?

That depends on the data that is being transferred. If it includes
sensitive information, then this leakage rate might be unacceptable.
We provide this information so you can decide whether this attack
is likely to succeed in your environment.

Thanks - I appreciate your post and clarification.
To be clear, I wasn't seeking to dispute your original post in any way
- rather I figured many of us non-cryptographers would like to be
*very* sure exactly what the exposure is, given that a weakness in SSH
protocol is often the cause of much fear, many missed meals and
remedial steps taken hurriedly :)

The original CPNI bulletin is less than helpful in stating :
"The severity is considered to be potentially HIGH due to the
32 bits of plaintext that can be recovered."
leaving me wondering how to reconcile "severity HIGH" with "32 bits of
plaintext can be recovered".

Ignoring the attack success probability, I glean from your explanation
that there is only really a problem if, say, the SSH connection
transfers a simple 1, 2, 3 or 4 byte value which reveals a secret.

at present we do not feel that this issue is serious enough to make an emergency release

Maybe this was always clear, but along with that reassurance I guess
you would recommend we all take your stated remedial action :
[place] the following directive in sshd_config and ssh_config:
"Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc"
at the very next maintenance opportunity, on the grounds that it can't
hurt, and can only help ?

For instance, (and my apologies for not having looked in any detail at
possible compatibility issues), would it be fair to say the popular
PuTTY-client-with-OpenSSH-server scenario would be fine after the
above config change ?

Nick Boyce
"Science is the poetry of reality" -- Richard Dawkins

Relevant Pages

  • Re: A basic cryptanalysis question
    ... he assumes he's recovered the plaintext. ... but only for what is known as a ciphertext-only attack. ... include the keys in your construction. ... decryption table for F and use a meet-in-the-middle strategy to recover the ...
  • recover from possible DOS attack!
    ... recover from possible DOS attack! ... router connection and all will be well, ...
  • [Full-disclosure] Re: RLA ("Remote LanD Attack")
    ... You are correct if your router is configured with such an ACL, ... and the LAND attack no longer works. ... hping2 on Comcast Cable connection behind Linksys Router ...
  • (fwd) FreeBSD Security Advisory FreeBSD-SA-01:39.tcp-isn (fwd)
    ... susceptible to attack than other unencrypted sessions. ... > incoming connection is being established, ... > All versions of FreeBSD 3.x and 4.x prior to the correction date ... > requiring other authentication of the originator are vulnerable to ...
  • [NEWS] Land Attacks Still Going Strong
    ... Land Attacks Still Going Strong ... " <> A LAND attack is a DoS ... hping2 on Comcast Cable connection behind Linksys Router ...