Description of problem: OpenSSH has a security flaw which, if exploited, the 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 recovers 14 bits of plaintext with probability 2^{-14}. The success probability of the attack for other implementations of SSH is not known. Article here: http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt And Version-Release number of selected component (if applicable): 4.8p1 and earlier How reproducible: Always Steps to Reproduce: 1. See URLs for details. 2. 3. Actual results: This is not supposed to happen... Expected results: but it happens. Additional info: Although this is a security-sensitive bug, it is now widely known, in part due to the info given on the SANS Internet Storm Center.
(In reply to comment #0) > Version-Release number of selected component (if applicable): 4.8p1 and earlier That should read 4.7p1 and earlier, sorry for the typo.
It is inherent weakness of the ssh2 protocol. You can overcome it by using only the aes ctr mode ciphers.
Tomas, Should I close this bug, then?
I'm moving this bug to the Security Response product for proper tracking.
Created attachment 324169 [details] CPNI Advisory (saved for posterity sake)
OpenSSH upstream advisory / statement regarding this issue: http://openssh.org/txt/cbc.adv
OpenSSH upstream mitigation patch, reducing success probability to 2^-18: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/packet.c.diff?r1=1.157;r2=1.158;f=h
After reviewing the upstream fix for this issue, Red Hat does not intent to address this flaw at this time. A future update may address this issue.
Upstream further extended the mitigations in version 5.2: http://openssh.com/txt/release-5.2 * 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". Which refers to upstream commit: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/myproposal.h.diff?r1=1.22;r2=1.23;f=h * 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. Which refers to upstream commits: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/cipher.c.diff?r1=1.81;r2=1.82;f=h http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/cipher.h.diff?r1=1.36;r2=1.37;f=h http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/packet.c.diff?r1=1.158;r2=1.159;f=h
*** Bug 498957 has been marked as a duplicate of this bug. ***
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2009:1287 https://rhn.redhat.com/errata/RHSA-2009-1287.html
Statement: This issue was addressed for Red Hat Enterprise Linux 5 by https://rhn.redhat.com/errata/RHSA-2009-1287.html After reviewing the upstream fix for this issue, Red Hat does not intend to address this flaw in Red Hat Enterprise Linux 4.