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.
** libgnutls: Corrections in record packet parsing.
Reported by Matthew Hall.
Additional details from the reporter are described as MU-201202-01 in:
Patch for 2.x:
Patch for 3.x:
@crypto, I believe this was fixed in >=net-libs/gnutls-2.12.17 for 2.x. Can we move forward and stabilize that? Thanks.
(In reply to comment #1)
> @crypto, I believe this was fixed in >=net-libs/gnutls-2.12.17 for 2.x. Can
> we move forward and stabilize that? Thanks.
I'd say =net-libs/gnutls-2.12.18 should go stable.
(In reply to comment #2)
> I'd say =net-libs/gnutls-2.12.18 should go stable.
Arches, please test and mark stable:
Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
#required by net-libs/gnutls-2.12.18[pkcs11], required by =net-libs/gnutls-2.12.18 (argument)
added Bug 409781 but probably could be done simply here, notice now that have the same maintainer, sorry
gnutls_cipher.c in libgnutls in GnuTLS before 2.12.17 and 3.x before 3.0.15
does not properly handle data encrypted with a block cipher, which allows
remote attackers to cause a denial of service (heap memory corruption and
application crash) via a crafted record, as demonstrated by a crafted
Stable for HPPA.
Thanks, everyone. Creating new GLSA request.
This issue was resolved and addressed in
GLSA 201206-18 at http://security.gentoo.org/glsa/glsa-201206-18.xml
by GLSA coordinator Sean Amoss (ackle).