Security problem in GnuTLS v1.2.0 and earlier [GNUTLS-SA-2010-1]

Simon Josefsson simon at
Thu Mar 25 09:21:27 CET 2010

GnuTLS version 1.2.0 and earlier (released on 2005-01-27) on 64-bit
platforms are vulnerable to a bug described in:

Please note that the problem was solved for GnuTLS 1.2.1, released on
2005-04-04.  Also, 32-bit platforms are not affected.  I have added
information about this on

so that it contains the complete list of known security flaws.  I'm
using the keyword GNUTLS-SA-2010-1 for this.

Thanks to Tomas Hoger and the RedHat team for finding and tracking down
this problem.  I have given this bug a 'Remote Denial of Service'
severity, but if anyone has time to look at this bug, justification for
any other severity is welcome.


Tomas Hoger      2010-03-12 11:16:28 EST

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 gnutls_x509_crt_get_serial(), which calls
asn1_read_value() to extract serial number from the x509 certificate.

 526 int gnutls_x509_crt_get_serial(gnutls_x509_crt cert, void* result,
 527     size_t* result_size)
 528 {
 536     if ((ret = asn1_read_value(cert->cert, "tbsCertificate.serialNumber",
result, result_size)) < 0) {

asn1_read_value() expects pointer to int (32 bit) as its third argument, but
gnutls_x509_crt_get_serial() passed pointer to size_t (64 bit on 64 bit
platforms) instead.  On 64bit big endian platforms asn1_read_value() got
incorrect length value.

 598 asn1_retCode
 599 asn1_read_value(node_asn *root,const char *name,void* ivalue, int *len)

On little endian 64 bit platforms, high 32 bits of the *result_size size_t
value were lost, but they only contained zeros.  On big endian 64 bit
platforms, low 32 bits were lost / ignored, causing asn1_read_value() to see
length value as 0.  This caused asn1_read_value() to return an error, but the
length of the value that should have been extracted was saved to *len.

gnutls_x509_crt_get_serial() did not correctly check return value of
asn1_read_value(), failing to detect an error.  After returning, caller could
see a high value stored in *result_size (when interpreted as 64 bit value

print_x509_info() (used by gnutls-cli or gnutls-serv) and
print_certificate_info() (used by certtool) relied on the returned size value. 
Unexpected value caused a stack buffer overflow in those functions.

This bug could also cause gnutls_x509_crt_check_revocation() 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:

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.

Comment 2 Tomas Hoger 2010-03-25 03:57:43 EDT

Making bug public.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 420 bytes
Desc: not available
URL: </pipermail/attachments/20100325/53dfd5fa/attachment.pgp>

More information about the Gnutls-help mailing list