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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.BSO.1.10.0811251031470.16202@fuyu.mindrot.org>
Date: Tue, 25 Nov 2008 10:39:34 +1100 (EST)
From: Damien Miller <djm@...drot.org>
To: Nick Boyce <nick.boyce@...il.com>
Cc: Bugtraq <bugtraq@...urityfocus.com>
Subject: Re: OpenSSH security advisory: cbc.adv

On Mon, 24 Nov 2008, Nick Boyce wrote:

> [ahem] ... Sorry to be dumb, but ...
> 
> On Fri, Nov 21, 2008 at 10:19 AM, Damien Miller <djm@....openbsd.org> wrote:
> 
> > Based on the description contained in the CPNI report and a slightly
> > more detailed description forwarded by CERT this issue appears to be
> > substantially similar to a known weakness in the SSH binary packet
> > protocol first described in 2002 by Bellare, Kohno and Namprempre[2].
> > The new component seems to be an attack that can recover 14 bits of
> > plaintext with a success probability of 2^-14
> 
> Could someone please help the uncomprehending [i.e. me :-)] understand
> why or whether this is anything to be worried about at all ?
> 
> Quick calculator session :
> 2^(-18) = 0.000003814697265625
> 2^(-14) = 0.00006103515625
> 
> So there is a vanishingly small probability that a Bad Guy may
> discover less than 2 characters from my command-line, every time they
> try this attack.  And each time they fail, my connection gets rudely
> chopped.  Two characters won't help them much.  They'd need to succeed
> about ten times per typed command-line to snoop on most of my
> sessions.  This weakness is surely of no conceivable use to a Bad Guy
> ?

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 (assuming a very fast 10 connections per second).
> > Implementing a limit on the number of connection retries (e.g. 256) is
> > sufficient to render the attack infeasible for this case.
> 
> 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.
On the other hand, I expect that most people aren't running automated
transfers that will retry enough for the attack to become feasible.

We provide this information so you can decide whether this attack
is likely to succeed in your environment.

-d