[openssl-commits] [web] master update

[Matt Caswell]

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)"/>