The branch master has been updated via 0a4c853aded41a16c9b7029406ec1e82dbb6079a (commit) from 63ef2bb8b25bfe47b73d85db8f9c4940fa965374 (commit)
- Log ----------------------------------------------------------------- commit 0a4c853aded41a16c9b7029406ec1e82dbb6079a Author: Matt Caswell <m...@openssl.org> Date: Thu Dec 7 13:42:20 2017 +0000 Updates for the new release ----------------------------------------------------------------------- Summary of changes: news/newsflash.txt | 2 ++ news/secadv/20171207.txt | 84 +++++++++++++++++++++++++++++++++++++++++++ news/vulnerabilities.xml | 93 ++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 179 insertions(+) create mode 100644 news/secadv/20171207.txt diff --git a/news/newsflash.txt b/news/newsflash.txt index aa7a53d..4bb3ed9 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 +07-Dec-2017: <a href="/news/secadv/20171207.txt">Security Advisory</a>: one security fix +07-Dec-2017: OpenSSL 1.0.2n is now available, including bug and security fixes 02-Nov-2017: <a href="/news/secadv/20171102.txt">Security Advisory</a>: Internal carry bug on X86_64 02-Nov-2017: OpenSSL 1.1.0g is now available, including bug and security fixes 02-Nov-2017: OpenSSL 1.0.2m is now available, including bug and security fixes diff --git a/news/secadv/20171207.txt b/news/secadv/20171207.txt new file mode 100644 index 0000000..c5370f4 --- /dev/null +++ b/news/secadv/20171207.txt @@ -0,0 +1,84 @@ + +OpenSSL Security Advisory [07 Dec 2017] +======================================== + +Read/write after SSL object in error state (CVE-2017-3737) +========================================================== + +Severity: Moderate + +OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state" +mechanism. The intent was that if a fatal error occurred during a handshake then +OpenSSL would move into the error state and would immediately fail if you +attempted to continue the handshake. This works as designed for the explicit +handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()), +however due to a bug it does not work correctly if SSL_read() or SSL_write() is +called directly. In that scenario, if the handshake fails then a fatal error +will be returned in the initial function call. If SSL_read()/SSL_write() is +subsequently called by the application for the same SSL object then it will +succeed and the data is passed without being decrypted/encrypted directly from +the SSL/TLS record layer. + +In order to exploit this issue an application bug would have to be present that +resulted in a call to SSL_read()/SSL_write() being issued after having already +received a fatal error. + +This issue does not affect OpenSSL 1.1.0. + +OpenSSL 1.0.2 users should upgrade to 1.0.2n + +This issue was reported to OpenSSL on 10th November 2017 by David Benjamin +(Google). The fix was proposed by David Benjamin and implemented by Matt Caswell +of the OpenSSL development team. + +rsaz_1024_mul_avx2 overflow bug on x86_64 (CVE-2017-3738) +========================================================= + +Severity: Low + +There is an overflow bug in the AVX2 Montgomery multiplication procedure +used in exponentiation with 1024-bit moduli. No EC algorithms are affected. +Analysis suggests that attacks against RSA and DSA as a result of this defect +would be very difficult to perform and are not believed likely. Attacks +against DH1024 are considered just feasible, because most of the work +necessary to deduce information about a private key may be performed offline. +The amount of resources required for such an attack would be significant. +However, for an attack on TLS to be meaningful, the server would have to share +the DH1024 private key among multiple clients, which is no longer an option +since CVE-2016-0701. + +This only affects processors that support the AVX2 but not ADX extensions +like Intel Haswell (4th generation). + +Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732 +and CVE-2015-3193. + +Due to the low severity of this issue we are not issuing a new release of +OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 1.1.0h when it +becomes available. The fix is also available in commit e502cc86d in the OpenSSL +git repository. + +OpenSSL 1.0.2 users should upgrade to 1.0.2n + +This issue was reported to OpenSSL on 22nd November 2017 by David Benjamin +(Google). The issue was originally found via the OSS-Fuzz project. The fix was +developed by Andy Polyakov of the OpenSSL development team. + +Note +==== + +Support for version 1.0.1 ended on 31st December 2016. 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/20171207.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 0880fbc..c96da20 100644 --- a/news/vulnerabilities.xml +++ b/news/vulnerabilities.xml @@ -8,6 +8,99 @@ <!-- The updated attribute should be the same as the first public issue, unless an old entry was updated. --> <security updated="20171102"> + <issue public="20171207"> + <impact severity="Moderate"/> + <cve name="2017-3737"/> + <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.0.2" version="1.0.2i"/> + <affects base="1.0.2" version="1.0.2j"/> + <affects base="1.0.2" version="1.0.2k"/> + <affects base="1.0.2" version="1.0.2l"/> + <affects base="1.0.2" version="1.0.2m"/> + <fixed base="1.0.2" version="1.0.2n" date="20171207"/> + <problemtype>Unauthenticated read/unencrypted write</problemtype> + <title>Read/write after SSL object in error state</title> + <description> + OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state" + mechanism. The intent was that if a fatal error occurred during a handshake then + OpenSSL would move into the error state and would immediately fail if you + attempted to continue the handshake. This works as designed for the explicit + handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()), + however due to a bug it does not work correctly if SSL_read() or SSL_write() is + called directly. In that scenario, if the handshake fails then a fatal error + will be returned in the initial function call. If SSL_read()/SSL_write() is + subsequently called by the application for the same SSL object then it will + succeed and the data is passed without being decrypted/encrypted directly from + the SSL/TLS record layer. + + In order to exploit this issue an application bug would have to be present that + resulted in a call to SSL_read()/SSL_write() being issued after having already + received a fatal error. + </description> + <advisory url="/news/secadv/20171207.txt"/> + <reported source="David Benjamin (Google)"/> + </issue> + <issue public="20171207"> + <impact severity="Low"/> + <cve name="2017-3738"/> + <affects base="1.1.0" version="1.1.0"/> + <affects base="1.1.0" version="1.1.0a"/> + <affects base="1.1.0" version="1.1.0b"/> + <affects base="1.1.0" version="1.1.0c"/> + <affects base="1.1.0" version="1.1.0d"/> + <affects base="1.1.0" version="1.1.0e"/> + <affects base="1.1.0" version="1.1.0f"/> + <affects base="1.1.0" version="1.1.0g"/> + <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.0.2" version="1.0.2i"/> + <affects base="1.0.2" version="1.0.2j"/> + <affects base="1.0.2" version="1.0.2k"/> + <affects base="1.0.2" version="1.0.2l"/> + <affects base="1.0.2" version="1.0.2m"/> + <fixed base="1.0.2" version="1.0.2n" date="20171207"/> + <fixed base="1.1.0" version="1.1.0h-dev" date="20171207"/> + <problemtype>carry-propagating bug</problemtype> + <title>bn_sqrx8x_internal carry bug on x86_64</title> + <description> + There is an overflow bug in the AVX2 Montgomery multiplication procedure + used in exponentiation with 1024-bit moduli. No EC algorithms are affected. + Analysis suggests that attacks against RSA and DSA as a result of this defect + would be very difficult to perform and are not believed likely. Attacks + against DH1024 are considered just feasible, because most of the work + necessary to deduce information about a private key may be performed offline. + The amount of resources required for such an attack would be significant. + However, for an attack on TLS to be meaningful, the server would have to share + the DH1024 private key among multiple clients, which is no longer an option + since CVE-2016-0701. + + This only affects processors that support the AVX2 but not ADX extensions + like Intel Haswell (4th generation). + + Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732 + and CVE-2015-3193. + + Due to the low severity of this issue we are not issuing a new release of + OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 1.1.0h when it + becomes available. The fix is also available in commit e502cc86d in the OpenSSL + git repository. + </description> + <advisory url="/news/secadv/20171207.txt"/> + <reported source="David Benjamin (Google)/Google OSS-Fuzz"/> + </issue> <issue public="20171102"> <impact severity="Moderate"/> <cve name="2017-3736"/> _____ openssl-commits mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-commits