[openssl-commits] [web] master update
Matt Caswell
matt at openssl.org
Tue Mar 1 13:58:26 UTC 2016
The branch master has been updated
via 77d5a49c12876ed984fc15225b90c5320ac145d6 (commit)
from c141014db4abc964a8247f0314a368f494df5e23 (commit)
- Log -----------------------------------------------------------------
commit 77d5a49c12876ed984fc15225b90c5320ac145d6
Author: Matt Caswell <matt at openssl.org>
Date: Tue Mar 1 13:52:30 2016 +0000
Updates for the new release
-----------------------------------------------------------------------
Summary of changes:
news/newsflash.txt | 2 +
news/secadv/20160301.txt | 286 +++++++++++++++++++++++++++
news/vulnerabilities.xml | 505 ++++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 792 insertions(+), 1 deletion(-)
create mode 100644 news/secadv/20160301.txt
diff --git a/news/newsflash.txt b/news/newsflash.txt
index 3cdf185..9cbb1f2 100644
--- a/news/newsflash.txt
+++ b/news/newsflash.txt
@@ -4,6 +4,8 @@
# Format is two fields, colon-separated; the first line is the column
# headings. URL paths must all be absolute.
Date: Item
+01-Mar-2016: OpenSSL 1.0.2g is now available, including bug and security fixes
+01-Mar-2016: OpenSSL 1.0.1s is now available, including bug and security fixes
25-Feb-2016: OpenSSL 1.0.2g and 1.0.1s <a href="https://mta.openssl.org/pipermail/openssl-announce/2016-February/000063.html">security releases due 1st Mar 2016</a>
15-Feb-2016: Alpha 3 of OpenSSL 1.1.0 is now available: please download and test it
28-Jan-2016: <a href="/news/secadv/20160128.txt">Security Advisory</a>: two security fixes
diff --git a/news/secadv/20160301.txt b/news/secadv/20160301.txt
new file mode 100644
index 0000000..719351b
--- /dev/null
+++ b/news/secadv/20160301.txt
@@ -0,0 +1,286 @@
+OpenSSL Security Advisory [1st March 2016]
+=========================================
+
+NOTE: With this update, OpenSSL is disabling the SSLv2 protocol by default, as
+well as removing SSLv2 EXPORT ciphers. We strongly advise against the use of
+SSLv2 due not only to the issues described below, but to the other known
+deficiencies in the protocol as described at
+https://tools.ietf.org/html/rfc6176
+
+
+Cross-protocol attack on TLS using SSLv2 (DROWN) (CVE-2016-0800)
+================================================================
+
+Severity: High
+
+A cross-protocol attack was discovered that could lead to decryption of TLS
+sessions by using a server supporting SSLv2 and EXPORT cipher suites as a
+Bleichenbacher RSA padding oracle. Note that traffic between clients and
+non-vulnerable servers can be decrypted provided another server supporting
+SSLv2 and EXPORT ciphers (even with a different protocol such as SMTP, IMAP or
+POP) shares the RSA keys of the non-vulnerable server. This vulnerability is
+known as DROWN (CVE-2016-0800).
+
+Recovering one session key requires the attacker to perform approximately 2^50
+computation, as well as thousands of connections to the affected server. A more
+efficient variant of the DROWN attack exists against unpatched OpenSSL servers
+using versions that predate 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf released on
+19/Mar/2015 (see CVE-2016-0703 below).
+
+Users can avoid this issue by disabling the SSLv2 protocol in all their SSL/TLS
+servers, if they've not done so already. Disabling all SSLv2 ciphers is also
+sufficient, provided the patches for CVE-2015-3197 (fixed in OpenSSL 1.0.1r and
+1.0.2f) have been deployed. Servers that have not disabled the SSLv2 protocol,
+and are not patched for CVE-2015-3197 are vulnerable to DROWN even if all SSLv2
+ciphers are nominally disabled, because malicious clients can force the use of
+SSLv2 with EXPORT ciphers.
+
+OpenSSL 1.0.2g and 1.0.1s deploy the following mitigation against DROWN:
+
+SSLv2 is now by default disabled at build-time. Builds that are not configured
+with "enable-ssl2" will not support SSLv2. Even if "enable-ssl2" is used,
+users who want to negotiate SSLv2 via the version-flexible SSLv23_method() will
+need to explicitly call either of:
+
+ SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2);
+ or
+ SSL_clear_options(ssl, SSL_OP_NO_SSLv2);
+
+as appropriate. Even if either of those is used, or the application explicitly
+uses the version-specific SSLv2_method() or its client or server variants,
+SSLv2 ciphers vulnerable to exhaustive search key recovery have been removed.
+Specifically, the SSLv2 40-bit EXPORT ciphers, and SSLv2 56-bit DES are no
+longer available.
+
+In addition, weak ciphers in SSLv3 and up are now disabled in default builds of
+OpenSSL. Builds that are not configured with "enable-weak-ssl-ciphers" will
+not provide any "EXPORT" or "LOW" strength ciphers.
+
+OpenSSL 1.0.2 users should upgrade to 1.0.2g
+OpenSSL 1.0.1 users should upgrade to 1.0.1s
+
+This issue was reported to OpenSSL on December 29th 2015 by Nimrod Aviram and
+Sebastian Schinzel. The fix was developed by Viktor Dukhovni and Matt Caswell
+of OpenSSL.
+
+
+Double-free in DSA code (CVE-2016-0705)
+=======================================
+
+Severity: Low
+
+A double free bug was discovered when OpenSSL parses malformed DSA private keys
+and could lead to a DoS attack or memory corruption for applications that
+receive DSA private keys from untrusted sources. This scenario is considered
+rare.
+
+This issue affects OpenSSL versions 1.0.2 and 1.0.1.
+
+OpenSSL 1.0.2 users should upgrade to 1.0.2g
+OpenSSL 1.0.1 users should upgrade to 1.0.1s
+
+This issue was reported to OpenSSL on February 7th 2016 by Adam Langley
+(Google/BoringSSL) using libFuzzer. The fix was developed by Dr Stephen Henson
+of OpenSSL.
+
+
+Memory leak in SRP database lookups (CVE-2016-0798)
+===================================================
+
+Severity: Low
+
+The SRP user database lookup method SRP_VBASE_get_by_user had
+confusing memory management semantics; the returned pointer was sometimes newly
+allocated, and sometimes owned by the callee. The calling code has no way of
+distinguishing these two cases.
+
+Specifically, SRP servers that configure a secret seed to hide valid
+login information are vulnerable to a memory leak: an attacker
+connecting with an invalid username can cause a memory leak of around
+300 bytes per connection. Servers that do not configure SRP, or
+configure SRP but do not configure a seed are not vulnerable.
+
+In Apache, the seed directive is known as SSLSRPUnknownUserSeed.
+
+To mitigate the memory leak, the seed handling in
+SRP_VBASE_get_by_user is now disabled even if the user has configured
+a seed. Applications are advised to migrate to
+SRP_VBASE_get1_by_user. However, note that OpenSSL makes no strong
+guarantees about the indistinguishability of valid and invalid
+logins. In particular, computations are currently not carried out in
+constant time.
+
+This issue affects OpenSSL versions 1.0.2 and 1.0.1.
+
+OpenSSL 1.0.2 users should upgrade to 1.0.2g
+OpenSSL 1.0.1 users should upgrade to 1.0.1s
+
+This issue was discovered on February 23rd 2016 by Emilia Käsper of
+the OpenSSL development team. Emilia Käsper also developed the fix.
+
+
+BN_hex2bn/BN_dec2bn NULL pointer deref/heap corruption (CVE-2016-0797)
+======================================================================
+
+Severity: Low
+
+In the BN_hex2bn function the number of hex digits is calculated using an int
+value |i|. Later |bn_expand| is called with a value of |i * 4|. For large values
+of |i| this can result in |bn_expand| not allocating any memory because |i * 4|
+is negative. This can leave the internal BIGNUM data field as NULL leading to a
+subsequent NULL ptr deref. For very large values of |i|, the calculation |i * 4|
+could be a positive value smaller than |i|. In this case memory is allocated to
+the internal BIGNUM data field, but it is insufficiently sized leading to heap
+corruption. A similar issue exists in BN_dec2bn. This could have security
+consequences if BN_hex2bn/BN_dec2bn is ever called by user applications with
+very large untrusted hex/dec data. This is anticipated to be a rare occurrence.
+
+All OpenSSL internal usage of these functions use data that is not expected to
+be untrusted, e.g. config file data or application command line arguments. If
+user developed applications generate config file data based on untrusted data
+then it is possible that this could also lead to security consequences. This is
+also anticipated to be rare.
+
+This issue affects OpenSSL versions 1.0.2 and 1.0.1.
+
+OpenSSL 1.0.2 users should upgrade to 1.0.2g
+OpenSSL 1.0.1 users should upgrade to 1.0.1s
+
+This issue was reported to OpenSSL on February 19th 2016 by Guido Vranken. The
+fix was developed by Matt Caswell of the OpenSSL development team.
+
+Fix memory issues in BIO_*printf functions (CVE-2016-0799)
+==========================================================
+
+Severity: Low
+
+The internal |fmtstr| function used in processing a "%s" format string in the
+BIO_*printf functions could overflow while calculating the length of a string
+and cause an OOB read when printing very long strings.
+
+Additionally the internal |doapr_outch| function can attempt to write to an OOB
+memory location (at an offset from the NULL pointer) in the event of a memory
+allocation failure. In 1.0.2 and below this could be caused where the size of a
+buffer to be allocated is greater than INT_MAX. E.g. this could be in processing
+a very long "%s" format string. Memory leaks can also occur.
+
+The first issue may mask the second issue dependent on compiler behaviour.
+These problems could enable attacks where large amounts of untrusted data is
+passed to the BIO_*printf functions. If applications use these functions in this
+way then they could be vulnerable. OpenSSL itself uses these functions when
+printing out human-readable dumps of ASN.1 data. Therefore applications that
+print this data could be vulnerable if the data is from untrusted sources.
+OpenSSL command line applications could also be vulnerable where they print out
+ASN.1 data, or if untrusted data is passed as command line arguments.
+
+Libssl is not considered directly vulnerable. Additionally certificates etc
+received via remote connections via libssl are also unlikely to be able to
+trigger these issues because of message size limits enforced within libssl.
+
+This issue affects OpenSSL versions 1.0.2 and 1.0.1.
+
+OpenSSL 1.0.2 users should upgrade to 1.0.2g
+OpenSSL 1.0.1 users should upgrade to 1.0.1s
+
+This issue was reported to OpenSSL on February 23rd by Guido Vranken. The
+fix was developed by Matt Caswell of the OpenSSL development team.
+
+Side channel attack on modular exponentiation (CVE-2016-0702)
+=============================================================
+
+Severity: Low
+
+A side-channel attack was found which makes use of cache-bank conflicts on the
+Intel Sandy-Bridge microarchitecture which could lead to the recovery of RSA
+keys. The ability to exploit this issue is limited as it relies on an attacker
+who has control of code in a thread running on the same hyper-threaded core as
+the victim thread which is performing decryptions.
+
+This issue affects OpenSSL versions 1.0.2 and 1.0.1.
+
+OpenSSL 1.0.2 users should upgrade to 1.0.2g
+OpenSSL 1.0.1 users should upgrade to 1.0.1s
+
+This issue was reported to OpenSSL on Jan 8th 2016 by Yuval Yarom, The
+University of Adelaide and NICTA, Daniel Genkin, Technion and Tel Aviv
+University, and Nadia Heninger, University of Pennsylvania with more
+information at http://cachebleed.info. The fix was developed by Andy Polyakov
+of OpenSSL.
+
+
+Divide-and-conquer session key recovery in SSLv2 (CVE-2016-0703)
+================================================================
+
+Severity: High
+
+This issue only affected versions of OpenSSL prior to March 19th 2015 at which
+time the code was refactored to address vulnerability CVE-2015-0293.
+
+s2_srvr.c did not enforce that clear-key-length is 0 for non-export ciphers. If
+clear-key bytes are present for these ciphers, they *displace* encrypted-key
+bytes. This leads to an efficient divide-and-conquer key recovery attack: if an
+eavesdropper has intercepted an SSLv2 handshake, they can use the server as an
+oracle to determine the SSLv2 master-key, using only 16 connections to the
+server and negligible computation.
+
+More importantly, this leads to a more efficient version of DROWN that is
+effective against non-export ciphersuites, and requires no significant
+computation.
+
+This issue affected OpenSSL versions 1.0.2, 1.0.1l, 1.0.0q, 0.9.8ze and all
+earlier versions. It was fixed in OpenSSL 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf
+(released March 19th 2015).
+
+This issue was reported to OpenSSL on February 10th 2016 by David Adrian and J.
+Alex Halderman of the University of Michigan. The underlying defect had by
+then already been fixed by Emilia Käsper of OpenSSL on March 4th 2015. The fix
+for this issue can be identified by commits ae50d827 (1.0.2a), cd56a08d
+(1.0.1m), 1a08063 (1.0.0r) and 65c588c (0.9.8zf).
+
+
+Bleichenbacher oracle in SSLv2 (CVE-2016-0704)
+==============================================
+
+Severity: Moderate
+
+This issue only affected versions of OpenSSL prior to March 19th 2015 at which
+time the code was refactored to address the vulnerability CVE-2015-0293.
+
+s2_srvr.c overwrite the wrong bytes in the master-key when applying
+Bleichenbacher protection for export cipher suites. This provides a
+Bleichenbacher oracle, and could potentially allow more efficient variants of
+the DROWN attack.
+
+This issue affected OpenSSL versions 1.0.2, 1.0.1l, 1.0.0q, 0.9.8ze and all
+earlier versions. It was fixed in OpenSSL 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf
+(released March 19th 2015).
+
+This issue was reported to OpenSSL on February 10th 2016 by David Adrian and J.
+Alex Halderman of the University of Michigan. The underlying defect had by
+then already been fixed by Emilia Käsper of OpenSSL on March 4th 2015. The fix
+for this issue can be identified by commits ae50d827 (1.0.2a), cd56a08d
+(1.0.1m), 1a08063 (1.0.0r) and 65c588c (0.9.8zf).
+
+Note
+====
+
+As per our previous announcements and our Release Strategy
+(https://www.openssl.org/policies/releasestrat.html), support for OpenSSL
+version 1.0.1 will cease on 31st December 2016. No security updates for that
+version will be provided after that date. Users of 1.0.1 are advised to
+upgrade.
+
+Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those
+versions are no longer receiving security updates.
+
+References
+==========
+
+URL for this Security Advisory:
+https://www.openssl.org/news/secadv/20160301.txt
+
+Note: the online version of the advisory may be updated with additional details
+over time.
+
+For details of OpenSSL severity classifications please see:
+https://www.openssl.org/policies/secpolicy.html
diff --git a/news/vulnerabilities.xml b/news/vulnerabilities.xml
index fb59f52..4465289 100644
--- a/news/vulnerabilities.xml
+++ b/news/vulnerabilities.xml
@@ -5,7 +5,510 @@
1.0.0 on 20100329
-->
-<security updated="20160128">
+<security updated="20160301">
+ <issue public="20160301">
+ <impact severity="High"/>
+ <cve name="2016-0800"/>
+ <affects base="1.0.1" version="1.0.1"/>
+ <affects base="1.0.1" version="1.0.1a"/>
+ <affects base="1.0.1" version="1.0.1b"/>
+ <affects base="1.0.1" version="1.0.1c"/>
+ <affects base="1.0.1" version="1.0.1d"/>
+ <affects base="1.0.1" version="1.0.1e"/>
+ <affects base="1.0.1" version="1.0.1f"/>
+ <affects base="1.0.1" version="1.0.1g"/>
+ <affects base="1.0.1" version="1.0.1h"/>
+ <affects base="1.0.1" version="1.0.1i"/>
+ <affects base="1.0.1" version="1.0.1j"/>
+ <affects base="1.0.1" version="1.0.1k"/>
+ <affects base="1.0.1" version="1.0.1l"/>
+ <affects base="1.0.1" version="1.0.1m"/>
+ <affects base="1.0.1" version="1.0.1n"/>
+ <affects base="1.0.1" version="1.0.1o"/>
+ <affects base="1.0.1" version="1.0.1p"/>
+ <affects base="1.0.1" version="1.0.1q"/>
+ <affects base="1.0.1" version="1.0.1r"/>
+ <affects base="1.0.2" version="1.0.2"/>
+ <affects base="1.0.2" version="1.0.2a"/>
+ <affects base="1.0.2" version="1.0.2b"/>
+ <affects base="1.0.2" version="1.0.2c"/>
+ <affects base="1.0.2" version="1.0.2d"/>
+ <affects base="1.0.2" version="1.0.2e"/>
+ <affects base="1.0.2" version="1.0.2f"/>
+ <fixed base="1.0.1" version="1.0.1s" date="20160301"/>
+ <fixed base="1.0.2" version="1.0.2g" date="20160301"/>
+
+ <description>
+ A cross-protocol attack was discovered that could lead to decryption of TLS
+ sessions by using a server supporting SSLv2 and EXPORT cipher suites as a
+ Bleichenbacher RSA padding oracle. Note that traffic between clients and
+ non-vulnerable servers can be decrypted provided another server supporting
+ SSLv2 and EXPORT ciphers (even with a different protocol such as SMTP, IMAP or
+ POP) shares the RSA keys of the non-vulnerable server. This vulnerability is
+ known as DROWN (CVE-2016-0800).
+
+ Recovering one session key requires the attacker to perform approximately 2^50
+ computation, as well as thousands of connections to the affected server. A more
+ efficient variant of the DROWN attack exists against unpatched OpenSSL servers
+ using versions that predate 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf released on
+ 19/Mar/2015 (see CVE-2016-0703 below).
+
+ Users can avoid this issue by disabling the SSLv2 protocol in all their SSL/TLS
+ servers, if they've not done so already. Disabling all SSLv2 ciphers is also
+ sufficient, provided the patches for CVE-2015-3197 (fixed in OpenSSL 1.0.1r and
+ 1.0.2f) have been deployed. Servers that have not disabled the SSLv2 protocol,
+ and are not patched for CVE-2015-3197 are vulnerable to DROWN even if all SSLv2
+ ciphers are nominally disabled, because malicious clients can force the use of
+ SSLv2 with EXPORT ciphers.
+
+ OpenSSL 1.0.2g and 1.0.1s deploy the following mitigation against DROWN:
+
+ SSLv2 is now by default disabled at build-time. Builds that are not configured
+ with "enable-ssl2" will not support SSLv2. Even if "enable-ssl2" is used,
+ users who want to negotiate SSLv2 via the version-flexible SSLv23_method() will
+ need to explicitly call either of:
+
+ SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2);
+ or
+ SSL_clear_options(ssl, SSL_OP_NO_SSLv2);
+
+ as appropriate. Even if either of those is used, or the application explicitly
+ uses the version-specific SSLv2_method() or its client or server variants,
+ SSLv2 ciphers vulnerable to exhaustive search key recovery have been removed.
+ Specifically, the SSLv2 40-bit EXPORT ciphers, and SSLv2 56-bit DES are no
+ longer available.
+
+ In addition, weak ciphers in SSLv3 and up are now disabled in default builds of
+ OpenSSL. Builds that are not configured with "enable-weak-ssl-ciphers" will
+ not provide any "EXPORT" or "LOW" strength ciphers.
+ </description>
+ <advisory url="/news/secadv/20160301.txt"/>
+ <reported source="Nimrod Aviram and Sebastian Schinzel"/>
+ </issue>
+ <issue public="20160301">
+ <impact severity="Low"/>
+ <cve name="2016-0705"/>
+ <affects base="1.0.1" version="1.0.1"/>
+ <affects base="1.0.1" version="1.0.1a"/>
+ <affects base="1.0.1" version="1.0.1b"/>
+ <affects base="1.0.1" version="1.0.1c"/>
+ <affects base="1.0.1" version="1.0.1d"/>
+ <affects base="1.0.1" version="1.0.1e"/>
+ <affects base="1.0.1" version="1.0.1f"/>
+ <affects base="1.0.1" version="1.0.1g"/>
+ <affects base="1.0.1" version="1.0.1h"/>
+ <affects base="1.0.1" version="1.0.1i"/>
+ <affects base="1.0.1" version="1.0.1j"/>
+ <affects base="1.0.1" version="1.0.1k"/>
+ <affects base="1.0.1" version="1.0.1l"/>
+ <affects base="1.0.1" version="1.0.1m"/>
+ <affects base="1.0.1" version="1.0.1n"/>
+ <affects base="1.0.1" version="1.0.1o"/>
+ <affects base="1.0.1" version="1.0.1p"/>
+ <affects base="1.0.1" version="1.0.1q"/>
+ <affects base="1.0.1" version="1.0.1r"/>
+ <affects base="1.0.2" version="1.0.2"/>
+ <affects base="1.0.2" version="1.0.2a"/>
+ <affects base="1.0.2" version="1.0.2b"/>
+ <affects base="1.0.2" version="1.0.2c"/>
+ <affects base="1.0.2" version="1.0.2d"/>
+ <affects base="1.0.2" version="1.0.2e"/>
+ <affects base="1.0.2" version="1.0.2f"/>
+ <fixed base="1.0.1" version="1.0.1s" date="20160301"/>
+ <fixed base="1.0.2" version="1.0.2g" date="20160301"/>
+
+ <description>
+ A double free bug was discovered when OpenSSL parses malformed DSA private keys
+ and could lead to a DoS attack or memory corruption for applications that
+ receive DSA private keys from untrusted sources. This scenario is considered
+ rare.
+ </description>
+ <advisory url="/news/secadv/20160301.txt"/>
+ <reported source="Adam Langley (Google/BoringSSL)"/>
+ </issue>
+ <issue public="20160301">
+ <impact severity="Low"/>
+ <cve name="2016-0798"/>
+ <affects base="1.0.1" version="1.0.1"/>
+ <affects base="1.0.1" version="1.0.1a"/>
+ <affects base="1.0.1" version="1.0.1b"/>
+ <affects base="1.0.1" version="1.0.1c"/>
+ <affects base="1.0.1" version="1.0.1d"/>
+ <affects base="1.0.1" version="1.0.1e"/>
+ <affects base="1.0.1" version="1.0.1f"/>
+ <affects base="1.0.1" version="1.0.1g"/>
+ <affects base="1.0.1" version="1.0.1h"/>
+ <affects base="1.0.1" version="1.0.1i"/>
+ <affects base="1.0.1" version="1.0.1j"/>
+ <affects base="1.0.1" version="1.0.1k"/>
+ <affects base="1.0.1" version="1.0.1l"/>
+ <affects base="1.0.1" version="1.0.1m"/>
+ <affects base="1.0.1" version="1.0.1n"/>
+ <affects base="1.0.1" version="1.0.1o"/>
+ <affects base="1.0.1" version="1.0.1p"/>
+ <affects base="1.0.1" version="1.0.1q"/>
+ <affects base="1.0.1" version="1.0.1r"/>
+ <affects base="1.0.2" version="1.0.2"/>
+ <affects base="1.0.2" version="1.0.2a"/>
+ <affects base="1.0.2" version="1.0.2b"/>
+ <affects base="1.0.2" version="1.0.2c"/>
+ <affects base="1.0.2" version="1.0.2d"/>
+ <affects base="1.0.2" version="1.0.2e"/>
+ <affects base="1.0.2" version="1.0.2f"/>
+ <fixed base="1.0.1" version="1.0.1s" date="20160301"/>
+ <fixed base="1.0.2" version="1.0.2g" date="20160301"/>
+
+ <description>
+ The SRP user database lookup method SRP_VBASE_get_by_user had
+ confusing memory management semantics; the returned pointer was sometimes newly
+ allocated, and sometimes owned by the callee. The calling code has no way of
+ distinguishing these two cases.
+
+ Specifically, SRP servers that configure a secret seed to hide valid
+ login information are vulnerable to a memory leak: an attacker
+ connecting with an invalid username can cause a memory leak of around
+ 300 bytes per connection. Servers that do not configure SRP, or
+ configure SRP but do not configure a seed are not vulnerable.
+
+ In Apache, the seed directive is known as SSLSRPUnknownUserSeed.
+
+ To mitigate the memory leak, the seed handling in
+ SRP_VBASE_get_by_user is now disabled even if the user has configured
+ a seed. Applications are advised to migrate to
+ SRP_VBASE_get1_by_user. However, note that OpenSSL makes no strong
+ guarantees about the indistinguishability of valid and invalid
+ logins. In particular, computations are currently not carried out in
+ constant time.
+ </description>
+ <advisory url="/news/secadv/20160301.txt"/>
+ <reported source="OpenSSL"/>
+ </issue>
+ <issue public="20160301">
+ <impact severity="Low"/>
+ <cve name="2016-0797"/>
+ <affects base="1.0.1" version="1.0.1"/>
+ <affects base="1.0.1" version="1.0.1a"/>
+ <affects base="1.0.1" version="1.0.1b"/>
+ <affects base="1.0.1" version="1.0.1c"/>
+ <affects base="1.0.1" version="1.0.1d"/>
+ <affects base="1.0.1" version="1.0.1e"/>
+ <affects base="1.0.1" version="1.0.1f"/>
+ <affects base="1.0.1" version="1.0.1g"/>
+ <affects base="1.0.1" version="1.0.1h"/>
+ <affects base="1.0.1" version="1.0.1i"/>
+ <affects base="1.0.1" version="1.0.1j"/>
+ <affects base="1.0.1" version="1.0.1k"/>
+ <affects base="1.0.1" version="1.0.1l"/>
+ <affects base="1.0.1" version="1.0.1m"/>
+ <affects base="1.0.1" version="1.0.1n"/>
+ <affects base="1.0.1" version="1.0.1o"/>
+ <affects base="1.0.1" version="1.0.1p"/>
+ <affects base="1.0.1" version="1.0.1q"/>
+ <affects base="1.0.1" version="1.0.1r"/>
+ <affects base="1.0.2" version="1.0.2"/>
+ <affects base="1.0.2" version="1.0.2a"/>
+ <affects base="1.0.2" version="1.0.2b"/>
+ <affects base="1.0.2" version="1.0.2c"/>
+ <affects base="1.0.2" version="1.0.2d"/>
+ <affects base="1.0.2" version="1.0.2e"/>
+ <affects base="1.0.2" version="1.0.2f"/>
+ <fixed base="1.0.1" version="1.0.1s" date="20160301"/>
+ <fixed base="1.0.2" version="1.0.2g" date="20160301"/>
+
+ <description>
+ In the BN_hex2bn function the number of hex digits is calculated using an int
+ value |i|. Later |bn_expand| is called with a value of |i * 4|. For large values
+ of |i| this can result in |bn_expand| not allocating any memory because |i * 4|
+ is negative. This can leave the internal BIGNUM data field as NULL leading to a
+ subsequent NULL ptr deref. For very large values of |i|, the calculation |i * 4|
+ could be a positive value smaller than |i|. In this case memory is allocated to
+ the internal BIGNUM data field, but it is insufficiently sized leading to heap
+ corruption. A similar issue exists in BN_dec2bn. This could have security
+ consequences if BN_hex2bn/BN_dec2bn is ever called by user applications with
+ very large untrusted hex/dec data. This is anticipated to be a rare occurrence.
+
+ All OpenSSL internal usage of these functions use data that is not expected to
+ be untrusted, e.g. config file data or application command line arguments. If
+ user developed applications generate config file data based on untrusted data
+ then it is possible that this could also lead to security consequences. This is
+ also anticipated to be rare.
+ </description>
+ <advisory url="/news/secadv/20160301.txt"/>
+ <reported source="Guido Vranken"/>
+ </issue>
+ <issue public="20160301">
+ <impact severity="Low"/>
+ <cve name="2016-0799"/>
+ <affects base="1.0.1" version="1.0.1"/>
+ <affects base="1.0.1" version="1.0.1a"/>
+ <affects base="1.0.1" version="1.0.1b"/>
+ <affects base="1.0.1" version="1.0.1c"/>
+ <affects base="1.0.1" version="1.0.1d"/>
+ <affects base="1.0.1" version="1.0.1e"/>
+ <affects base="1.0.1" version="1.0.1f"/>
+ <affects base="1.0.1" version="1.0.1g"/>
+ <affects base="1.0.1" version="1.0.1h"/>
+ <affects base="1.0.1" version="1.0.1i"/>
+ <affects base="1.0.1" version="1.0.1j"/>
+ <affects base="1.0.1" version="1.0.1k"/>
+ <affects base="1.0.1" version="1.0.1l"/>
+ <affects base="1.0.1" version="1.0.1m"/>
+ <affects base="1.0.1" version="1.0.1n"/>
+ <affects base="1.0.1" version="1.0.1o"/>
+ <affects base="1.0.1" version="1.0.1p"/>
+ <affects base="1.0.1" version="1.0.1q"/>
+ <affects base="1.0.1" version="1.0.1r"/>
+ <affects base="1.0.2" version="1.0.2"/>
+ <affects base="1.0.2" version="1.0.2a"/>
+ <affects base="1.0.2" version="1.0.2b"/>
+ <affects base="1.0.2" version="1.0.2c"/>
+ <affects base="1.0.2" version="1.0.2d"/>
+ <affects base="1.0.2" version="1.0.2e"/>
+ <affects base="1.0.2" version="1.0.2f"/>
+ <fixed base="1.0.1" version="1.0.1s" date="20160301"/>
+ <fixed base="1.0.2" version="1.0.2g" date="20160301"/>
+
+ <description>
+ The internal |fmtstr| function used in processing a "%s" format string in the
+ BIO_*printf functions could overflow while calculating the length of a string
+ and cause an OOB read when printing very long strings.
+
+ Additionally the internal |doapr_outch| function can attempt to write to an OOB
+ memory location (at an offset from the NULL pointer) in the event of a memory
+ allocation failure. In 1.0.2 and below this could be caused where the size of a
+ buffer to be allocated is greater than INT_MAX. E.g. this could be in processing
+ a very long "%s" format string. Memory leaks can also occur.
+
+ The first issue may mask the second issue dependent on compiler behaviour.
+ These problems could enable attacks where large amounts of untrusted data is
+ passed to the BIO_*printf functions. If applications use these functions in this
+ way then they could be vulnerable. OpenSSL itself uses these functions when
+ printing out human-readable dumps of ASN.1 data. Therefore applications that
+ print this data could be vulnerable if the data is from untrusted sources.
+ OpenSSL command line applications could also be vulnerable where they print out
+ ASN.1 data, or if untrusted data is passed as command line arguments.
+
+ Libssl is not considered directly vulnerable. Additionally certificates etc
+ received via remote connections via libssl are also unlikely to be able to
+ trigger these issues because of message size limits enforced within libssl.
+ </description>
+ <advisory url="/news/secadv/20160301.txt"/>
+ <reported source="Guido Vranken"/>
+ </issue>
+ <issue public="20160301">
+ <impact severity="Low"/>
+ <cve name="2016-0702"/>
+ <affects base="1.0.1" version="1.0.1"/>
+ <affects base="1.0.1" version="1.0.1a"/>
+ <affects base="1.0.1" version="1.0.1b"/>
+ <affects base="1.0.1" version="1.0.1c"/>
+ <affects base="1.0.1" version="1.0.1d"/>
+ <affects base="1.0.1" version="1.0.1e"/>
+ <affects base="1.0.1" version="1.0.1f"/>
+ <affects base="1.0.1" version="1.0.1g"/>
+ <affects base="1.0.1" version="1.0.1h"/>
+ <affects base="1.0.1" version="1.0.1i"/>
+ <affects base="1.0.1" version="1.0.1j"/>
+ <affects base="1.0.1" version="1.0.1k"/>
+ <affects base="1.0.1" version="1.0.1l"/>
+ <affects base="1.0.1" version="1.0.1m"/>
+ <affects base="1.0.1" version="1.0.1n"/>
+ <affects base="1.0.1" version="1.0.1o"/>
+ <affects base="1.0.1" version="1.0.1p"/>
+ <affects base="1.0.1" version="1.0.1q"/>
+ <affects base="1.0.1" version="1.0.1r"/>
+ <affects base="1.0.2" version="1.0.2"/>
+ <affects base="1.0.2" version="1.0.2a"/>
+ <affects base="1.0.2" version="1.0.2b"/>
+ <affects base="1.0.2" version="1.0.2c"/>
+ <affects base="1.0.2" version="1.0.2d"/>
+ <affects base="1.0.2" version="1.0.2e"/>
+ <affects base="1.0.2" version="1.0.2f"/>
+ <fixed base="1.0.1" version="1.0.1s" date="20160301"/>
+ <fixed base="1.0.2" version="1.0.2g" date="20160301"/>
+
+ <description>
+ A side-channel attack was found which makes use of cache-bank conflicts on the
+ Intel Sandy-Bridge microarchitecture which could lead to the recovery of RSA
+ keys. The ability to exploit this issue is limited as it relies on an attacker
+ who has control of code in a thread running on the same hyper-threaded core as
+ the victim thread which is performing decryptions.
+ </description>
+ <advisory url="/news/secadv/20160301.txt"/>
+ <reported source="Yuval Yarom, The University of Adelaide and NICTA, Daniel Genkin, Technion and Tel Aviv University, and Nadia Heninger, University of Pennsylvania"/>
+ </issue>
+ <issue public="20160301">
+ <impact severity="High"/>
+ <cve name="2016-0703"/>
+
+ <affects base="0.9.8" version="0.9.8"/>
+ <affects base="0.9.8" version="0.9.8a"/>
+ <affects base="0.9.8" version="0.9.8b"/>
+ <affects base="0.9.8" version="0.9.8c"/>
+ <affects base="0.9.8" version="0.9.8d"/>
+ <affects base="0.9.8" version="0.9.8e"/>
+ <affects base="0.9.8" version="0.9.8f"/>
+ <affects base="0.9.8" version="0.9.8g"/>
+ <affects base="0.9.8" version="0.9.8h"/>
+ <affects base="0.9.8" version="0.9.8i"/>
+ <affects base="0.9.8" version="0.9.8j"/>
+ <affects base="0.9.8" version="0.9.8k"/>
+ <affects base="0.9.8" version="0.9.8l"/>
+ <affects base="0.9.8" version="0.9.8m"/>
+ <affects base="0.9.8" version="0.9.8n"/>
+ <affects base="0.9.8" version="0.9.8o"/>
+ <affects base="0.9.8" version="0.9.8p"/>
+ <affects base="0.9.8" version="0.9.8q"/>
+ <affects base="0.9.8" version="0.9.8r"/>
+ <affects base="0.9.8" version="0.9.8s"/>
+ <affects base="0.9.8" version="0.9.8t"/>
+ <affects base="0.9.8" version="0.9.8u"/>
+ <affects base="0.9.8" version="0.9.8v"/>
+ <affects base="0.9.8" version="0.9.8w"/>
+ <affects base="0.9.8" version="0.9.8x"/>
+ <affects base="0.9.8" version="0.9.8y"/>
+ <affects base="0.9.8" version="0.9.8za"/>
+ <affects base="0.9.8" version="0.9.8zb"/>
+ <affects base="0.9.8" version="0.9.8zc"/>
+ <affects base="0.9.8" version="0.9.8zd"/>
+ <affects base="0.9.8" version="0.9.8ze"/>
+ <affects base="1.0.0" version="1.0.0"/>
+ <affects base="1.0.0" version="1.0.0a"/>
+ <affects base="1.0.0" version="1.0.0b"/>
+ <affects base="1.0.0" version="1.0.0c"/>
+ <affects base="1.0.0" version="1.0.0d"/>
+ <affects base="1.0.0" version="1.0.0e"/>
+ <affects base="1.0.0" version="1.0.0f"/>
+ <affects base="1.0.0" version="1.0.0g"/>
+ <affects base="1.0.0" version="1.0.0i"/>
+ <affects base="1.0.0" version="1.0.0j"/>
+ <affects base="1.0.0" version="1.0.0k"/>
+ <affects base="1.0.0" version="1.0.0l"/>
+ <affects base="1.0.0" version="1.0.0m"/>
+ <affects base="1.0.0" version="1.0.0n"/>
+ <affects base="1.0.0" version="1.0.0o"/>
+ <affects base="1.0.0" version="1.0.0p"/>
+ <affects base="1.0.0" version="1.0.0q"/>
+ <affects base="1.0.1" version="1.0.1"/>
+ <affects base="1.0.1" version="1.0.1a"/>
+ <affects base="1.0.1" version="1.0.1b"/>
+ <affects base="1.0.1" version="1.0.1c"/>
+ <affects base="1.0.1" version="1.0.1d"/>
+ <affects base="1.0.1" version="1.0.1e"/>
+ <affects base="1.0.1" version="1.0.1f"/>
+ <affects base="1.0.1" version="1.0.1g"/>
+ <affects base="1.0.1" version="1.0.1h"/>
+ <affects base="1.0.1" version="1.0.1i"/>
+ <affects base="1.0.1" version="1.0.1j"/>
+ <affects base="1.0.1" version="1.0.1k"/>
+ <affects base="1.0.1" version="1.0.1l"/>
+ <affects base="1.0.2" version="1.0.2"/>
+ <fixed base="0.9.8" version="0.9.8zf" date="20150319"/>
+ <fixed base="1.0.0" version="1.0.0r" date="20150319"/>
+ <fixed base="1.0.1" version="1.0.1m" date="20150319"/>
+ <fixed base="1.0.2" version="1.0.2a" date="20150319"/>
+
+ <description>
+ This issue only affected versions of OpenSSL prior to March 19th 2015 at which
+ time the code was refactored to address vulnerability CVE-2015-0293.
+
+ s2_srvr.c did not enforce that clear-key-length is 0 for non-export ciphers. If
+ clear-key bytes are present for these ciphers, they *displace* encrypted-key
+ bytes. This leads to an efficient divide-and-conquer key recovery attack: if an
+ eavesdropper has intercepted an SSLv2 handshake, they can use the server as an
+ oracle to determine the SSLv2 master-key, using only 16 connections to the
+ server and negligible computation.
+
+ More importantly, this leads to a more efficient version of DROWN that is
+ effective against non-export ciphersuites, and requires no significant
+ computation.
+ </description>
+ <advisory url="/news/secadv/20160301.txt"/>
+ <reported source="David Adrian and J.Alex Halderman (University of Michigan)"/>
+ </issue>
+ <issue public="20160301">
+ <impact severity="Moderate"/>
+ <cve name="2016-0704"/>
+
+ <affects base="0.9.8" version="0.9.8"/>
+ <affects base="0.9.8" version="0.9.8a"/>
+ <affects base="0.9.8" version="0.9.8b"/>
+ <affects base="0.9.8" version="0.9.8c"/>
+ <affects base="0.9.8" version="0.9.8d"/>
+ <affects base="0.9.8" version="0.9.8e"/>
+ <affects base="0.9.8" version="0.9.8f"/>
+ <affects base="0.9.8" version="0.9.8g"/>
+ <affects base="0.9.8" version="0.9.8h"/>
+ <affects base="0.9.8" version="0.9.8i"/>
+ <affects base="0.9.8" version="0.9.8j"/>
+ <affects base="0.9.8" version="0.9.8k"/>
+ <affects base="0.9.8" version="0.9.8l"/>
+ <affects base="0.9.8" version="0.9.8m"/>
+ <affects base="0.9.8" version="0.9.8n"/>
+ <affects base="0.9.8" version="0.9.8o"/>
+ <affects base="0.9.8" version="0.9.8p"/>
+ <affects base="0.9.8" version="0.9.8q"/>
+ <affects base="0.9.8" version="0.9.8r"/>
+ <affects base="0.9.8" version="0.9.8s"/>
+ <affects base="0.9.8" version="0.9.8t"/>
+ <affects base="0.9.8" version="0.9.8u"/>
+ <affects base="0.9.8" version="0.9.8v"/>
+ <affects base="0.9.8" version="0.9.8w"/>
+ <affects base="0.9.8" version="0.9.8x"/>
+ <affects base="0.9.8" version="0.9.8y"/>
+ <affects base="0.9.8" version="0.9.8za"/>
+ <affects base="0.9.8" version="0.9.8zb"/>
+ <affects base="0.9.8" version="0.9.8zc"/>
+ <affects base="0.9.8" version="0.9.8zd"/>
+ <affects base="0.9.8" version="0.9.8ze"/>
+ <affects base="1.0.0" version="1.0.0"/>
+ <affects base="1.0.0" version="1.0.0a"/>
+ <affects base="1.0.0" version="1.0.0b"/>
+ <affects base="1.0.0" version="1.0.0c"/>
+ <affects base="1.0.0" version="1.0.0d"/>
+ <affects base="1.0.0" version="1.0.0e"/>
+ <affects base="1.0.0" version="1.0.0f"/>
+ <affects base="1.0.0" version="1.0.0g"/>
+ <affects base="1.0.0" version="1.0.0i"/>
+ <affects base="1.0.0" version="1.0.0j"/>
+ <affects base="1.0.0" version="1.0.0k"/>
+ <affects base="1.0.0" version="1.0.0l"/>
+ <affects base="1.0.0" version="1.0.0m"/>
+ <affects base="1.0.0" version="1.0.0n"/>
+ <affects base="1.0.0" version="1.0.0o"/>
+ <affects base="1.0.0" version="1.0.0p"/>
+ <affects base="1.0.0" version="1.0.0q"/>
+ <affects base="1.0.1" version="1.0.1"/>
+ <affects base="1.0.1" version="1.0.1a"/>
+ <affects base="1.0.1" version="1.0.1b"/>
+ <affects base="1.0.1" version="1.0.1c"/>
+ <affects base="1.0.1" version="1.0.1d"/>
+ <affects base="1.0.1" version="1.0.1e"/>
+ <affects base="1.0.1" version="1.0.1f"/>
+ <affects base="1.0.1" version="1.0.1g"/>
+ <affects base="1.0.1" version="1.0.1h"/>
+ <affects base="1.0.1" version="1.0.1i"/>
+ <affects base="1.0.1" version="1.0.1j"/>
+ <affects base="1.0.1" version="1.0.1k"/>
+ <affects base="1.0.1" version="1.0.1l"/>
+ <affects base="1.0.2" version="1.0.2"/>
+ <fixed base="0.9.8" version="0.9.8zf" date="20150319"/>
+ <fixed base="1.0.0" version="1.0.0r" date="20150319"/>
+ <fixed base="1.0.1" version="1.0.1m" date="20150319"/>
+ <fixed base="1.0.2" version="1.0.2a" date="20150319"/>
+
+ <description>
+ This issue only affected versions of OpenSSL prior to March 19th 2015 at which
+ time the code was refactored to address the vulnerability CVE-2015-0293.
+
+ s2_srvr.c overwrite the wrong bytes in the master-key when applying
+ Bleichenbacher protection for export cipher suites. This provides a
+ Bleichenbacher oracle, and could potentially allow more efficient variants of
+ the DROWN attack.
+ </description>
+ <advisory url="/news/secadv/20160301.txt"/>
+ <reported source="David Adrian and J.Alex Halderman (University of Michigan)"/>
+ </issue>
<issue public="20160128">
<impact severity="High"/>
<cve name="2016-0701"/>
More information about the openssl-commits
mailing list