Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 247466 (CVE-2008-5161) - <net-misc/openssh-5.2_p1: CPNI 32bit plaintext recovery (CVE-2008-5161)
Summary: <net-misc/openssh-5.2_p1: CPNI 32bit plaintext recovery (CVE-2008-5161)
Alias: CVE-2008-5161
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High minor (vote)
Assignee: Gentoo Security
Whiteboard: A4 [glsa]
: 247692 (view as bug list)
Depends on:
Reported: 2008-11-18 18:38 UTC by Stefan Behte (RETIRED)
Modified: 2014-05-11 13:56 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Behte (RETIRED) gentoo-dev Security 2008-11-18 18:38:18 UTC
From the CPNI advisory:

What is affected?
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.


If exploited, this attack can potentially allow an attacker to
recover up to 32 bits of plaintext from an arbitrary block of 
ciphertext from a connection secured using the SSH protocol in 
the standard configuration. If OpenSSH is used in the standard 
configuration, then the attacker's success probability for 
recovering 32 bits of plaintext is 2^{-18}. A variant of the 
attack against OpenSSH in the standard configuration can verifiably recover 14 
bits of plaintext with probability 2^{-14}. The success probability 
of the attack for other implementations of SSH is not known.
Comment 1 Stefan Behte (RETIRED) gentoo-dev Security 2008-11-18 18:41:39 UTC
Also see:
I've got no further information available.
Comment 2 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-11-18 21:40:17 UTC
craig: nothing for LPK here, removing myself.
Comment 3 stupendoussteve 2008-11-18 22:22:13 UTC
It appears that base-system is the herd for this.
Comment 4 SpanKY gentoo-dev 2008-11-18 22:32:58 UTC
unless it affects openssh-5.1_p1, we dont really care ... we dont track/issue GLSA's for versions older than current stable
Comment 5 Doug Goldstein (RETIRED) gentoo-dev 2008-11-18 22:37:47 UTC
We should at the very least remove versions with known security issues from the tree.
Comment 6 SpanKY gentoo-dev 2008-11-18 22:44:12 UTC
not necessarily.  older versions of important packages (like openssh) are left in the tree on purpose even if they have issues.  allowing admins the flexibility to quickly address things on their side takes precedence.

if you wish to p.mask versions with known issues, feel free.  i dont care that much seeing as how people who are actively running older versions will most likely continue to do so even in the face of security issues.
Comment 7 stupendoussteve 2008-11-18 22:51:36 UTC
According to the advisory, it is known to affect 4.7p1 but other versions are probably affected as it appears to be a vulnerability in the behavior per RFC, not necessarily a bug in the product itself.

The suggested solution from the secunia advisory ( ) is "Allow only CTR (Counter) mode cipher
algorithms (e.g. AES-CTR) to be used in an SSH session."

Maybe a default config issue?
Comment 8 SpanKY gentoo-dev 2008-11-18 23:04:06 UTC
this is the point where we let the security team figure things out and then let the maintainer(s) know the result ...
Comment 9 Robert Buchholz (RETIRED) gentoo-dev 2008-11-19 15:15:06 UTC
The attack allows to recover 32 bit with probability 2^-18, requires read and write access to the medium and destroys the connection. Thus, as stated by the advisory, exploitation is highly unlikely.
It seems OpenSSH 5.1 is affected as well, since they did not change default cipher suites since 4.7. However, I would not change Gentoo's default cipher if upstream does not go with that change as well. So let's see how they deal with the issue.

For reference, the Debian and RH bug reports:

OpenBSD maintainer does not seem to take this issue too serious:
Comment 10 Stefan Behte (RETIRED) gentoo-dev Security 2008-11-20 09:43:30 UTC
CVE-2008-5161 (
  Error handling in the SSH protocol in (1) SSH Tectia Client and
  Server and Connector 4.0 through 4.4.11, 5.0 through 5.2.4, and 5.3
  through 5.3.8; Client and Server and ConnectSecure 6.0 through 6.0.4;
  Server for Linux on IBM System z 6.0.4; Server for IBM z/OS 5.5.1 and
  earlier, 6.0.0, and 6.0.1; and Client 4.0-J through 4.3.3-J and 4.0-K
  through 4.3.10-K; and (2) OpenSSH 4.7p1 and possibly other versions,
  when using a block cipher algorithm in Cipher Block Chaining (CBC)
  mode, makes it easier for remote attackers to recover certain
  plaintext data from an arbitrary block of ciphertext in an SSH
  session via unknown vectors.

Comment 11 Robert Buchholz (RETIRED) gentoo-dev 2008-11-20 12:19:52 UTC
*** Bug 247692 has been marked as a duplicate of this bug. ***
Comment 12 Robert Buchholz (RETIRED) gentoo-dev 2008-11-24 00:08:23 UTC
Upstream issued the following statement [ ]
> 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.
Comment 13 Robert Buchholz (RETIRED) gentoo-dev 2009-02-23 12:09:49 UTC

OpenSSH 5.2 has just been released. It will be available from the
mirrors listed at shortly.
 * This release changes the default cipher order to prefer the AES CTR
   modes and the revised "arcfour256" mode to CBC mode ciphers that are
   susceptible to CPNI-957037 "Plaintext Recovery Attack Against SSH".

 * This release also adds countermeasures to mitigate CPNI-957037-style
   attacks against the SSH protocol's use of CBC-mode ciphers. Upon
   detection of an invalid packet length or Message Authentication
   Code, ssh/sshd will continue reading up to the maximum supported
   packet length rather than immediately terminating the connection.
   This eliminates most of the known differences in behaviour that
   leaked information about the plaintext of injected data which formed
   the basis of this attack. We believe that these attacks are rendered
   infeasible by these changes.
Comment 14 SpanKY gentoo-dev 2009-02-24 17:02:48 UTC
so 5.2_p1 is in the tree, but i dont think this issue warrants a stable bumping
Comment 15 Robert Buchholz (RETIRED) gentoo-dev 2009-02-25 16:55:47 UTC
(In reply to comment #14)
> so 5.2_p1 is in the tree, but i dont think this issue warrants a stable bumping

Can we target a 15 or 30 day stabling? This update would also fix some other bugs for stable users (as the double MOTD I see on my machines these days).
Comment 16 SpanKY gentoo-dev 2009-02-25 18:23:35 UTC
while the ldap/x509 patch have been updated, the hpn patchset has not

the changes here cannot be backported to 5.1_p1 via config updates ?
Comment 18 SpanKY gentoo-dev 2009-02-25 21:33:30 UTC
in other words, the changes arent trivial

my understanding is that the attack vector is not trivial to setup let alone actually leverage, so this isnt a terribly critical issue.  it's more of a "we are paranoid to the extreme so let's get it right" (i'm not saying this is a bad thing btw).

so i'd prefer we wait for hpn/30 days ... if hpn isnt updated, then stabilizing without it is OK ...
Comment 19 Robert Buchholz (RETIRED) gentoo-dev 2009-02-26 01:17:04 UTC
Comment 20 SpanKY gentoo-dev 2009-03-21 12:00:17 UTC
welp, we gave hpn time and still no love.  feel free to stabilize 5.2_p1-r1 as i havent seen any regressions reported against it.
Comment 21 Robert Buchholz (RETIRED) gentoo-dev 2009-04-02 12:42:47 UTC
Arches, please test and mark stable:
Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
Comment 22 Jeroen Roovers (RETIRED) gentoo-dev 2009-04-02 17:07:52 UTC
Stable for HPPA.
Comment 23 Brent Baude (RETIRED) gentoo-dev 2009-04-02 18:48:47 UTC
ppc64 and ppc stable
Comment 24 Markus Meier gentoo-dev 2009-04-02 21:54:12 UTC
amd64/x86 stable
Comment 25 Raúl Porcel (RETIRED) gentoo-dev 2009-04-04 15:44:59 UTC
alpha/arm/ia64/m68k/s390/sh/sparc stable
Comment 26 Robert Buchholz (RETIRED) gentoo-dev 2009-04-05 14:54:21 UTC
this needs a glsa vote. Due to the unlikely and limited value of the success, I'm tempted to say no. However, since SSH is a very crucial system package, we might want to relay the change in defaults. So I tend for a yes.
Comment 27 Tobias Heinlein (RETIRED) gentoo-dev 2009-04-14 20:12:43 UTC
YES too, request filed.
Comment 28 GLSAMaker/CVETool Bot gentoo-dev 2014-05-11 13:56:28 UTC
This issue was resolved and addressed in
 GLSA 201405-06 at
by GLSA coordinator Mikle Kolyada (Zlogene).