The branch master has been updated via 2fb6133d074d20f9620ebc23f090cef1a1f1ace8 (commit) from 55c8718b30ea218af975fd1c6d2a8fb202aec9b5 (commit)
- Log ----------------------------------------------------------------- commit 2fb6133d074d20f9620ebc23f090cef1a1f1ace8 Author: Matt Caswell <m...@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)"/> _____ openssl-commits mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-commits