var-201605-0077

Vulnerability from variot

The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a certain padding check, which allows remote attackers to obtain sensitive cleartext information via a padding-oracle attack against an AES CBC session. NOTE: this vulnerability exists because of an incorrect fix for CVE-2013-0169. OpenSSL is prone to an information-disclosure vulnerability. An attacker can exploit this issue to perform man-in-the-middle attacks and obtain sensitive information. Successful exploits will lead to other attacks. Note : This issue is the result of an incomplete fix for the issue described in 57778 (Multiple TLS And DTLS Implementations CVE-2013-0169 Information Disclosure Vulnerability) OpenSSL versions 1.0.2 prior to 1.0.2h are vulnerable. OpenSSL versions 1.0.1 prior to 1.0.1t are vulnerable. OpenSSL Security Advisory [3rd May 2016] ========================================

Memory corruption in the ASN.1 encoder (CVE-2016-2108)

Severity: High

This issue affected versions of OpenSSL prior to April 2015. The bug causing the vulnerability was fixed on April 18th 2015, and released as part of the June 11th 2015 security releases. The security impact of the bug was not known at the time.

In previous versions of OpenSSL, ASN.1 encoding the value zero represented as a negative integer can cause a buffer underflow with an out-of-bounds write in i2c_ASN1_INTEGER. The ASN.1 parser does not normally create "negative zeroes" when parsing ASN.1 input, and therefore, an attacker cannot trigger this bug.

However, a second, independent bug revealed that the ASN.1 parser (specifically, d2i_ASN1_TYPE) can misinterpret a large universal tag as a negative zero value. Large universal tags are not present in any common ASN.1 structures (such as X509) but are accepted as part of ANY structures.

Therefore, if an application deserializes untrusted ASN.1 structures containing an ANY field, and later reserializes them, an attacker may be able to trigger an out-of-bounds write. This has been shown to cause memory corruption that is potentially exploitable with some malloc implementations.

Applications that parse and re-encode X509 certificates are known to be vulnerable. Applications that verify RSA signatures on X509 certificates may also be vulnerable; however, only certificates with valid signatures trigger ASN.1 re-encoding and hence the bug. Specifically, since OpenSSL's default TLS X509 chain verification code verifies the certificate chain from root to leaf, TLS handshakes could only be targeted with valid certificates issued by trusted Certification Authorities.

OpenSSL 1.0.2 users should upgrade to 1.0.2c OpenSSL 1.0.1 users should upgrade to 1.0.1o

This vulnerability is a combination of two bugs, neither of which individually has security impact. The first bug (mishandling of negative zero integers) was reported to OpenSSL by Huzaifa Sidhpurwala (Red Hat) and independently by Hanno Böck in April 2015. The second issue (mishandling of large universal tags) was found using libFuzzer, and reported on the public issue tracker on March 1st 2016. The fact that these two issues combined present a security vulnerability was reported by David Benjamin (Google) on March 31st 2016. The fixes were developed by Steve Henson of the OpenSSL development team, and David Benjamin. The OpenSSL team would also like to thank Mark Brand and Ian Beer from the Google Project Zero team for their careful analysis of the impact.

This issue was introduced as part of the fix for Lucky 13 padding attack (CVE-2013-0169). The padding check was rewritten to be in constant time by making sure that always the same bytes are read and compared against either the MAC or padding bytes. But it no longer checked that there was enough data to have both the MAC and padding bytes.