A heap-buffer-overread vulnerability exists in GnuTLS (confirmed in version 3.8.9) due to unsafe handling of the Certificate Transparency (CT) Signed Certificate Timestamp (SCT) extension during X.509 certificate parsing. The vulnerability can be triggered by a malicious peer presenting a crafted certificate containing a malformed SCT extension (OID 1.3.6.1.4.1.11129.2.4.2). This overread may lead to disclosure of heap memory contents to attackers if the SCT logid is logged, exported, or otherwise exposed by the application consuming the GnuTLS client library.

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

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.

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.

A NULL pointer dereference flaw was found in libtasn1's asn1readvaluetype() / asn1readvalue() function. If an application called the function with a NULL value for an ivalue argument to determine the amount of memory needed to store data to be read from the ASN.1 input, libtasn1 could incorrectly attempt to dereference the NULL pointer, causing an application using the library to crash.

The libtasn1 library is used by the GnuTLS library to parse X.509 certificates. The gnutls packages in Red Hat Enterprise Linux 5 and earlier use bundled libtasn1, packages in Red Hat Enterprise Linux 6 and later depend on the library provided by a separate libtasn1 package.

Upstream commits: http://git.savannah.gnu.org/cgit/libtasn1.git/commit/lib/element.c?id=a8b3e14f84174e01755bfd1be5448fffce7c9ffa http://git.savannah.gnu.org/cgit/libtasn1.git/commit/lib/element.c?id=3d6a02f19ff15a38dae9686033e37499b3968256 http://git.savannah.gnu.org/cgit/libtasn1.git/commit/lib/element.c?id=53958290ab731c8486531a3bdef54a933533579d

Multiple buffer boundary check issues were discovered in libtasn1 library, causing it to read beyond the boundary of an allocated buffer. An untrusted ASN.1 input could cause an application using the library to crash.

The libtasn1 library is used by the GnuTLS library to parse X.509 certificates. The gnutls packages in Red Hat Enterprise Linux 5 and earlier use bundled libtasn1, packages in Red Hat Enterprise Linux 6 and later depend on the library provided by a separate libtasn1 package.

Upstream commits: http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=ff3b5c68cc32e30d19edbbc3a962b2266029f3cc http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=0e80d79db71747644394fe3472dad28cd3e7b00b http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=154909136c12cfa5c60732b7210827dfb1ec6aee http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=37a16434131c6ad8745b9accefec5cecb4cbb5b7 http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=cc10a8c5443c751d920cfaca1f104089e43296be http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=6fee6745b1bd1a82f16ae9b607855a3e3ab39fc6 http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=af0e8cd0bacf47ecce049165d3bc1ed9e861df1c http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=609d5c1366fb424f6150c4eed358d246e61cf204 http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=51612fca32dda445056ca9a7533bae258acd3ecb

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

GnuTLS before 2.7.6, when the GNUTLSVERIFYALLOWX509V1CACRT flag is not enabled, treats version 1 X.509 certificates as intermediate CAs, which allows remote attackers to bypass intended restrictions by leveraging a X.509 V1 certificate from a trusted CA to issue new certificates, a different vulnerability than CVE-2014-1959.

The gnutlsx509oid2macalgorithm function in lib/gnutlsalgorithms.c in GnuTLS before 1.4.2 allows remote attackers to cause a denial of service (crash) via a crafted X.509 certificate that uses a hash algorithm that is not supported by GnuTLS, which triggers a NULL pointer dereference.

A vulnerability was found that the response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from response times of ciphertexts with correct PKCS#1 v1.5 padding.

A NULL pointer dereference flaw was found in GnuTLS. As Nettle's hash update functions internally call memcpy, providing zero-length input may cause undefined behavior. This flaw leads to a denial of service after authentication in rare circumstances.

It was found that GnuTLS implementation of HMAC-SHA-256 was vulnerable to Lucky thirteen style attack due to the fact that not enough dummy compression function calls are added to cater for every situation.

It was found that GnuTLS implementation of HMAC-SHA-384 was vulnerable to Lucky thirteen style attack due to use of wrong constant appropriate to hash functions that encode the length field.

A cache-based side channel in GnuTLS implementation that leads to plain text recovery in cross-VM attack setting was found. An attacker could use a combination of "Just in Time" Prime+probe attack in combination with Lucky-13 attack to recover plain text using crafted packets.

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.

The "record packet parsing" in GnuTLS 1.2 before 1.2.3 and 1.0 before 1.0.25 allows remote attackers to cause a denial of service, possibly related to padding bytes in gnutilscipher.c.

verify.c in GnuTLS before 1.4.4, when using an RSA key with exponent 3, does not properly handle excess data in the digestAlgorithm.parameters field when generating a hash, which allows remote attackers to forge a PKCS #1 v1.5 signature that is signed by that RSA key and prevents GnuTLS from correctly verifying X.509 and other certificates that use PKCS, a variant of CVE-2006-4339.

libtasn1 version 2.12 was released fixing the following issue:

- Corrected DER decoding issue (reported by Matthew Hall). Added self check to detect the problem, see tests/Testoverflow.c. This problem can lead to at least remotely triggered crashes, see further analysis on the libtasn1 mailing list.

http://thread.gmane.org/gmane.comp.gnu.libtasn1.general/53

Upstream and few limited details are available at:

http://thread.gmane.org/gmane.comp.gnu.libtasn1.general/54

The behavior of asn1getlengthder was changed to protect against accidental incorrect use, if though it was previously "working properly and as documented".

GnuTLS 3.0.15 was released fixing the following issue:

libgnutls: Corrections in record packet parsing. Reported by Matthew Hall. http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/5912

Patch for 2.x: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=422214868061370aeeb0ac9cd0f021a5c350a57d

Patch for 3.x: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=b495740f2ff66550ca9395b3fda3ea32c3acb185

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

GnuTLS incorrectly validates the first byte of padding in CBC modes