A vulnerability found in gnutls. This security flaw happens because of a double free error occurs during verification of pkcs7 signatures in gnutlspkcs7verify function.
A timing side-channel in the handling of RSA ClientKeyExchange messages was discovered in GnuTLS. This side-channel can be sufficient to recover the key encrypted in the RSA ciphertext across a network in a Bleichenbacher style attack. To achieve a successful decryption the attacker would need to send a large amount of specially crafted messages to the vulnerable server. By recovering the secret from the ClientKeyExchange message, the attacker would be able to decrypt the application data exchanged over that connection.
Modgnutls is a TLS module for Apache HTTPD based on GnuTLS. Versions from 0.9.0 to 0.12.0 (including) did not properly fail blocking read operations on TLS connections when the transport hit timeouts. Instead it entered an endless loop retrying the read operation, consuming CPU resources. This could be exploited for denial of service attacks. If trace level logging was enabled, it would also produce an excessive amount of log output during the loop, consuming disk space. The problem has been fixed in commit d7eec4e598158ab6a98bf505354e84352f9715ec, please update to version 0.12.1. There are no workarounds, users who cannot update should apply the errno fix detailed in the security advisory.
It was found an issue in certificate validation using OCSP responses caused by not verifying the serial length, which can falsely report a certificate as valid.
Upstream patch:
https://gitlab.com/gnutls/gnutls/commit/964632f37dfdfb914ebc5e49db4fa29af35b1de9
External References:
https://www.gnutls.org/security.html https://lists.gnupg.org/pipermail/gnutls-devel/2016-September/008146.html
Use-after-free vulnerability in the gnutlshandshakehashbuffersclear function in lib/gnutlshandshake.c in libgnutls in GnuTLS 2.3.5 through 2.4.0 allows remote attackers to cause a denial of service (crash) or possibly execute arbitrary code via TLS transmission of data that is improperly used when the peer calls gnutlshandshake within a normal session, leading to attempted access to a deallocated libgcrypt handle.
It was reported that under certain conditions modgnutls ignores "GnuTLSClientVerify require" when specified in directory [1] and server [2] context. Suggested commit that fixes [2] is: https://github.com/airtower-luna/modgnutls/commit/5a8a32bbfb8a83fe6358c5c31c443325a7775fc2 Patch for [1] is attaced in the corresponding bugreport.
[1]: http://issues.outoforder.cc/view.php?id=93 [2]: https://bugs.debian.org/578663
libgnutls in GnuTLS before 2.8.2 does not properly handle a '\0' character in a domain name in the subject's (1) Common Name (CN) or (2) Subject Alternative Name (SAN) field of an X.509 certificate, which allows man-in-the-middle attackers to spoof arbitrary SSL servers via a crafted certificate issued by a legitimate Certification Authority.
lib/gnutlspk.c in libgnutls in GnuTLS 2.5.0 through 2.6.5 generates RSA keys stored in DSA structures, instead of the intended DSA keys, which might allow remote attackers to spoof signatures on certificates or have unspecified other impact by leveraging an invalid DSA key.
Double free vulnerability in lib/x509/x509ext.c in GnuTLS before 3.3.14 allows remote attackers to cause a denial of service or possibly have unspecified other impact via a crafted CRL distribution point.
GnuTLS before 3.3.13 does not validate that the signature algorithms match when importing a certificate.
It was reported that gnutls 3.4.12 uses an environment variable (GNUTLSKEYLOGFILE) to write the keys of the running sessions. This variable is obtained insecurely via getenv(), meaning that any set-uid program using gnutls can be used to overwrite any file on the filesystem.
Upstream patch:
https://gitlab.com/gnutls/gnutls/compare/fb2a6baef79f4aadfd95e657fe5a18da20a1410e...86076c9b17b9a32b348cafb8b724f57f7da64d58
External References:
http://gnutls.org/security.html#GNUTLS-SA-2016-1
An issue was discovered in GnuTLS before 3.6.15. A server can trigger a NULL pointer dereference in a TLS 1.3 client if a norenegotiation alert is sent with unexpected timing, and then an invalid second handshake occurs. The crash happens in the application's error handling path, where the gnutlsdeinit function is called after detecting a handshake failure.
GnuTLS 3.6.x before 3.6.14 uses incorrect cryptography for encrypting a session ticket (a loss of confidentiality in TLS 1.2, and an authentication bypass in TLS 1.3). The earliest affected version is 3.6.4 (2018-09-24) because of an error in a 2018-09-18 commit. Until the first key rotation, the TLS server always uses wrong data in place of an encryption key derived from an application.
GnuTLS 3.6.x before 3.6.13 uses incorrect cryptography for DTLS. The earliest affected version is 3.6.3 (2018-07-16) because of an error in a 2017-10-06 commit. The DTLS client always uses 32 '\0' bytes instead of a random value, and thus contributes no randomness to a DTLS negotiation. This breaks the security guarantees of the DTLS protocol.