Re: Bug#506115: openssh: Plaintext Recovery Attack Against SSH
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
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
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:
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 ...
Colin Watson [email@example.com]