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. References: ** libgnutls: Corrections in record packet parsing. Reported by Matthew Hall. http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/5912 Additional details from the reporter are described as MU-201202-01 in: http://blog.mudynamics.com/2012/03/20/gnutls-and-libtasn1-vulns/ Patch for 2.x: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=422214868061370aeeb0ac9cd0f021a5c350a57d Patch for 3.x: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=b495740f2ff66550ca9395b3fda3ea32c3acb185
@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. Great, thanks. Arches, please test and mark stable: =net-libs/gnutls-2.12.18 Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
amd64: ok
#required by net-libs/gnutls-2.12.18[pkcs11], required by =net-libs/gnutls-2.12.18 (argument) =app-crypt/p11-kit-0.12 ~amd64 added Bug 409781 but probably could be done simply here, notice now that have the same maintainer, sorry
x86 stable
amd64: pass
amd64 stable
CVE-2012-1573 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-1573): 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 GenericBlockCipher structure.
Stable for HPPA.
ppc64 done
arm stable
alpha/ia64/m68k/s390/sh/sparc stable
ppc done
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).