A flaw was found in the way GnuTLS parsed session ids from Server Hello packets of the TLS/SSL handshake. A malicious server could use this flaw to send an excessively long session id value and trigger a buffer overflow in a connecting TLS/SSL client using GnuTLS, causing it to crash or, possibly, execute arbitrary code.

The flaw is in readserverhello() / gnutlsreadserverhello(), where sessionidlen is checked to not exceed incoming packet size, but not checked to ensure it does not exceed maximum session id length: https://www.gitorious.org/gnutls/gnutls/source/8d7d6c6:lib/gnutlshandshake.c#L1747

A NULL pointer dereference flaw was discovered in GnuTLS's gnutlsx509dnoidname(). The function, when called with the GNUTLSX509DNOIDRETURNOID flag, should not return NULL to its caller. However, it could previously return NULL when parsed X.509 certificates included specific OIDs.

The issue was corrected upstream using the following commit: https://www.gitorious.org/gnutls/gnutls/commit/d3648ebb04b650e6d20a2ec1fb839256b30b9fc6

The fix was first included in upstream versions 3.1.20 and 3.2.10: http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/7251 http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/7250

Affected function was introduced in GnuTLS version 3.0: http://gnutls.org/manual/htmlnode/X509-certificate-API.html#gnutls005fx509005fdn005foid005fname-1

The gnutls packages in Red Hat Enterprise Linux 6 and earlier include GnuTLS versions 2.x or 1.x and were therefore not affected by this issue. The gnutls and mingw-gnutls packages in Fedora are already updated to the fixed upstream version.

It was discovered that GnuTLS X.509 certificate verification code failed to properly handle certain errors that can occur during the certificate verification. When such errors are encountered, GnuTLS would report successful verification of the certificate, even though verification should end with failure. A specially-crafted certificate can be accepted by GnuTLS as valid even if it wasn't issued by any trusted Certificate Authority. This can be used to perform man-in-the-middle attacks against applications using GnuTLS.

It was reported [1] that a version 1 intermediate certificate would be considered as a CA certificate by GnuTLS by default. This certificate verification behaviour deviates from the documented behaviour.

Upstream notes that this only affects individuals or organizations who have a CA that issues X.509 version 1 certificates in their trusted list.

This has been fixed upstream [2] in version 3.1.21 and 3.2.11.

At a quick look at the code of GnuTLS 2.8.5, it is affected. 1.4.1 looks affected to me as well.

[1] http://www.gnutls.org/security.html [2] https://www.gitorious.org/gnutls/gnutls/commit/b1abfe3d18

Off-by-one error in the danerawtlsa in the DANE library (libdane) in GnuTLS 3.1.x before 3.1.16 and 3.2.x before 3.2.6 allows remote servers to cause a denial of service (memory corruption) via a response with more than four DANE entries. NOTE: this issue is due to an incomplete fix for CVE-2013-4466.

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:

http://www.isg.rhul.ac.uk/tls/TLStiming.pdf

External References:

http://www.isg.rhul.ac.uk/tls/ http://www.gnutls.org/security.html#GNUTLS-SA-2013-1

Patches:

2.12.x: https://gitorious.org/gnutls/gnutls/commit/458c67cf98740e7b12404f6c30e0d5317d56fd30 https://gitorious.org/gnutls/gnutls/commit/93b7fcfa3297a9123630704668b2946f602b910e

3.0.x: https://gitorious.org/gnutls/gnutls/commit/8dc2822966f64dd9cf7dde9c7aacd80d49d3ffe5

3.2.x / master: https://gitorious.org/gnutls/gnutls/commit/328ee22c1b3951e060c7124c7cb1cee592c59bc0