[openssl-commits] [web] master update
Matt Caswell
matt at openssl.org
Thu Sep 22 10:38:43 UTC 2016
The branch master has been updated
via fbd32b1a5c7f0d7bc90e8a716bdf44cbfbeeb7a6 (commit)
from 08e980caee8d6252b0838e9924498db12083203b (commit)
- Log -----------------------------------------------------------------
commit fbd32b1a5c7f0d7bc90e8a716bdf44cbfbeeb7a6
Author: Matt Caswell <matt at openssl.org>
Date: Thu Sep 22 11:10:48 2016 +0100
Update website for new release
-----------------------------------------------------------------------
Summary of changes:
news/newsflash.txt | 4 +
news/secadv/20160922.txt | 361 +++++++++++++++++++++++++++++
news/vulnerabilities.xml | 590 ++++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 954 insertions(+), 1 deletion(-)
create mode 100644 news/secadv/20160922.txt
diff --git a/news/newsflash.txt b/news/newsflash.txt
index 0a90069..6eb393c 100644
--- a/news/newsflash.txt
+++ b/news/newsflash.txt
@@ -4,6 +4,10 @@
# Format is two fields, colon-separated; the first line is the column
# headings. URL paths must all be absolute.
Date: Item
+22-Sep-2016: <a href="/news/secadv/20160922.txt">Security Advisory</a>: several security fixes
+22-Sep-2016: OpenSSL 1.1.0a is now available, including bug and security fixes
+22-Sep-2016: OpenSSL 1.0.2i is now available, including bug and security fixes
+22-Sep-2016: OpenSSL 1.0.1u is now available, including bug and security fixes
19-Sep-2016: OpenSSL 1.1.0a, 1.0.2i, 1.0.1u <a href="https://mta.openssl.org/pipermail/openssl-announce/2016-September/000076.html">security releases due 22nd Sep 2016</a>
25-Aug-2016: OpenSSL 1.1.0 is now available
04-Aug-2016: Beta 3 (pre-release 6) of OpenSSL 1.1.0 is now available: please download and test it
diff --git a/news/secadv/20160922.txt b/news/secadv/20160922.txt
new file mode 100644
index 0000000..c35d70a
--- /dev/null
+++ b/news/secadv/20160922.txt
@@ -0,0 +1,361 @@
+
+OpenSSL Security Advisory [22 Sep 2016]
+========================================
+
+OCSP Status Request extension unbounded memory growth (CVE-2016-6304)
+=====================================================================
+
+Severity: High
+
+A malicious client can send an excessively large OCSP Status Request extension.
+If that client continually requests renegotiation, sending a large OCSP Status
+Request extension each time, then there will be unbounded memory growth on the
+server. This will eventually lead to a Denial Of Service attack through memory
+exhaustion. Servers with a default configuration are vulnerable even if they do
+not support OCSP. Builds using the "no-ocsp" build time option are not affected.
+
+Servers using OpenSSL versions prior to 1.0.1g are not vulnerable in a default
+configuration, instead only if an application explicitly enables OCSP stapling
+support.
+
+OpenSSL 1.1.0 users should upgrade to 1.1.0a
+OpenSSL 1.0.2 users should upgrade to 1.0.2i
+OpenSSL 1.0.1 users should upgrade to 1.0.1u
+
+This issue was reported to OpenSSL on 29th August 2016 by Shi Lei (Gear Team,
+Qihoo 360 Inc.). The fix was developed by Matt Caswell of the OpenSSL
+development team.
+
+SSL_peek() hang on empty record (CVE-2016-6305)
+===============================================
+
+Severity: Moderate
+
+OpenSSL 1.1.0 SSL/TLS will hang during a call to SSL_peek() if the peer sends an
+empty record. This could be exploited by a malicious peer in a Denial Of Service
+attack.
+
+OpenSSL 1.1.0 users should upgrade to 1.1.0a
+
+This issue was reported to OpenSSL on 10th September 2016 by Alex Gaynor. The
+fix was developed by Matt Caswell of the OpenSSL development team.
+
+SWEET32 Mitigation (CVE-2016-2183)
+==================================
+
+Severity: Low
+
+SWEET32 (https://sweet32.info) is an attack on older block cipher algorithms
+that use a block size of 64 bits. In mitigation for the SWEET32 attack DES based
+ciphersuites have been moved from the HIGH cipherstring group to MEDIUM in
+OpenSSL 1.0.1 and OpenSSL 1.0.2. OpenSSL 1.1.0 since release has had these
+ciphersuites disabled by default.
+
+OpenSSL 1.0.2 users should upgrade to 1.0.2i
+OpenSSL 1.0.1 users should upgrade to 1.0.1u
+
+This issue was reported to OpenSSL on 16th August 2016 by Karthikeyan
+Bhargavan and Gaetan Leurent (INRIA). The fix was developed by Rich Salz of the
+OpenSSL development team.
+
+OOB write in MDC2_Update() (CVE-2016-6303)
+==========================================
+
+Severity: Low
+
+An overflow can occur in MDC2_Update() either if called directly or
+through the EVP_DigestUpdate() function using MDC2. If an attacker
+is able to supply very large amounts of input data after a previous
+call to EVP_EncryptUpdate() with a partial block then a length check
+can overflow resulting in a heap corruption.
+
+The amount of data needed is comparable to SIZE_MAX which is impractical
+on most platforms.
+
+OpenSSL 1.0.2 users should upgrade to 1.0.2i
+OpenSSL 1.0.1 users should upgrade to 1.0.1u
+
+This issue was reported to OpenSSL on 11th August 2016 by Shi Lei (Gear Team,
+Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL
+development team.
+
+Malformed SHA512 ticket DoS (CVE-2016-6302)
+===========================================
+
+Severity: Low
+
+If a server uses SHA512 for TLS session ticket HMAC it is vulnerable to a
+DoS attack where a malformed ticket will result in an OOB read which will
+ultimately crash.
+
+The use of SHA512 in TLS session tickets is comparatively rare as it requires
+a custom server callback and ticket lookup mechanism.
+
+OpenSSL 1.0.2 users should upgrade to 1.0.2i
+OpenSSL 1.0.1 users should upgrade to 1.0.1u
+
+This issue was reported to OpenSSL on 19th August 2016 by Shi Lei (Gear Team,
+Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL
+development team.
+
+OOB write in BN_bn2dec() (CVE-2016-2182)
+========================================
+
+Severity: Low
+
+The function BN_bn2dec() does not check the return value of BN_div_word().
+This can cause an OOB write if an application uses this function with an
+overly large BIGNUM. This could be a problem if an overly large certificate
+or CRL is printed out from an untrusted source. TLS is not affected because
+record limits will reject an oversized certificate before it is parsed.
+
+OpenSSL 1.0.2 users should upgrade to 1.0.2i
+OpenSSL 1.0.1 users should upgrade to 1.0.1u
+
+This issue was reported to OpenSSL on 2nd August 2016 by Shi Lei (Gear Team,
+Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL
+development team.
+
+OOB read in TS_OBJ_print_bio() (CVE-2016-2180)
+==============================================
+
+Severity: Low
+
+The function TS_OBJ_print_bio() misuses OBJ_obj2txt(): the return value is
+the total length the OID text representation would use and not the amount
+of data written. This will result in OOB reads when large OIDs are presented.
+
+OpenSSL 1.0.2 users should upgrade to 1.0.2i
+OpenSSL 1.0.1 users should upgrade to 1.0.1u
+
+This issue was reported to OpenSSL on 21st July 2016 by Shi Lei (Gear Team,
+Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL
+development team.
+
+Pointer arithmetic undefined behaviour (CVE-2016-2177)
+======================================================
+
+Severity: Low
+
+Avoid some undefined pointer arithmetic
+
+A common idiom in the codebase is to check limits in the following manner:
+"p + len > limit"
+
+Where "p" points to some malloc'd data of SIZE bytes and
+limit == p + SIZE
+
+"len" here could be from some externally supplied data (e.g. from a TLS
+message).
+
+The rules of C pointer arithmetic are such that "p + len" is only well
+defined where len <= SIZE. Therefore the above idiom is actually
+undefined behaviour.
+
+For example this could cause problems if some malloc implementation
+provides an address for "p" such that "p + len" actually overflows for
+values of len that are too big and therefore p + len < limit.
+
+OpenSSL 1.0.2 users should upgrade to 1.0.2i
+OpenSSL 1.0.1 users should upgrade to 1.0.1u
+
+This issue was reported to OpenSSL on 4th May 2016 by Guido Vranken. The
+fix was developed by Matt Caswell of the OpenSSL development team.
+
+Constant time flag not preserved in DSA signing (CVE-2016-2178)
+===============================================================
+
+Severity: Low
+
+Operations in the DSA signing algorithm should run in constant time in order to
+avoid side channel attacks. A flaw in the OpenSSL DSA implementation means that
+a non-constant time codepath is followed for certain operations. This has been
+demonstrated through a cache-timing attack to be sufficient for an attacker to
+recover the private DSA key.
+
+OpenSSL 1.0.2 users should upgrade to 1.0.2i
+OpenSSL 1.0.1 users should upgrade to 1.0.1u
+
+This issue was reported to OpenSSL on 23rd May 2016 by César Pereida (Aalto
+University), Billy Brumley (Tampere University of Technology), and Yuval Yarom
+(The University of Adelaide and NICTA). The fix was developed by César Pereida.
+
+DTLS buffered message DoS (CVE-2016-2179)
+=========================================
+
+Severity: Low
+
+In a DTLS connection where handshake messages are delivered out-of-order those
+messages that OpenSSL is not yet ready to process will be buffered for later
+use. Under certain circumstances, a flaw in the logic means that those messages
+do not get removed from the buffer even though the handshake has been completed.
+An attacker could force up to approx. 15 messages to remain in the buffer when
+they are no longer required. These messages will be cleared when the DTLS
+connection is closed. The default maximum size for a message is 100k. Therefore
+the attacker could force an additional 1500k to be consumed per connection. By
+opening many simulataneous connections an attacker could cause a DoS attack
+through memory exhaustion.
+
+OpenSSL 1.0.2 DTLS users should upgrade to 1.0.2i
+OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1u
+
+This issue was reported to OpenSSL on 22nd June 2016 by Quan Luo. The fix was
+developed by Matt Caswell of the OpenSSL development team.
+
+DTLS replay protection DoS (CVE-2016-2181)
+==========================================
+
+Severity: Low
+
+A flaw in the DTLS replay attack protection mechanism means that records that
+arrive for future epochs update the replay protection "window" before the MAC
+for the record has been validated. This could be exploited by an attacker by
+sending a record for the next epoch (which does not have to decrypt or have a
+valid MAC), with a very large sequence number. This means that all subsequent
+legitimate packets are dropped causing a denial of service for a specific
+DTLS connection.
+
+OpenSSL 1.0.2 DTLS users should upgrade to 1.0.2i
+OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1u
+
+This issue was reported to OpenSSL on 21st November 2015 by the OCAP audit team.
+The fix was developed by Matt Caswell of the OpenSSL development team.
+
+Certificate message OOB reads (CVE-2016-6306)
+=============================================
+
+Severity: Low
+
+In OpenSSL 1.0.2 and earlier some missing message length checks can result in
+OOB reads of up to 2 bytes beyond an allocated buffer. There is a theoretical
+DoS risk but this has not been observed in practice on common platforms.
+
+The messages affected are client certificate, client certificate request and
+server certificate. As a result the attack can only be performed against
+a client or a server which enables client authentication.
+
+OpenSSL 1.1.0 is not affected.
+
+OpenSSL 1.0.2 users should upgrade to 1.0.2i
+OpenSSL 1.0.1 users should upgrade to 1.0.1u
+
+This issue was reported to OpenSSL on 22nd August 2016 by Shi Lei (Gear Team,
+Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL
+development team.
+
+Excessive allocation of memory in tls_get_message_header() (CVE-2016-6307)
+==========================================================================
+
+Severity: Low
+
+A TLS message includes 3 bytes for its length in the header for the message.
+This would allow for messages up to 16Mb in length. Messages of this length are
+excessive and OpenSSL includes a check to ensure that a peer is sending
+reasonably sized messages in order to avoid too much memory being consumed to
+service a connection. A flaw in the logic of version 1.1.0 means that memory for
+the message is allocated too early, prior to the excessive message length
+check. Due to way memory is allocated in OpenSSL this could mean an attacker
+could force up to 21Mb to be allocated to service a connection. This could lead
+to a Denial of Service through memory exhaustion. However, the excessive message
+length check still takes place, and this would cause the connection to
+immediately fail. Assuming that the application calls SSL_free() on the failed
+conneciton in a timely manner then the 21Mb of allocated memory will then be
+immediately freed again. Therefore the excessive memory allocation will be
+transitory in nature. This then means that there is only a security impact if:
+
+1) The application does not call SSL_free() in a timely manner in the
+event that the connection fails
+or
+2) The application is working in a constrained environment where there
+is very little free memory
+or
+3) The attacker initiates multiple connection attempts such that there
+are multiple connections in a state where memory has been allocated for
+the connection; SSL_free() has not yet been called; and there is
+insufficient memory to service the multiple requests.
+
+Except in the instance of (1) above any Denial Of Service is likely to
+be transitory because as soon as the connection fails the memory is
+subsequently freed again in the SSL_free() call. However there is an
+increased risk during this period of application crashes due to the lack
+of memory - which would then mean a more serious Denial of Service.
+
+This issue does not affect DTLS users.
+
+OpenSSL 1.1.0 TLS users should upgrade to 1.1.0a
+
+This issue was reported to OpenSSL on 18th September 2016 by Shi Lei (Gear Team,
+Qihoo 360 Inc.). The fix was developed by Matt Caswell of the OpenSSL
+development team.
+
+Excessive allocation of memory in dtls1_preprocess_fragment() (CVE-2016-6308)
+=============================================================================
+
+Severity: Low
+
+This issue is very similar to CVE-2016-6307. The underlying defect is different
+but the security analysis and impacts are the same except that it impacts DTLS.
+
+A DTLS message includes 3 bytes for its length in the header for the message.
+This would allow for messages up to 16Mb in length. Messages of this length are
+excessive and OpenSSL includes a check to ensure that a peer is sending
+reasonably sized messages in order to avoid too much memory being consumed to
+service a connection. A flaw in the logic of version 1.1.0 means that memory for
+the message is allocated too early, prior to the excessive message length
+check. Due to way memory is allocated in OpenSSL this could mean an attacker
+could force up to 21Mb to be allocated to service a connection. This could lead
+to a Denial of Service through memory exhaustion. However, the excessive message
+length check still takes place, and this would cause the connection to
+immediately fail. Assuming that the application calls SSL_free() on the failed
+conneciton in a timely manner then the 21Mb of allocated memory will then be
+immediately freed again. Therefore the excessive memory allocation will be
+transitory in nature. This then means that there is only a security impact if:
+
+1) The application does not call SSL_free() in a timely manner in the
+event that the connection fails
+or
+2) The application is working in a constrained environment where there
+is very little free memory
+or
+3) The attacker initiates multiple connection attempts such that there
+are multiple connections in a state where memory has been allocated for
+the connection; SSL_free() has not yet been called; and there is
+insufficient memory to service the multiple requests.
+
+Except in the instance of (1) above any Denial Of Service is likely to
+be transitory because as soon as the connection fails the memory is
+subsequently freed again in the SSL_free() call. However there is an
+increased risk during this period of application crashes due to the lack
+of memory - which would then mean a more serious Denial of Service.
+
+This issue does not affect TLS users.
+
+OpenSSL 1.1.0 DTLS users should upgrade to 1.1.0a
+
+This issue was reported to OpenSSL on 18th September 2016 by Shi Lei (Gear Team,
+Qihoo 360 Inc.). The fix was developed by Matt Caswell of the OpenSSL
+development team.
+
+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/20160922.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 da6d047..f9b4a5d 100644
--- a/news/vulnerabilities.xml
+++ b/news/vulnerabilities.xml
@@ -5,7 +5,595 @@
1.0.0 on 20100329
-->
-<security updated="20160503">
+<security updated="20160922">
+ <issue public="20160922">
+ <impact severity="High"/>
+ <cve name="2016-6304"/>
+ <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.1" version="1.0.1s"/>
+ <affects base="1.0.1" version="1.0.1t"/>
+ <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"/>
+ <affects base="1.0.2" version="1.0.2g"/>
+ <affects base="1.0.2" version="1.0.2h"/>
+ <affects base="1.1.0" version="1.1.0"/>
+ <fixed base="1.0.1" version="1.0.1u" date="20160922"/>
+ <fixed base="1.0.2" version="1.0.2i" date="20160922"/>
+ <fixed base="1.1.0" version="1.1.0a" date="20160922"/>
+
+ <description>
+ A malicious client can send an excessively large OCSP Status Request extension.
+ If that client continually requests renegotiation, sending a large OCSP Status
+ Request extension each time, then there will be unbounded memory growth on the
+ server. This will eventually lead to a Denial Of Service attack through memory
+ exhaustion. Servers with a default configuration are vulnerable even if they do
+ not support OCSP. Builds using the "no-ocsp" build time option are not affected.
+
+ Servers using OpenSSL versions prior to 1.0.1g are not vulnerable in a default
+ configuration, instead only if an application explicitly enables OCSP stapling
+ support.
+ </description>
+ <advisory url="/news/secadv/20160922.txt"/>
+ <reported source="Shi Lei (Gear Team, Qihoo 360 Inc.)"/>
+ </issue>
+ <issue public="20160922">
+ <impact severity="Moderate"/>
+ <cve name="2016-6305"/>
+ <affects base="1.1.0" version="1.1.0"/>
+ <fixed base="1.1.0" version="1.1.0a" date="20160922"/>
+
+ <description>
+ OpenSSL 1.1.0 SSL/TLS will hang during a call to SSL_peek() if the peer sends an
+ empty record. This could be exploited by a malicious peer in a Denial Of Service
+ attack.
+ </description>
+ <advisory url="/news/secadv/20160922.txt"/>
+ <reported source="Alex Gaynor"/>
+ </issue>
+ <issue public="20160824">
+ <impact severity="Low"/>
+ <cve name="2016-6303"/>
+ <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.1" version="1.0.1s"/>
+ <affects base="1.0.1" version="1.0.1t"/>
+ <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"/>
+ <affects base="1.0.2" version="1.0.2g"/>
+ <affects base="1.0.2" version="1.0.2h"/>
+ <fixed base="1.0.1" version="1.0.1u" date="20160922"/>
+ <fixed base="1.0.2" version="1.0.2i" date="20160922"/>
+
+ <description>
+ An overflow can occur in MDC2_Update() either if called directly or
+ through the EVP_DigestUpdate() function using MDC2. If an attacker
+ is able to supply very large amounts of input data after a previous
+ call to EVP_EncryptUpdate() with a partial block then a length check
+ can overflow resulting in a heap corruption.
+
+ The amount of data needed is comparable to SIZE_MAX which is impractical
+ on most platforms.
+ </description>
+ <advisory url="/news/secadv/20160922.txt"/>
+ <reported source="Shi Lei (Gear Team, Qihoo 360 Inc.)"/>
+ </issue>
+ <issue public="20160823">
+ <impact severity="Low"/>
+ <cve name="2016-6302"/>
+ <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.1" version="1.0.1s"/>
+ <affects base="1.0.1" version="1.0.1t"/>
+ <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"/>
+ <affects base="1.0.2" version="1.0.2g"/>
+ <affects base="1.0.2" version="1.0.2h"/>
+ <fixed base="1.0.1" version="1.0.1u" date="20160922"/>
+ <fixed base="1.0.2" version="1.0.2i" date="20160922"/>
+
+ <description>
+ If a server uses SHA512 for TLS session ticket HMAC it is vulnerable to a
+ DoS attack where a malformed ticket will result in an OOB read which will
+ ultimately crash.
+
+ The use of SHA512 in TLS session tickets is comparatively rare as it requires
+ a custom server callback and ticket lookup mechanism.
+ </description>
+ <advisory url="/news/secadv/20160922.txt"/>
+ <reported source="Shi Lei (Gear Team, Qihoo 360 Inc.)"/>
+ </issue>
+ <issue public="20160816">
+ <impact severity="Low"/>
+ <cve name="2016-2182"/>
+ <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.1" version="1.0.1s"/>
+ <affects base="1.0.1" version="1.0.1t"/>
+ <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"/>
+ <affects base="1.0.2" version="1.0.2g"/>
+ <affects base="1.0.2" version="1.0.2h"/>
+ <fixed base="1.0.1" version="1.0.1u" date="20160922"/>
+ <fixed base="1.0.2" version="1.0.2i" date="20160922"/>
+
+ <description>
+ The function BN_bn2dec() does not check the return value of BN_div_word().
+ This can cause an OOB write if an application uses this function with an
+ overly large BIGNUM. This could be a problem if an overly large certificate
+ or CRL is printed out from an untrusted source. TLS is not affected because
+ record limits will reject an oversized certificate before it is parsed.
+ </description>
+ <advisory url="/news/secadv/20160922.txt"/>
+ <reported source="Shi Lei (Gear Team, Qihoo 360 Inc.)"/>
+ </issue>
+ <issue public="20160722">
+ <impact severity="Low"/>
+ <cve name="2016-2180"/>
+ <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.1" version="1.0.1s"/>
+ <affects base="1.0.1" version="1.0.1t"/>
+ <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"/>
+ <affects base="1.0.2" version="1.0.2g"/>
+ <affects base="1.0.2" version="1.0.2h"/>
+ <fixed base="1.0.1" version="1.0.1u" date="20160922"/>
+ <fixed base="1.0.2" version="1.0.2i" date="20160922"/>
+
+ <description>
+ The function TS_OBJ_print_bio() misuses OBJ_obj2txt(): the return value is
+ the total length the OID text representation would use and not the amount
+ of data written. This will result in OOB reads when large OIDs are presented.
+ </description>
+ <advisory url="/news/secadv/20160922.txt"/>
+ <reported source="Shi Lei (Gear Team, Qihoo 360 Inc.)"/>
+ </issue>
+ <issue public="20160601">
+ <impact severity="Low"/>
+ <cve name="2016-2177"/>
+ <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.1" version="1.0.1s"/>
+ <affects base="1.0.1" version="1.0.1t"/>
+ <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"/>
+ <affects base="1.0.2" version="1.0.2g"/>
+ <affects base="1.0.2" version="1.0.2h"/>
+ <fixed base="1.0.1" version="1.0.1u" date="20160922"/>
+ <fixed base="1.0.2" version="1.0.2i" date="20160922"/>
+
+ <description>
+ Avoid some undefined pointer arithmetic
+
+ A common idiom in the codebase is to check limits in the following manner:
+ "p + len > limit"
+
+ Where "p" points to some malloc'd data of SIZE bytes and
+ limit == p + SIZE
+
+ "len" here could be from some externally supplied data (e.g. from a TLS
+ message).
+
+ The rules of C pointer arithmetic are such that "p + len" is only well
+ defined where len <= SIZE. Therefore the above idiom is actually
+ undefined behaviour.
+
+ For example this could cause problems if some malloc implementation
+ provides an address for "p" such that "p + len" actually overflows for
+ values of len that are too big and therefore p + len < limit.
+ </description>
+ <advisory url="/news/secadv/20160922.txt"/>
+ <reported source="Guido Vranken"/>
+ </issue>
+ <issue public="20160607">
+ <impact severity="Low"/>
+ <cve name="2016-2178"/>
+ <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.1" version="1.0.1s"/>
+ <affects base="1.0.1" version="1.0.1t"/>
+ <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"/>
+ <affects base="1.0.2" version="1.0.2g"/>
+ <affects base="1.0.2" version="1.0.2h"/>
+ <fixed base="1.0.1" version="1.0.1u" date="20160922"/>
+ <fixed base="1.0.2" version="1.0.2i" date="20160922"/>
+
+ <description>
+ Operations in the DSA signing algorithm should run in constant time in order to
+ avoid side channel attacks. A flaw in the OpenSSL DSA implementation means that
+ a non-constant time codepath is followed for certain operations. This has been
+ demonstrated through a cache-timing attack to be sufficient for an attacker to
+ recover the private DSA key.
+ </description>
+ <advisory url="/news/secadv/20160922.txt"/>
+ <reported source="César Pereida (Aalto University), Billy Brumley (Tampere University of Technology), and Yuval Yarom (The University of Adelaide and NICTA)"/>
+ </issue>
+ <issue public="20160822">
+ <impact severity="Low"/>
+ <cve name="2016-2179"/>
+ <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.1" version="1.0.1s"/>
+ <affects base="1.0.1" version="1.0.1t"/>
+ <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"/>
+ <affects base="1.0.2" version="1.0.2g"/>
+ <affects base="1.0.2" version="1.0.2h"/>
+ <fixed base="1.0.1" version="1.0.1u" date="20160922"/>
+ <fixed base="1.0.2" version="1.0.2i" date="20160922"/>
+
+ <description>
+ In a DTLS connection where handshake messages are delivered out-of-order those
+ messages that OpenSSL is not yet ready to process will be buffered for later
+ use. Under certain circumstances, a flaw in the logic means that those messages
+ do not get removed from the buffer even though the handshake has been completed.
+ An attacker could force up to approx. 15 messages to remain in the buffer when
+ they are no longer required. These messages will be cleared when the DTLS
+ connection is closed. The default maximum size for a message is 100k. Therefore
+ the attacker could force an additional 1500k to be consumed per connection. By
+ opening many simulataneous connections an attacker could cause a DoS attack
+ through memory exhaustion.
+ </description>
+ <advisory url="/news/secadv/20160922.txt"/>
+ <reported source="Quan Luo"/>
+ </issue>
+ <issue public="20160819">
+ <impact severity="Low"/>
+ <cve name="2016-2181"/>
+ <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.1" version="1.0.1s"/>
+ <affects base="1.0.1" version="1.0.1t"/>
+ <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"/>
+ <affects base="1.0.2" version="1.0.2g"/>
+ <affects base="1.0.2" version="1.0.2h"/>
+ <fixed base="1.0.1" version="1.0.1u" date="20160922"/>
+ <fixed base="1.0.2" version="1.0.2i" date="20160922"/>
+
+ <description>
+ A flaw in the DTLS replay attack protection mechanism means that records that
+ arrive for future epochs update the replay protection "window" before the MAC
+ for the record has been validated. This could be exploited by an attacker by
+ sending a record for the next epoch (which does not have to decrypt or have a
+ valid MAC), with a very large sequence number. This means that all subsequent
+ legitimate packets are dropped causing a denial of service for a specific
+ DTLS connection.
+ </description>
+ <advisory url="/news/secadv/20160922.txt"/>
+ <reported source="OCAP audit team"/>
+ </issue>
+ <issue public="20160921">
+ <impact severity="Low"/>
+ <cve name="2016-6306"/>
+ <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.1" version="1.0.1s"/>
+ <affects base="1.0.1" version="1.0.1t"/>
+ <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"/>
+ <affects base="1.0.2" version="1.0.2g"/>
+ <affects base="1.0.2" version="1.0.2h"/>
+ <fixed base="1.0.1" version="1.0.1u" date="20160922"/>
+ <fixed base="1.0.2" version="1.0.2i" date="20160922"/>
+ <description>
+ In OpenSSL 1.0.2 and earlier some missing message length checks can result in
+ OOB reads of up to 2 bytes beyond an allocated buffer. There is a theoretical
+ DoS risk but this has not been observed in practice on common platforms.
+
+ The messages affected are client certificate, client certificate request and
+ server certificate. As a result the attack can only be performed against
+ a client or a server which enables client authentication.
+ </description>
+ <advisory url="/news/secadv/20160922.txt"/>
+ <reported source="Shi Lei (Gear Team, Qihoo 360 Inc.)"/>
+ </issue>
+ <issue public="20160921">
+ <impact severity="Low"/>
+ <cve name="2016-6307"/>
+ <affects base="1.1.0" version="1.1.0"/>
+ <fixed base="1.1.0" version="1.1.0a" date="20160922"/>
+
+ <description>
+ A TLS message includes 3 bytes for its length in the header for the message.
+ This would allow for messages up to 16Mb in length. Messages of this length are
+ excessive and OpenSSL includes a check to ensure that a peer is sending
+ reasonably sized messages in order to avoid too much memory being consumed to
+ service a connection. A flaw in the logic of version 1.1.0 means that memory for
+ the message is allocated too early, prior to the excessive message length
+ check. Due to way memory is allocated in OpenSSL this could mean an attacker
+ could force up to 21Mb to be allocated to service a connection. This could lead
+ to a Denial of Service through memory exhaustion. However, the excessive message
+ length check still takes place, and this would cause the connection to
+ immediately fail. Assuming that the application calls SSL_free() on the failed
+ conneciton in a timely manner then the 21Mb of allocated memory will then be
+ immediately freed again. Therefore the excessive memory allocation will be
+ transitory in nature. This then means that there is only a security impact if:
+
+ 1) The application does not call SSL_free() in a timely manner in the
+ event that the connection fails
+ or
+ 2) The application is working in a constrained environment where there
+ is very little free memory
+ or
+ 3) The attacker initiates multiple connection attempts such that there
+ are multiple connections in a state where memory has been allocated for
+ the connection; SSL_free() has not yet been called; and there is
+ insufficient memory to service the multiple requests.
+
+ Except in the instance of (1) above any Denial Of Service is likely to
+ be transitory because as soon as the connection fails the memory is
+ subsequently freed again in the SSL_free() call. However there is an
+ increased risk during this period of application crashes due to the lack
+ of memory - which would then mean a more serious Denial of Service.
+ </description>
+ <advisory url="/news/secadv/20160922.txt"/>
+ <reported source="Shi Lei (Gear Team, Qihoo 360 Inc.)"/>
+ </issue>
+ <issue public="20160921">
+ <impact severity="Low"/>
+ <cve name="2016-6308"/>
+ <affects base="1.1.0" version="1.1.0"/>
+ <fixed base="1.1.0" version="1.1.0a" date="20160922"/>
+
+ <description>
+ A DTLS message includes 3 bytes for its length in the header for the message.
+ This would allow for messages up to 16Mb in length. Messages of this length are
+ excessive and OpenSSL includes a check to ensure that a peer is sending
+ reasonably sized messages in order to avoid too much memory being consumed to
+ service a connection. A flaw in the logic of version 1.1.0 means that memory for
+ the message is allocated too early, prior to the excessive message length
+ check. Due to way memory is allocated in OpenSSL this could mean an attacker
+ could force up to 21Mb to be allocated to service a connection. This could lead
+ to a Denial of Service through memory exhaustion. However, the excessive message
+ length check still takes place, and this would cause the connection to
+ immediately fail. Assuming that the application calls SSL_free() on the failed
+ conneciton in a timely manner then the 21Mb of allocated memory will then be
+ immediately freed again. Therefore the excessive memory allocation will be
+ transitory in nature. This then means that there is only a security impact if:
+
+ 1) The application does not call SSL_free() in a timely manner in the
+ event that the connection fails
+ or
+ 2) The application is working in a constrained environment where there
+ is very little free memory
+ or
+ 3) The attacker initiates multiple connection attempts such that there
+ are multiple connections in a state where memory has been allocated for
+ the connection; SSL_free() has not yet been called; and there is
+ insufficient memory to service the multiple requests.
+
+ Except in the instance of (1) above any Denial Of Service is likely to
+ be transitory because as soon as the connection fails the memory is
+ subsequently freed again in the SSL_free() call. However there is an
+ increased risk during this period of application crashes due to the lack
+ of memory - which would then mean a more serious Denial of Service.
+ </description>
+ <advisory url="/news/secadv/20160922.txt"/>
+ <reported source="Shi Lei (Gear Team, Qihoo 360 Inc.)"/>
+ </issue>
<issue public="20160503">
<impact severity="High"/>
<cve name="2016-2108"/>
More information about the openssl-commits
mailing list