From $URL :
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
ebuild for version 1.2.5 added to main tree
(In reply to comment #1)
> ebuild for version 1.2.5 added to main tree
Arches, please test and mark stable.
Array index error in the SSL module in PolarSSL before 1.2.5 might allow
remote attackers to cause a denial of service via vectors involving a
crafted padding-length value during validation of CBC padding in a TLS
session, a different vulnerability than CVE-2013-0169.
GLSA vote: yes.
GLSA vote: yes
Added to existing GLSA request.
This issue was resolved and addressed in
GLSA 201310-10 at http://security.gentoo.org/glsa/glsa-201310-10.xml
by GLSA coordinator Sergey Popov (pinkbyte).