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 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
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.