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. Impact ------ 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.
Also see: http://secunia.com/advisories/product/5653/ I've got no further information available.
craig: nothing for LPK here, removing myself.
It appears that base-system is the herd for this.
unless it affects openssh-5.1_p1, we dont really care ... we dont track/issue GLSA's for versions older than current stable
We should at the very least remove versions with known security issues from the tree.
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.
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 ( http://secunia.com/advisories/32760/ ) is "Allow only CTR (Counter) mode cipher algorithms (e.g. AES-CTR) to be used in an SSH session." Maybe a default config issue?
this is the point where we let the security team figure things out and then let the maintainer(s) know the result ...
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: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506115 https://bugzilla.redhat.com/show_bug.cgi?id=472068 OpenBSD maintainer does not seem to take this issue too serious: http://www.nabble.com/Request:-Changing-algorithm-defaults-in-OpenSSH-%7C-CPNI-957037-td20550006.html
CVE-2008-5161 (http://nvd.nist.gov/nvd.cfm?cvename=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.
*** Bug 247692 has been marked as a duplicate of this bug. ***
Upstream issued the following statement [ http://www.openssh.com/txt/cbc.adv ] > 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.
http://www.openbsd.org/openssh/txt/release-5.2 OpenSSH 5.2 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ 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.
so 5.2_p1 is in the tree, but i dont think this issue warrants a stable bumping
(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).
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 ?
The countermeasures discussed in bullet point 2 are introduced in these patches: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/packet.c.diff?r1=1.157;r2=1.160;f=h;f=u http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/cipher.h.diff?r1=1.36;r2=1.37;sortby=date;f=h;f=u http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/cipher.c.diff?r1=1.81;r2=1.82;sortby=date;f=h;f=u Bullet point #1 is this config update: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/myproposal.h.diff?r1=1.22;r2=1.23;sortby=date;f=h;f=u and these documentation updates: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshd_config.5.diff?r1=1.99;r2=1.100;sortby=date;f=h;f=u http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh_config.5.diff?r1=1.115;r2=1.116;sortby=date;f=h;f=u http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh_config.diff?r1=1.24;r2=1.25;sortby=date;f=h;f=u
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 ...
agreed.
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.
Arches, please test and mark stable: =net-misc/openssh-5.2_p1-r1 Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
Stable for HPPA.
ppc64 and ppc stable
amd64/x86 stable
alpha/arm/ia64/m68k/s390/sh/sparc stable
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.
YES too, request filed.
This issue was resolved and addressed in GLSA 201405-06 at http://security.gentoo.org/glsa/glsa-201405-06.xml by GLSA coordinator Mikle Kolyada (Zlogene).