--- /dev/null
+
+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
<!-- 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"/>