Bugtraq mailing list archives
Re: OpenSSH security advisory: cbc.adv
From: "Nick Boyce" <nick.boyce () gmail com>
Date: Tue, 25 Nov 2008 03:36:19 +0000
On Mon, Nov 24, 2008 at 11:39 PM, Damien Miller <djm () mindrot org> 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 connection.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 ? Cheers Nick Boyce -- "Science is the poetry of reality" -- Richard Dawkins
Current thread:
- OpenSSH security advisory: cbc.adv Damien Miller (Nov 21)
- Re: OpenSSH security advisory: cbc.adv Otto Moerbeek (Nov 24)
- Re: Re: OpenSSH security advisory: cbc.adv Guillaume MULLER (Nov 24)
- Re: OpenSSH security advisory: cbc.adv Nick Boyce (Nov 24)
- Re: OpenSSH security advisory: cbc.adv Damien Miller (Nov 25)
- Re: OpenSSH security advisory: cbc.adv Nick Boyce (Nov 25)
- Re: OpenSSH security advisory: cbc.adv Bob Beck (Nov 25)
- Re: OpenSSH security advisory: cbc.adv Damien Miller (Nov 25)
- Re: OpenSSH security advisory: cbc.adv Fabian Hänsel (Nov 25)
- Re: OpenSSH security advisory: cbc.adv Otto Moerbeek (Nov 24)
- <Possible follow-ups>
- Re: Re: OpenSSH security advisory: cbc.adv dennis jackson (Nov 25)