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
> 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