CVE-2013-1624: Medium severity bouncycastle Legion-of-the-bouncy-castle-java-crytography-api vulnerability
A flaw in how TLS/DTLS, when CBC-mode encryption is used, communicates was reported. This vulnerability can allow for a Man-in-the-Middle attacker to recover plaintext from a TLS/DTLS connection, when CBC-mode encryption is used.
This flaw is in the TLS specification, and not a bug in a specific implementation (as such, it affects nearly all implementations). As such, it affects all TLS and DTLS implementations that are compliant with TLS 1.1 or 1.2, or with DTLS 1.0 or 1.2. It also applies to implementations of SSL 3.0 and TLS 1.0 that incorporate countermeasures to deal with previous padding oracle attacks. All TLS/DTLS ciphersuites that include CBC-mode encryption are potentially vulnerable.
The paper indicates that with OpenSSL, a full plaintext recovery attack is possible, and with GnuTLS, a partial plaintext recovery is possible (recovering up to 4 bits of the last byte in any block of plaintext).
To perform a successful attack, when TLS is used, a large number of TLS sessions are required (target plaintext must be sent repeatedly in the same position in the plaintext stream across the sessions). For DTLS, a successful attack can be carried out in a single session. The attacker must also be located close to the machine being attacked.
Further details are noted in the paper.
Current status of fixes in various implementations:
OpenSSL has a patch in development NSS has a patch in development GnuTLS is fixed in versions 2.12.23, 3.0.28, and 3.1.7 PolarSSL is fixed in version 1.2.5 BouncyCastle has a patch that will be included in the forthcoming 1.48 version
External References:
http://www.isg.rhul.ac.uk/tls/ http://www.isg.rhul.ac.uk/tls/TLStiming.pdf
Other sources
Bouncy Castle could allow a remote attacker to obtain sensitive information, caused by the exposure of timing differences during padding check verification by the CBC ciphersuite of the Transport Layer Security (TLS) implementation. An attacker could exploit this vulnerability using a timing attack to recover the original plaintext and obtain sensitive information.
— IBM
It was discovered that bouncycastle leaked timing information when decrypting TLS/SSL protocol encrypted records when CBC-mode cipher suites were used. A remote attacker could possibly use this flaw to retrieve plain text from the encrypted packets by using a TLS/SSL server as a padding oracle.
The TLS implementation in the Bouncy Castle Java library before 1.48 and C# library before 1.8 does not properly consider timing side-channel attacks on a noncompliant MAC check operation during the processing of malformed CBC padding, which allows remote attackers to conduct distinguishing attacks and plaintext-recovery attacks via statistical analysis of timing data for crafted packets, a related issue to CVE-2013-0169.
Affected Software
Event History
Parent advisories
This vulnerability appears in the following advisories.
Frequently Asked Questions
What is the severity of CVE-2013-1624?
CVE-2013-1624 is rated as a high-severity vulnerability due to its potential for a Man-in-the-Middle attack.
How do I fix CVE-2013-1624?
To fix CVE-2013-1624, it is recommended to update affected software to a version that disables CBC-mode in TLS/DTLS.
Which software is affected by CVE-2013-1624?
CVE-2013-1624 affects various versions of IBM GDE and multiple versions of the Bouncy Castle Crypto Package.
What type of attack does CVE-2013-1624 enable?
CVE-2013-1624 enables a Man-in-the-Middle attack, allowing the attacker to recover plaintext from a TLS/DTLS connection.
Is CVE-2013-1624 a design flaw?
Yes, CVE-2013-1624 is a design flaw in the TLS specification rather than a bug in a specific implementation.