bugtraq - Re: OpenSSH security advisory: cbc.adv

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a847a3140811241936y5b6e540dn1698214ca10d87ce@mail.gmail.com>
Date: Tue, 25 Nov 2008 03:36:19 +0000
From: "Nick Boyce" <nick.boyce@...il.com>
To: Bugtraq <bugtraq@...urityfocus.com>
Cc: "Damien Miller" <djm@...drot.org>
Subject: Re: OpenSSH security advisory: cbc.adv

On Mon, Nov 24, 2008 at 11:39 PM, Damien Miller <djm@...drot.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