oss-sec mailing list archives

CVE request: GnuTLS TLS record handling issue / MU-201202-01


From: Stefan Cornelius <scorneli () redhat com>
Date: Wed, 21 Mar 2012 12:32:59 +0100

Hi,

Correcting myself as more details about the GnuTLS case were revealed:
GnuTLS needs a CVE after all, for another issue different from
CVE-2012-1569.

Quoting the Mu Dynamics advisory [1]:

The block cipher decryption logic in GnuTLS assumed that a record
containing any data which was a multiple of the block size was valid for
further decryption processing, leading to a heap corruption vulnerability.

The bug can be reproduced in GnuTLS 3.0.14 by creating a corrupt
GenericBlockCipher struct with a valid IV, while everything else is
stripped off the end, while the handshake message length retains its
original value: [...]

This will cause a segmentation fault, when the ciphertext_to_compressed
function tries to give decrypted data to _gnutls_auth_cipher_add_auth
for HMAC verification, even though the data length is invalid, and it
should have returned GNUTLS_E_DECRYPTION_FAILED or
GNUTLS_E_UNEXPECTED_PACKET_LENGTH instead, before
_gnutls_auth_cipher_add_auth was called.

NOTE: This CVE request is only for the GnuTLS TLS record handling issue
/ MU-201202-01. When looking at the release notes [2] and [3], there are
other issues that may be worthy of a CVE, but are currently still under
investigation:

** libgnutls: Eliminate double free during SRP
authentication. Reported by Peter Penzov.

** libgnutls: PKCS #11 objects that do not have ID
no longer crash listing. Reported by Sven Geggus.


-- References --

[1] Mu Dynamics:
http://blog.mudynamics.com/2012/03/20/gnutls-and-libtasn1-vulns/

[2] GnuTLS 3.0.15 release announcement:
http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/5912

[3] GnuTLS 2.12.17 release announcement:
http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/5910

[4] GNUTLS-SA-2012-2:
http://www.gnu.org/software/gnutls/security.html

[5] Red Hat bug:
https://bugzilla.redhat.com/show_bug.cgi?id=805432

Thanks and kind regards,
-- 
Stefan Cornelius / Red Hat Security Response Team


Current thread: