[openssl-commits] [web] master update
Matt Caswell
matt at openssl.org
Tue May 3 14:58:40 UTC 2016
The branch master has been updated
via 2fb6133d074d20f9620ebc23f090cef1a1f1ace8 (commit)
from 55c8718b30ea218af975fd1c6d2a8fb202aec9b5 (commit)
- Log -----------------------------------------------------------------
commit 2fb6133d074d20f9620ebc23f090cef1a1f1ace8
Author: Matt Caswell <matt at openssl.org>
Date: Tue May 3 15:58:23 2016 +0100
Fix copy&paste error in vulnerabilities.xml
-----------------------------------------------------------------------
Summary of changes:
news/vulnerabilities.xml | 41 +++++++++++++++++++++++++++++++----------
1 file changed, 31 insertions(+), 10 deletions(-)
diff --git a/news/vulnerabilities.xml b/news/vulnerabilities.xml
index b18d98c..da6d047 100644
--- a/news/vulnerabilities.xml
+++ b/news/vulnerabilities.xml
@@ -31,16 +31,37 @@
<fixed base="1.0.2" version="1.0.2c" date="20160612"/>
<description>
- A MITM attacker can use a padding oracle attack to decrypt traffic
- when the connection uses an AES CBC cipher and the server support
- AES-NI.
-
- 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.
+ 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.
</description>
<advisory url="/news/secadv/20160503.txt"/>
<reported source="Huzaifa Sidhpurwala (Red Hat), Hanno Böck, David Benjamin (Google)"/>
More information about the openssl-commits
mailing list