Re: Bug#506115: openssh: Plaintext Recovery Attack Against SSH

[Colin Watson <cjwatson@debian.org>]

On Fri, Nov 21, 2008 at 05:29:33PM +0100, Cristian Ionescu-Idbohrn wrote:
> On Fri, 21 Nov 2008, Colin Watson wrote:
> > Accordingly, I'm downgrading this bug; I'd rather not rush out a
> > configuration change (which could well break interoperability with
> > unusual servers; it wouldn't be the first time) when upstream doesn't
> > feel it's urgent enough to do so themselves.
> 
> Right.  But what exactly are the pits one could fall into, should one
> follow the advice?
> 
>    Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc

sshd_config(5) says:

     Ciphers
             Specifies the ciphers allowed for protocol version 2.
             Multiple ciphers must be comma-separated.  The supported
             ciphers are ``3des-cbc'', ``aes128-cbc'', ``aes192-cbc'',
             ``aes256-cbc'', ``aes128-ctr'', ``aes192-ctr'',
             ``aes256-ctr'', ``arcfour128'', ``arcfour256'',
             ``arcfour'', ``blowfish-cbc'', and ``cast128-cbc''.  The
             default is:

                aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,
                arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr,
                aes192-ctr,aes256-ctr

The comment in the upstream advisory is essentially just reordering the
CTR ones to the front and dropping some of them (3des-cbc, blowfish-cbc,
cast128-cbc, arcfour128, aes192-cbc, aes192-ctr). I don't pretend to
know which of these are most widely-supported, but it seems clear to me
that one could improve safety with a relatively small chance of losing a
cipher you actually needed with:

  Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc

(for example).

If the server didn't support any of those, then I imagine you'd just get
a complete failure.

> How would one go about asking the ssh-server something like:
> 
>   What ciphers are you capable of?
> 
> from a batch job?

Sorry, I don't know of a way to do that, although you could probably get
it from 'ssh -vvv' output.

I'm not going to spend much time on this given that upstream doesn't
think it's serious. I tend to agree having read their analysis, too: if
it takes you several tens of thousands of attempts to connect
successfully, then you should probably consider whether somebody is
mucking about with your connection rather than continuing to type in
your password ...

Cheers,

-- 
Colin Watson                                       [cjwatson@debian.org]