[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#506115: openssh: Plaintext Recovery Attack Against SSH

severity 506115 normal

On Tue, Nov 18, 2008 at 02:40:48PM +0000, Colin Watson wrote:
> On Tue, Nov 18, 2008 at 10:44:02PM +0900, Hideki Yamane wrote:
> > Hi OpenSSH package maintainers (and lists),
> > 
> >  I saw new OpenSSH vulnerability issue.
> >  See http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt
> > 
> >  It says
> > "The attack was verified against the following product version running on Debian GNU/Linux:
> > 
> > - OpenSSH 4.7p1
> > 
> > Other versions are also affected. Other implementations of the SSH
> > protocol may also be affected."
> > 
> >  and upstream was reported this issue by CPNI (they say). IMHO, we should
> >  contact to upstream and wait to be put a solution from them.
> I'm aware of this and would be absolutely astonished if upstream
> weren't; I'm keeping an eye on CVS for an update.

Upstream have put out the following advisory notice now:


  OpenSSH Security Advisory: cbc.adv
  Regarding the "Plaintext Recovery Attack Against SSH" reported as
  The OpenSSH team has been made aware of an attack against the SSH
  protocol version 2 by researchers at the University of London.
  Unfortunately, due to the report lacking any detailed technical
  description of the attack and CPNI's unwillingness to share necessary
  information, we are unable to properly assess its impact.
  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, though we suspect this
  underestimates the work required by a practical attack.
  For most SSH usage scenarios, this attack has a very low likelihood of
  being carried out successfully - each attempt has a low probability
  of success and each failure will cause connection termination with a
  fatal error. It is therefore very unlikely for an interactive session
  to be usefully attacked using this protocol weakness: an attacker would
  expect around 32768 connection-killing attempts before they are likely
  to succeed. This level of disruption would certainly be noticed and it
  is highly unlikely that any user would retry the connection enough times
  for the attack to succeed.
  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.
  AES CTR mode and arcfour ciphers are not vulnerable to this attack at
  all. These may be preferentially selected by placing the following
  directive in sshd_config and ssh_config:
  Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc
  A future version of OpenSSH may make CTR mode ciphers the default and/or
  implement other countermeasures, but at present we do not feel that this
  issue is serious enough to make an emergency release.
  [1] http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt
  [2] http://www.cs.washington.edu/homes/yoshi/papers/TISSEC04/

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.

Colin Watson                                       [cjwatson@debian.org]

Reply to: