A vulnerability exists in SSH messages that employ CBC mode that may allow an attacker to recover plaintext from a block of ciphertext.
The Secure Shell (SSH) is a network protocol that creates a secure channel between two networked devices in order to allow data to be exchanged. SSH can create this secure channel by using Cipher Block Chaining (CBC) mode encryption. This mode adds a feedback mechanism to a block cipher that operates in a way that ensures that each block is used to modify the encryption of the next block.
SSH contains a vulnerability in the way certain types of errors are handled. Attacks leveraging this vulnerabilty would lead to the loss of the SSH session. According to CPNI Vulnerability Advisory SSH:
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.
An attacker may be able to recover up to 32 bits of plaintext from an arbitrary block of ciphertext.
We are currently unaware of a practical solution to this problem.
Use CTR Mode
SSH can be done using Counter (CTR) mode encryption. This mode generates the keystream by encrypting successive values of a “counter” function. For more information see the Block Cipher Modes article on wikipedia.
In order to mitigate this vulnerabilty SSH can be setup to use CTR mode rather CBC mode. According to CPNI Vulnerability Advisory SSH:
_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) … _
958563
Filter by status: All Affected Not Affected Unknown
Filter by content: __ Additional information available
__ Sort by: Status Alphabetical
Expand all
Javascript is disabled. Click here to view vendors.
Notified: November 07, 2008 Updated: November 24, 2008
Affected
We have not received a statement from the vendor.
The vendor has not provided us with any further information regarding this vulnerability.
Notified: November 07, 2008 Updated: November 24, 2008
Affected
We have not received a statement from the vendor.
The vendor has not provided us with any further information regarding this vulnerability.
Notified: November 07, 2008 Updated: November 24, 2008
Affected
We have not received a statement from the vendor.
The vendor has not provided us with any further information regarding this vulnerability.
Notified: November 07, 2008 Updated: November 24, 2008
Affected
We have not received a statement from the vendor.
The vendor has not provided us with any further information regarding this vulnerability.
Notified: November 07, 2008 Updated: November 24, 2008
Affected
We have not received a statement from the vendor.
The vendor has not provided us with any further information regarding this vulnerability.
Notified: November 07, 2008 Updated: January 05, 2009
Affected
The latest release (0.60) of PuTTY will always preferentially select CTR-mode ciphers over CBC-mode, and cannot even be configured by the user to do otherwise. Therefore, it is immune to this vulnerability when talking to any server which supports CTR mode.
Development snapshots of PuTTY beginning with 2008-11-27 will contain a countermeasure which avoids leaking information through this attack even when operating in CBC mode. Future releases of PuTTY will also contain this countermeasure.
(That is, the countermeasures will prevent PuTTY from leaking information about data previously sent from the server to the client. Protecting data sent from client to server, such as passwords, must be done by the server.)
We are currently not treating this vulnerability as severe enough to warrant an emergency security release.
The vendor has not provided us with any further information regarding this vulnerability.
Notified: November 07, 2008 Updated: November 24, 2008
Affected
We have not received a statement from the vendor.
The vendor has not provided us with any further information regarding this vulnerability.
Notified: November 07, 2008 Updated: November 24, 2008
Affected
We have not received a statement from the vendor.
The vendor has not provided us with any further information regarding this vulnerability.
Notified: November 07, 2008 Updated: November 24, 2008
Affected
We have not received a statement from the vendor.
The vendor has not provided us with any further information regarding this vulnerability.
Notified: November 07, 2008 Updated: January 12, 2009
Affected
VShell® version 3.5.1 and earlier, SecureCRT® version 6.1.2 and earlier, SecureFX® version 6.1.2 and earlier, and VanDyke ClientPack 6.1.2 and earlier are potentially vulnerable to this attack.
The advisory recommends using the AES cipher in CTR mode rather than CBC mode. VShell for some platforms, SecureCRT, SecureFX, and the VanDyke ClientPack for some platforms now prefer the AES cipher in CTR mode by default. Please see the following web page for more information.
<http://www.vandyke.com/support/advisory/2008/12/cpni-957037.html>
Notified: November 07, 2008 Updated: November 24, 2008
Affected
We have not received a statement from the vendor.
The vendor has not provided us with any further information regarding this vulnerability.
View all 11 vendors __View less vendors __
Group | Score | Vector |
---|---|---|
Base | ||
Temporal | ||
Environmental |
Thanks to CPNI for reporting this vulnerability.
This document was written by Chris Taschner.
CVE IDs: | None |
---|---|
Severity Metric: | 0.30 Date Public: |