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]

Date: Mon, 24 Nov 2008 17:05:58 +0000
From: "Nick Boyce" <nick.boyce@...il.com>
To: Bugtraq <bugtraq@...urityfocus.com>
Cc: "Damien Miller" <djm@....openbsd.org>
Subject: Re: OpenSSH security advisory: cbc.adv

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

What am I missing ?
Is this something to do with subsequently using those characters in a
known plaintext attack, or recovering a significant fraction of a
shortish typed password, or what ?

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

Cheers
Nick Boyce
-- 
"We make money the old-fashioned way: we EARN it"