Bug 446442 (CVE-2008-5161) - VUL-0: CVE-2008-5161: openssh: Plaintext Recovery Attack Against SSH
Summary: VUL-0: CVE-2008-5161: openssh: Plaintext Recovery Attack Against SSH
Status: RESOLVED UPSTREAM
Alias: CVE-2008-5161
Product: SUSE Security Incidents
Classification: Novell Products
Component: General (show other bugs)
Version: unspecified
Hardware: Other Other
: P5 - None : Normal
Target Milestone: ---
Deadline: 2008-12-17
Assignee: Anna Maresova
QA Contact: Security Team bot
URL:
Whiteboard: CVE-2008-5161: CVSS v2 Base Score: 2....
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-19 09:13 UTC by Ludwig Nussel
Modified: 2015-08-13 08:39 UTC (History)
2 users (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ludwig Nussel 2008-11-19 09:13:53 UTC
Your friendly security team received the following report via oss-security.
Please respond ASAP.
The issue is public.

CPNI Vulnerability Advisory SSH

Plaintext Recovery Attack Against SSH

Version Information
-------------------
Advisory Reference CPNI-957037 
Release Date	   14/11/08
Last Revision	   17/11/08 
Version Number	   2.0 - Changes to Impact and Summary sections. Version History added. Vendor details added
Version History    

Acknowledgement
---------------

This issue was reported by Martin Albrecht, Kenny Paterson and Gaven Watson
from the Information Security Group at Royal Holloway, University of London.

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.

Severity 
--------

The severity is considered to be potentially HIGH due to the
32 bits of plaintext that can be recovered. However, the 
likelihood of a successful attack is considered LOW.


Summary
-------

Secure Shell or SSH is a network protocol that allows data to be
exchanged using a secure channel between two networked devices. A
design flaw in the SSH specification allows an attacker with control
over the network to recover up to 32 bits of plaintext from an
SSH-protected connection in the standard configuration. The success
probability in recovering 32 plaintext bits is 2^{-18} when attacking 
the OpenSSH implementation of the SSH RFCs. A variant of the attack
against the OpenSSH implementation verifiably recovers 14 plaintext bits with
probability 2^{-14}. The recovered bits come from an arbitrary,
attacker-selected block of ciphertext. The success probabilities for 
other implementations are unknown (but are potentially much higher).

Details
-------

The attack works by analysing the behaviour of the SSH connection
when handling certain types of errors.

The attack was tested against the OpenSSH implementation of the SSH
RFCs. 

We expect any RFC-compliant SSH implementation to be vulnerable
to some form of the attack.

The attacks lead to the tear down of the SSH connection, meaning that
they cannot directly be iterated to increase the success probability. 
However, the SSH architectural RFC (RFC 4251) states that the SSH 
connection should be re-established in the event of errors. So, if
SSH were used to protect a fixed plaintext across multiple connections,
and connections were automatically re-established in compliance with RFC 
4251, then the success probability could be increased.

Solution
--------

The most straightforward solution is to use CTR mode instead
of CBC mode, since this renders SSH resistant to the attack. An RFC 
already exists to standardise counter mode for use in SSH (RFC 4344) 
and AES in counter mode is supported by OpenSSH. A switch to AES in counter
mode could most easily be enforced by limiting which encryption
algorithms are offered during the ciphersuite negotiation that takes
place as part of the SSH key exchange (see RFC 4253, Section 7.1).


Vendor Information
------------------
Buffalo not vulnerable

SSH Communications Security has released the following advisory on its website.
http://www.ssh.com/company/news/article/953/


Credits
-------

CPNI  would like to thank Martin Albrecht, Kenny Paterson and 
Gaven Watson from the Information Security Group at 
Royal Holloway, University of London for reporting these issues. 

Please visit http://www.isg.rhul.ac.uk for details about the 
Information Security Group at Royal Holloway


Contact Information
-------------------
Centre for the Protection of National Infrastructure (CPNI).
Email: csirtuk@cpni.gsi.gov.uk

For sensitve information the CSIRTUK PGP key is available from:
http://www.cpni.gov.uk/key.aspx

 
What is CPNI?
--------------
For further information regarding the Centre for the Protection of
National Infrastructure, please visit http://www.cpni.gov.uk.
 
Reference to any specific commercial product, process, or service by
trade name, trademark manufacturer, or otherwise, does not constitute
or imply its endorsement, recommendation, or favouring by CPNI. The
views and opinions of authors expressed within this notice shall not
be used for advertising or product endorsement purposes.

Neither shall CPNI accept responsibility for any errors or omissions
contained within this advisory. In particular, they shall not be
liable for any loss or damage whatsoever, arising from or in
connection with the usage of information contained within this notice.

© 2008 Crown Copyright
Comment 1 Ludwig Nussel 2008-11-21 07:55:43 UTC
======================================================
Name: CVE-2008-5161
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5161
Reference: MISC:http://isc.sans.org/diary.html?storyid=5366
Reference: MISC:http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt
Reference: CONFIRM:http://www.ssh.com/company/news/article/953/
Reference: BID:32319
Reference: URL:http://www.securityfocus.com/bid/32319
Reference: FRSIRT:ADV-2008-3172
Reference: URL:http://www.frsirt.com/english/advisories/2008/3172
Reference: FRSIRT:ADV-2008-3173
Reference: URL:http://www.frsirt.com/english/advisories/2008/3173
Reference: OSVDB:49872
Reference: URL:http://osvdb.org/49872
Reference: SECTRACK:1021235
Reference: URL:http://www.securitytracker.com/id?1021235
Reference: SECTRACK:1021236
Reference: URL:http://www.securitytracker.com/id?1021236
Reference: SECUNIA:32740
Reference: URL:http://secunia.com/advisories/32740
Reference: SECUNIA:32760
Reference: URL:http://secunia.com/advisories/32760
Reference: XF:openssh-sshtectia-cbc-info-disclosure(46620)
Reference: URL:http://xforce.iss.net/xforce/xfdb/46620

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 2 Anna Maresova 2008-11-21 09:44:41 UTC
Wonderful :-(
But I think that we have to wait for an upstream fix anyway...
Comment 3 Ludwig Nussel 2008-11-21 13:36:01 UTC
http://openssh.org/txt/cbc.adv
Comment 4 Anna Maresova 2008-11-21 15:07:16 UTC
Well, I can change default configuration as is supposed for stable, but what can I do for released products? Changing our customer's config files is probably not a good idea - what is your opinion?
Comment 5 Ludwig Nussel 2008-11-21 15:09:55 UTC
IMHO it's ok to not change anything atm and only pick up a new openssh in the future for future products
Comment 6 Anna Maresova 2008-11-24 12:18:14 UTC
Fine, so I am closing it.
Comment 7 Thomas Biege 2009-10-14 01:46:56 UTC
CVE-2008-5161: CVSS v2 Base Score: 2.6 (AV:N/AC:H/Au:N/C:P/I:N/A:N)