Double free vulnerability in libgnutls in GnuTLS before 3.0.14 allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a crafted certificate list.
During the testing of GnuTLS updates, a flaw was discovered affecting Red Hat Enterprise Linux 4 GnuTLS packages on s390x platform, causing gnutls-cli to crash while printing server certificate info.
This crash was caused by a flaw in gnutlsx509crtgetserial(), which calls asn1readvalue() to extract serial number from the x509 certificate.
(lib/x509/x509.c) 526 int gnutlsx509crtgetserial(gnutlsx509crt cert, void result, 527 sizet resultsize) 528 { ... 536 if ((ret = asn1readvalue(cert->cert, "tbsCertificate.serialNumber", result, resultsize)) < 0) {
asn1readvalue() expects pointer to int (32 bit) as its third argument, but gnutlsx509crtgetserial() passed pointer to sizet (64 bit on 64 bit platforms) instead. On 64bit big endian platforms asn1readvalue() got incorrect length value.
(lib/minitasn1/element.c) 598 asn1retCode 599 asn1readvalue(nodeasn root,const char name,void ivalue, int len)
On little endian 64 bit platforms, high 32 bits of the resultsize sizet value were lost, but they only contained zeros. On big endian 64 bit platforms, low 32 bits were lost / ignored, causing asn1readvalue() to see length value as 0. This caused asn1readvalue() to return an error, but the length of the value that should have been extracted was saved to len.
gnutlsx509crtgetserial() did not correctly check return value of asn1readvalue(), failing to detect an error. After returning, caller could see a high value stored in resultsize (when interpreted as 64 bit value again).
printx509info() (used by gnutls-cli or gnutls-serv) and printcertificateinfo() (used by certtool) relied on the returned size value. Unexpected value caused a stack buffer overflow in those functions.
This bug could also cause gnutlsx509crtcheckrevocation() to incorrectly check supplied X509 certificate against the list of revoked certificates, resulting in a bypass or the CRL check.
This issue was fixed upstream via following commit: http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=112d537d
This fix was first included in upstream version 1.2.1. Therefore, GnuTLS packages in Red Hat Enterprise Linux 5, Fedora, and current upstream GnuTLS versions are not affected by this flaw.
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.
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".