1.0.0 on 20100329
-->
-<security updated="20150319">
+<!-- The updated attribute should be the same as the first public issue,
+ unless an old entry was updated. -->
+<security updated="20180814">
+ <issue public="20180612">
+ <impact severity="Low"/>
+ <cve name="2018-0732"/>
+ <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.1.0" version="1.1.0h"/>
+ <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"/>
+ <affects base="1.0.2" version="1.0.2n"/>
+ <affects base="1.0.2" version="1.0.2o"/>
+ <fixed base="1.1.0" version="1.1.0i" date="20180814">
+ <git hash="ea7abeeabf92b7aca160bdd0208636d4da69f4f4"/>
+ </fixed>
+ <fixed base="1.0.2" version="1.0.2p" date="20180814">
+ <git hash="3984ef0b72831da8b3ece4745cac4f8575b19098"/>
+ </fixed>
+ <problemtype>Client side Denial of Service</problemtype>
+ <title>Client DoS due to large DH parameter</title>
+ <description>
+ During key agreement in a TLS handshake using a DH(E) based ciphersuite
+ a malicious server can send a very large prime value to the client. This
+ will cause the client to spend an unreasonably long period of time
+ generating a key for this prime resulting in a hang until the client has
+ finished. This could be exploited in a Denial Of Service attack.
+ </description>
+ <advisory url="/news/secadv/20180612.txt"/>
+ <reported source="Guido Vranken"/>
+ </issue>
+ <issue public="20180416">
+ <impact severity="Low"/>
+ <cve name="2018-0737"/>
+ <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.1.0" version="1.1.0h"/>
+ <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"/>
+ <affects base="1.0.2" version="1.0.2n"/>
+ <affects base="1.0.2" version="1.0.2o"/>
+ <fixed base="1.1.0" version="1.1.0i" date="20180814">
+ <git hash="6939eab03a6e23d2bd2c3f5e34fe1d48e542e787"/>
+ </fixed>
+ <fixed base="1.0.2" version="1.0.2p" date="20180814">
+ <git hash="349a41da1ad88ad87825414752a8ff5fdd6a6c3f"/>
+ </fixed>
+ <problemtype>Constant time issue</problemtype>
+ <title>Cache timing vulnerability in RSA Key Generation</title>
+ <description>
+ The OpenSSL RSA Key generation algorithm has been shown to be vulnerable
+ to a cache timing side channel attack. An attacker with sufficient access
+ to mount cache timing attacks during the RSA key generation process could
+ recover the private key.
+ </description>
+ <advisory url="/news/secadv/20180416.txt"/>
+ <reported source="Alejandro Cabrera Aldaya, Billy Brumley, Cesar Pereida Garcia and Luis Manuel Alvarez Tapia"/>
+ </issue>
+ <issue public="20180327">
+ <impact severity="Moderate"/>
+ <cve name="2018-0739"/>
+ <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.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"/>
+ <affects base="1.0.2" version="1.0.2n"/>
+ <fixed base="1.1.0" version="1.1.0h" date="20180327">
+ <git hash="2ac4c6f7b2b2af20c0e2b0ba05367e454cd11b33"/>
+ </fixed>
+ <fixed base="1.0.2" version="1.0.2o" date="20180327">
+ <git hash="9310d45087ae546e27e61ddf8f6367f29848220d"/>
+ </fixed>
+ <problemtype>Stack overflow</problemtype>
+ <title>Constructed ASN.1 types with a recursive definition could exceed the stack</title>
+ <description>
+ Constructed ASN.1 types with a recursive definition (such as can be found
+ in PKCS7) could eventually exceed the stack given malicious input with
+ excessive recursion. This could result in a Denial Of Service attack.
+ There are no such structures used within SSL/TLS that come from untrusted
+ sources so this is considered safe.
+ </description>
+ <advisory url="/news/secadv/20180327.txt"/>
+ <reported source="OSS-fuzz"/>
+ </issue>
+ <issue public="20180327">
+ <impact severity="Moderate"/>
+ <cve name="2018-0733"/>
+ <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"/>
+ <fixed base="1.1.0" version="1.1.0h" date="20180327">
+ <git hash="56d5a4bfcaf37fa420aef2bb881aa55e61cf5f2f"/>
+ </fixed>
+ <problemtype>Message forgery</problemtype>
+ <title>Incorrect CRYPTO_memcmp on HP-UX PA-RISC</title>
+ <description>
+ Because of an implementation bug the PA-RISC CRYPTO_memcmp function is
+ effectively reduced to only comparing the least significant bit of each
+ byte. This allows an attacker to forge messages that would be considered
+ as authenticated in an amount of tries lower than that guaranteed by the
+ security claims of the scheme. The module can only be compiled by the
+ HP-UX assembler, so that only HP-UX PA-RISC targets are affected.
+ </description>
+ <advisory url="/news/secadv/20180327.txt"/>
+ <reported source="Peter Waltenberg (IBM)"/>
+ </issue>
+ <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">
+ <git hash="898fb884b706aaeb283de4812340bb0bde8476dc"/>
+ </fixed>
+ <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">
+ <git hash="ca51bafc1a88d8b8348f5fd97adc5d6ca93f8e76"/>
+ </fixed>
+ <fixed base="1.1.0" version="1.1.0h" date="20180327">
+ <git hash="e502cc86df9dafded1694fceb3228ee34d11c11a"/>
+ </fixed>
+ <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"/>
+ <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.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"/>
+ <fixed base="1.0.2" version="1.0.2m" date="20171102">
+ <git hash="38d600147331d36e74174ebbd4008b63188b321b"/>
+ </fixed>
+ <fixed base="1.1.0" version="1.1.0g" date="20171102">
+ <git hash="4443cf7aa0099e5ce615c18cee249fff77fb0871"/>
+ </fixed>
+ <problemtype>carry-propagating bug</problemtype>
+ <title>bn_sqrx8x_internal carry bug on x86_64</title>
+ <description>
+ There is a carry propagating bug in the x86_64 Montgomery squaring procedure. 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 DH are considered just feasible (although very
+ difficult) 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 very significant and likely only
+ accessible to a limited number of attackers. An attacker would
+ additionally need online access to an unpatched system using the target
+ private key in a scenario with persistent DH parameters and a private
+ key that is shared between multiple clients.
+
+ This only affects processors that support the BMI1, BMI2 and ADX extensions like
+ Intel Broadwell (5th generation) and later or AMD Ryzen.
+ </description>
+ <advisory url="/news/secadv/20171102.txt"/>
+ <reported source="Google OSS-Fuzz"/>
+ </issue>
+ <issue public="20170828">
+ <impact severity="Low"/>
+ <cve name="2017-3735"/>
+ <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.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"/>
+ <fixed base="1.0.2" version="1.0.2m" date="20171102">
+ <git hash="31c8b265591a0aaa462a1f3eb5770661aaac67db"/>
+ </fixed>
+ <fixed base="1.1.0" version="1.1.0g" date="20171102">
+ <git hash="068b963bb7afc57f5bdd723de0dd15e7795d5822"/>
+ </fixed>
+ <problemtype>out-of-bounds read</problemtype>
+ <title>Possible Overread in parsing X.509 IPAdressFamily</title>
+ <description>
+ While parsing an IPAdressFamily extension in an X.509 certificate,
+ it is possible to do a one-byte overread. This would result in
+ an incorrect text display of the certificate.
+ </description>
+ <advisory url="/news/secadv/20170828.txt"/>
+ <reported source="Google OSS-Fuzz"/>
+ </issue>
+ <issue public="20170216">
+ <impact severity="High"/>
+ <cve name="2017-3733"/>
+ <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"/>
+ <fixed base="1.1.0" version="1.1.0e" date="20170216">
+ <git hash="4ad93618d26a3ea23d36ad5498ff4f59eff3a4d2"/>
+ </fixed>
+ <problemtype>protocol error</problemtype>
+ <title>Encrypt-Then-Mac renegotiation crash</title>
+ <description>
+ During a renegotiation handshake if the Encrypt-Then-Mac extension is
+ negotiated where it was not in the original handshake (or vice-versa) then
+ this can cause OpenSSL to crash (dependent on ciphersuite). Both clients
+ and servers are affected.
+ </description>
+ <advisory url="/news/secadv/20170216.txt"/>
+ <reported source="Joe Orton (Red Hat)" />
+ </issue>
+ <issue public="20170126">
+ <impact severity="Moderate"/>
+ <cve name="2017-3731"/>
+ <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.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"/>
+ <fixed base="1.1.0" version="1.1.0d" date="20170126">
+ <git hash="00d965474b22b54e4275232bc71ee0c699c5cd21"/>
+ </fixed>
+ <fixed base="1.0.2" version="1.0.2k" date="20170126">
+ <git hash="51d009043670a627d6abe66894126851cf3690e9"/>
+ </fixed>
+ <problemtype>out-of-bounds read</problemtype>
+ <title>Truncated packet could crash via OOB read</title>
+ <description>
+ If an SSL/TLS server or client is running on a 32-bit host, and a specific
+ cipher is being used, then a truncated packet can cause that server or
+ client to perform an out-of-bounds read, usually resulting in a crash.
+
+ For OpenSSL 1.1.0, the crash can be triggered when using
+ CHACHA20/POLY1305; users should upgrade to 1.1.0d.
+
+ For Openssl 1.0.2, the crash can be triggered when using RC4-MD5; users
+ who have not disabled that algorithm should update to 1.0.2k
+ </description>
+ <advisory url="/news/secadv/20170126.txt"/>
+ <reported source="Robert Święcki of Google" />
+ </issue>
+ <issue public="20170126">
+ <impact severity="Moderate"/>
+ <cve name="2017-3730"/>
+ <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"/>
+ <fixed base="1.1.0" version="1.1.0d" date="20170126">
+ <git hash="efbe126e3ebb9123ac9d058aa2bb044261342aaa"/>
+ </fixed>
+ <problemtype>NULL pointer deference</problemtype>
+ <title>Bad (EC)DHE parameters cause a client crash</title>
+ <description>
+ If a malicious server supplies bad parameters for a DHE or ECDHE key
+ exchange then this can result in the client attempting to dereference a
+ NULL pointer leading to a client crash. This could be exploited in a
+ Denial of Service attack.
+ </description>
+ <advisory url="/news/secadv/20170126.txt"/>
+ <reported source="Guido Vranken" />
+ </issue>
+ <issue public="20170126">
+ <impact severity="Moderate"/>
+ <cve name="2017-3732"/>
+ <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.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"/>
+ <fixed base="1.1.0" version="1.1.0d" date="20170126">
+ <git hash="a59b90bf491410f1f2bc4540cc21f1980fd14c5b"/>
+ </fixed>
+ <fixed base="1.0.2" version="1.0.2k" date="20170126">
+ <git hash="760d04342a495ee86bf5adc71a91d126af64397f"/>
+ </fixed>
+ <problemtype>carry-propagating bug</problemtype>
+ <title>BN_mod_exp may produce incorrect results on x86_64</title>
+ <description>
+ There is a carry propagating bug in the x86_64 Montgomery squaring
+ procedure. 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 DH are considered
+ just feasible (although very difficult) 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 very significant
+ and likely only accessible to a limited number of attackers. An attacker
+ would additionally need online access to an unpatched system using the
+ target private key in a scenario with persistent DH parameters and a
+ private key that is shared between multiple clients. For example this can
+ occur by default in OpenSSL DHE based SSL/TLS ciphersuites. Note: This
+ issue is very similar to CVE-2015-3193 but must be treated as a separate
+ problem.
+ </description>
+ <advisory url="/news/secadv/20170126.txt"/>
+ <reported source="OSS-Fuzz project" />
+ </issue>
+ <issue public="20161110">
+ <impact severity="High"/>
+ <cve name="2016-7054"/>
+ <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"/>
+ <fixed base="1.1.0" version="1.1.0c" date="20161110">
+ <git hash="99d97842ddb5fbbbfb5e9820a64ebd19afe569f6"/>
+ </fixed>
+ <problemtype>protocol error</problemtype>
+ <title>ChaCha20/Poly1305 heap-buffer-overflow</title>
+ <description>
+ TLS connections using *-CHACHA20-POLY1305 ciphersuites are susceptible to
+ a DoS attack by corrupting larger payloads. This can result in an OpenSSL
+ crash. This issue is not considered to be exploitable beyond a DoS.
+ </description>
+ <advisory url="/news/secadv/20161110.txt"/>
+ <reported source="Robert Święcki (Google Security Team)" date="20160925"/>
+ </issue>
+ <issue public="20161110">
+ <impact severity="Moderate"/>
+ <cve name="2016-7053"/>
+ <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"/>
+ <fixed base="1.1.0" version="1.1.0c" date="20161110">
+ <git hash="610b66267e41a32805ab54cbc580c5a6d5826cb4"/>
+ </fixed>
+ <problemtype>NULL pointer deference</problemtype>
+ <title>CMS Null dereference</title>
+ <description>
+ Applications parsing invalid CMS structures can crash with a NULL pointer
+ dereference. This is caused by a bug in the handling of the ASN.1 CHOICE
+ type in OpenSSL 1.1.0 which can result in a NULL value being passed to the
+ structure callback if an attempt is made to free certain invalid
+ encodings. Only CHOICE structures using a callback which do not handle
+ NULL value are affected.
+ </description>
+ <advisory url="/news/secadv/20161110.txt"/>
+ <reported source="Tyler Nighswander (ForAllSecure)" date="20161012"/>
+ </issue>
+ <issue public="20161110">
+ <impact severity="Low"/>
+ <cve name="2016-7055"/>
+ <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.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"/>
+ <fixed base="1.1.0" version="1.1.0c" date="20161110">
+ <git hash="2a7dd548a6f5d6f7f84a89c98323b70a2822406e"/>
+ </fixed>
+ <fixed base="1.0.2" version="1.0.2k" date="20170126">
+ <git hash="57c4b9f6a2f800b41ce2836986fe33640f6c3f8a"/>
+ </fixed>
+ <problemtype>carry propagating bug</problemtype>
+ <title>Montgomery multiplication may produce incorrect results</title>
+ <description>
+ There is a carry propagating bug in the Broadwell-specific Montgomery
+ multiplication procedure that handles input lengths divisible by, but
+ longer than 256 bits. Analysis suggests that attacks against RSA, DSA
+ and DH private keys are impossible. This is because the subroutine in
+ question is not used in operations with the private key itself and an
+ input of the attacker's direct choice. Otherwise the bug can manifest
+ itself as transient authentication and key negotiation failures or
+ reproducible erroneous outcome of public-key operations with specially
+ crafted input. Among EC algorithms only Brainpool P-512 curves are
+ affected and one presumably can attack ECDH key negotiation. Impact was
+ not analyzed in detail, because pre-requisites for attack are considered
+ unlikely. Namely multiple clients have to choose the curve in question and
+ the server has to share the private key among them, neither of which is
+ default behaviour. Even then only clients that chose the curve will be
+ affected.
+ </description>
+ <advisory url="/news/secadv/20161110.txt"/>
+ <reported source="Publicly reported" />
+ </issue>
+ <issue public="20160926">
+ <impact severity="Critical"/>
+ <cve name="2016-6309"/>
+ <affects base="1.1.0" version="1.1.0a"/>
+ <fixed base="1.1.0" version="1.1.0b" date="20160926">
+ <git hash="acacbfa7565c78d2273c0b2a2e5e803f44afefeb"/>
+ </fixed>
+
+ <problemtype>write to free</problemtype>
+ <description>
+ This issue only affects OpenSSL 1.1.0a, released on 22nd September 2016.
+
+ The patch applied to address CVE-2016-6307 resulted in an issue where if a
+ message larger than approx 16k is received then the underlying buffer to store
+ the incoming message is reallocated and moved. Unfortunately a dangling pointer
+ to the old location is left which results in an attempt to write to the
+ previously freed location. This is likely to result in a crash, however it
+ could potentially lead to execution of arbitrary code.
+ </description>
+ <advisory url="/news/secadv/20160926.txt"/>
+ <reported source="Robert Święcki (Google Security Team)" date="20160923"/>
+ </issue>
+ <issue public="20160926">
+ <impact severity="Moderate"/>
+ <cve name="2016-7052"/>
+ <affects base="1.0.2" version="1.0.2i"/>
+ <fixed base="1.0.2" version="1.0.2j" date="20160926">
+ <git hash="6e629b5be45face20b4ca71c4fcbfed78b864a2e"/>
+ </fixed>
+ <problemtype>NULL pointer exception</problemtype>
+ <description>
+ This issue only affects OpenSSL 1.0.2i, released on 22nd September 2016.
+
+ A bug fix which included a CRL sanity check was added to OpenSSL 1.1.0
+ but was omitted from OpenSSL 1.0.2i. As a result any attempt to use
+ CRLs in OpenSSL 1.0.2i will crash with a null pointer exception.
+ </description>
+ <advisory url="/news/secadv/20160926.txt"/>
+ <reported source="Bruce Stephens and Thomas Jakobi" date="20160922"/>
+ </issue>
+ <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">
+ <git hash="2c0d295e26306e15a92eb23a84a1802005c1c137"/>
+ </fixed>
+ <fixed base="1.0.2" version="1.0.2i" date="20160922">
+ <git hash="ea39b16b71e4e72a228a4535bd6d6a02c5edbc1f"/>
+ </fixed>
+ <fixed base="1.1.0" version="1.1.0a" date="20160922">
+ <git hash="a59ab1c4dd27a4c7c6e88f3c33747532fd144412"/>
+ </fixed>
+
+ <problemtype>memory leak</problemtype>
+ <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.)" date="20160829"/>
+ </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">
+ <git hash="63658103d4441924f8dbfc517b99bb54758a98b9"/>
+ </fixed>
+
+ <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" date="20160910"/>
+ </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">
+ <git hash="2b4029e68fd7002d2307e6c3cde0f3784eef9c83"/>
+ </fixed>
+ <fixed base="1.0.2" version="1.0.2i" date="20160922">
+ <git hash="1027ad4f34c30b8585592764b9a670ba36888269"/>
+ </fixed>
+
+ <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.)" date="20160811"/>
+ </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">
+ <git hash="1bbe48ab149893a78bf99c8eb8895c928900a16f"/>
+ </fixed>
+ <fixed base="1.0.2" version="1.0.2i" date="20160922">
+ <git hash="baaabfd8fdcec04a691695fad9a664bea43202b6"/>
+ </fixed>
+
+ <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.)" date="20160819"/>
+ </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.)" date="20160802"/>
+ </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.)" date="20160721"/>
+ </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" date="20160504"/>
+ </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)" date="20160523"/>
+ </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">
+ <git hash="00a4c1421407b6ac796688871b0a49a179c694d9"/>
+ </fixed>
+ <fixed base="1.0.2" version="1.0.2i" date="20160922">
+ <git hash="26f2c5774f117aea588e8f31fad38bcf14e83bec"/>
+ </fixed>
+
+ <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" date="20160622"/>
+ </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">
+ <git hash="b77ab018b79a00f789b0fb85596b446b08be4c9d"/>
+ </fixed>
+ <fixed base="1.0.2" version="1.0.2i" date="20160922">
+ <git hash="3884b47b7c255c2e94d9b387ee83c7e8bb981258"/>
+ </fixed>
+
+
+ <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" date="20151121"/>
+ </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">
+ <git hash="bb1a4866034255749ac578adb06a76335fc117b1"/>
+ </fixed>
+ <fixed base="1.0.2" version="1.0.2i" date="20160922">
+ <git hash="006a788c84e541c8920dd2ad85fb62b52185c519"/>
+ </fixed>
+ <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.)" date="20160822"/>
+ </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">
+ <git hash="4b390b6c3f8df925dc92a3dd6b022baa9a2f4650"/>
+ </fixed>
+
+ <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.)" date="20160818"/>
+ </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">
+ <git hash="df6b5e29ffea2d5a3e08de92fb765fdb21c7a21e"/>
+ </fixed>
+
+ <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.)" date="20160818"/>
+ </issue>
+ <issue public="20160503">
+ <impact severity="High"/>
+ <cve name="2016-2108"/>
+ <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.2" version="1.0.2"/>
+ <affects base="1.0.2" version="1.0.2a"/>
+ <affects base="1.0.2" version="1.0.2b"/>
+ <fixed base="1.0.1" version="1.0.1o" date="20160612"/>
+ <fixed base="1.0.2" version="1.0.2c" date="20160612"/>
+
+ <description>
+ This issue affected versions of OpenSSL prior to April 2015. The bug
+ causing the vulnerability was fixed on April 18th 2015, and released
+ as part of the June 11th 2015 security releases. The security impact
+ of the bug was not known at the time.
+
+ In previous versions of OpenSSL, ASN.1 encoding the value zero
+ represented as a negative integer can cause a buffer underflow
+ with an out-of-bounds write in i2c_ASN1_INTEGER. The ASN.1 parser does
+ not normally create "negative zeroes" when parsing ASN.1 input, and
+ therefore, an attacker cannot trigger this bug.
+
+ However, a second, independent bug revealed that the ASN.1 parser
+ (specifically, d2i_ASN1_TYPE) can misinterpret a large universal tag
+ as a negative zero value. Large universal tags are not present in any
+ common ASN.1 structures (such as X509) but are accepted as part of ANY
+ structures.
+
+ Therefore, if an application deserializes untrusted ASN.1 structures
+ containing an ANY field, and later reserializes them, an attacker may
+ be able to trigger an out-of-bounds write. This has been shown to
+ cause memory corruption that is potentially exploitable with some
+ malloc implementations.
+
+ Applications that parse and re-encode X509 certificates are known to
+ be vulnerable. Applications that verify RSA signatures on X509
+ certificates may also be vulnerable; however, only certificates with
+ valid signatures trigger ASN.1 re-encoding and hence the
+ bug. Specifically, since OpenSSL's default TLS X509 chain verification
+ code verifies the certificate chain from root to leaf, TLS handshakes
+ could only be targeted with valid certificates issued by trusted
+ Certification Authorities.
+ </description>
+ <advisory url="/news/secadv/20160503.txt"/>
+ <reported source="Huzaifa Sidhpurwala (Red Hat), Hanno Böck, David Benjamin (Google)" date="20160331"/>
+ </issue>
+ <issue public="20160503">
+ <impact severity="High"/>
+ <cve name="2016-2107"/>
+ <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.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"/>
+ <fixed base="1.0.1" version="1.0.1t" date="20160503"/>
+ <fixed base="1.0.2" version="1.0.2h" date="20160503">
+ <git hash="68595c0c2886e7942a14f98c17a55a88afb6c292"/>
+ </fixed>
+
+ <description>
+ A MITM attacker can use a padding oracle attack to decrypt traffic
+ when the connection uses an AES CBC cipher and the server support
+ AES-NI.
+
+ This issue was introduced as part of the fix for Lucky 13 padding
+ attack (CVE-2013-0169). The padding check was rewritten to be in
+ constant time by making sure that always the same bytes are read and
+ compared against either the MAC or padding bytes. But it no longer
+ checked that there was enough data to have both the MAC and padding
+ bytes.
+ </description>
+ <advisory url="/news/secadv/20160503.txt"/>
+ <reported source="Juraj Somorovsky" date="20160413"/>
+ </issue>
+ <issue public="20160503">
+ <impact severity="Low"/>
+ <cve name="2016-2105"/>
+ <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.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"/>
+ <fixed base="1.0.1" version="1.0.1t" date="20160503"/>
+ <fixed base="1.0.2" version="1.0.2h" date="20160503"/>
+
+ <description>
+ An overflow can occur in the EVP_EncodeUpdate() function which is used for
+ Base64 encoding of binary data. If an attacker is able to supply very
+ large amounts of input data then a length check can overflow resulting in
+ a heap corruption.
+
+ Internally to OpenSSL the EVP_EncodeUpdate() function is primarly used by the
+ PEM_write_bio* family of functions. These are mainly used within the OpenSSL
+ command line applications. These internal uses are not considered vulnerable
+ because all calls are bounded with length checks so no overflow is possible.
+ User applications that call these APIs directly with large amounts of untrusted
+ data may be vulnerable. (Note: Initial analysis suggested that the
+ PEM_write_bio* were vulnerable, and this is reflected in the patch commit
+ message. This is no longer believed to be the case).
+ </description>
+ <advisory url="/news/secadv/20160503.txt"/>
+ <reported source="Guido Vranken" date="20160303"/>
+ </issue>
+ <issue public="20160503">
+ <impact severity="Low"/>
+ <cve name="2016-2106"/>
+ <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.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"/>
+ <fixed base="1.0.1" version="1.0.1t" date="20160503"/>
+ <fixed base="1.0.2" version="1.0.2h" date="20160503"/>
+
+ <description>
+ An overflow can occur in the EVP_EncryptUpdate() function. 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. Following an analysis of all
+ OpenSSL internal usage of the EVP_EncryptUpdate() function all usage is
+ one of two forms. The first form is where the EVP_EncryptUpdate() call is
+ known to be the first called function after an EVP_EncryptInit(), and
+ therefore that specific call must be safe. The second form is where the
+ length passed to EVP_EncryptUpdate() can be seen from the code to be some
+ small value and therefore there is no possibility of an overflow. Since
+ all instances are one of these two forms, it is believed that there can be
+ no overflows in internal code due to this problem. It should be noted that
+ EVP_DecryptUpdate() can call EVP_EncryptUpdate() in certain code paths.
+ Also EVP_CipherUpdate() is a synonym for EVP_EncryptUpdate(). All
+ instances of these calls have also been analysed too and it is believed
+ there are no instances in internal usage where an overflow could occur.
+
+ This could still represent a security issue for end user code that calls
+ this function directly.
+ </description>
+ <advisory url="/news/secadv/20160503.txt"/>
+ <reported source="Guido Vranken" date="20160303"/>
+ </issue>
+ <issue public="20160503">
+ <impact severity="Low"/>
+ <cve name="2016-2109"/>
+ <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.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"/>
+ <fixed base="1.0.1" version="1.0.1t" date="20160503"/>
+ <fixed base="1.0.2" version="1.0.2h" date="20160503"/>
+
+ <description>
+ When ASN.1 data is read from a BIO using functions such as d2i_CMS_bio()
+ a short invalid encoding can casuse allocation of large amounts of memory
+ potentially consuming excessive resources or exhausting memory.
+
+ Any application parsing untrusted data through d2i BIO functions is
+ affected. The memory based functions such as d2i_X509() are *not*
+ affected. Since the memory based functions are used by the TLS library,
+ TLS applications are not affected.
+ </description>
+ <advisory url="/news/secadv/20160503.txt"/>
+ <reported source="Brian Carpenter" date="20160404"/>
+ </issue>
+ <issue public="20160503">
+ <impact severity="Low"/>
+ <cve name="2016-2176"/>
+ <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.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"/>
+ <fixed base="1.0.1" version="1.0.1t" date="20160503"/>
+ <fixed base="1.0.2" version="1.0.2h" date="20160503"/>
+
+ <description>
+ ASN1 Strings that are over 1024 bytes can cause an overread in
+ applications using the X509_NAME_oneline() function on EBCDIC systems.
+ This could result in arbitrary stack data being returned in the buffer.
+ </description>
+ <advisory url="/news/secadv/20160503.txt"/>
+ <reported source="Guido Vranken" date="20160305"/>
+ </issue>
+ <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" date="20151229"/>
+ </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)" date="20160207"/>
+ </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="Emilia Käsper (OpenSSL)" date="20160223"/>
+ </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" date="20160219"/>
+ </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" date="20160223"/>
+ </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" date="20160108"/>
+ </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)" date="20160210"/>
+ </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)" date="20160210"/>
+ </issue>
+ <issue public="20160128">
+ <impact severity="High"/>
+ <cve name="2016-0701"/>
+ <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"/>
+ <fixed base="1.0.2" version="1.0.2f" date="2016-0701"/>
+
+ <description>
+ Historically OpenSSL usually only ever generated DH parameters based on "safe"
+ primes. More recently (in version 1.0.2) support was provided for generating
+ X9.42 style parameter files such as those required for RFC 5114 support. The
+ primes used in such files may not be "safe". Where an application is using DH
+ configured with parameters based on primes that are not "safe" then an attacker
+ could use this fact to find a peer's private DH exponent. This attack requires
+ that the attacker complete multiple handshakes in which the peer uses the same
+ private DH exponent. For example this could be used to discover a TLS server's
+ private DH exponent if it's reusing the private DH exponent or it's using a
+ static DH ciphersuite.
+
+ OpenSSL provides the option SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE) in TLS.
+ It is not on by default. If the option is not set then the server reuses the
+ same private DH exponent for the life of the server process and would be
+ vulnerable to this attack. It is believed that many popular applications do set
+ this option and would therefore not be at risk.
+
+ OpenSSL before 1.0.2f will reuse the key if:
+ - SSL_CTX_set_tmp_dh()/SSL_set_tmp_dh() is used and SSL_OP_SINGLE_DH_USE is not
+ set.
+ - SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used, and both the
+ parameters and the key are set and SSL_OP_SINGLE_DH_USE is not used. This is
+ an undocumted feature and parameter files don't contain the key.
+ - Static DH ciphersuites are used. The key is part of the certificate and
+ so it will always reuse it. This is only supported in 1.0.2.
+
+ It will not reuse the key for DHE ciphers suites if:
+ - SSL_OP_SINGLE_DH_USE is set
+ - SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used and the
+ callback does not provide the key, only the parameters. The callback is
+ almost always used like this.
+
+ Non-safe primes are generated by OpenSSL when using:
+ - genpkey with the dh_rfc5114 option. This will write an X9.42 style file
+ including the prime-order subgroup size "q". This is supported since the 1.0.2
+ version. Older versions can't read files generated in this way.
+ - dhparam with the -dsaparam option. This has always been documented as
+ requiring the single use.
+
+ The fix for this issue adds an additional check where a "q" parameter is
+ available (as is the case in X9.42 based parameters). This detects the
+ only known attack, and is the only possible defense for static DH ciphersuites.
+ This could have some performance impact.
+
+ Additionally the SSL_OP_SINGLE_DH_USE option has been switched on by default
+ and cannot be disabled. This could have some performance impact.
+ </description>
+ <advisory url="/news/secadv/20160128.txt"/>
+ <reported source="Antonio Sanso (Adobe)" date="20160112"/>
+ </issue>
+ <issue public="20160128">
+ <impact severity="Low"/>
+ <cve name="2015-3197"/>
+ <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.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"/>
+ <fixed base="1.0.1" version="1.0.1r" date="20160128"/>
+ <fixed base="1.0.2" version="1.0.2f" date="20160128"/>
+
+ <description>
+ A malicious client can negotiate SSLv2 ciphers that have been disabled on the
+ server and complete SSLv2 handshakes even if all SSLv2 ciphers have been
+ disabled, provided that the SSLv2 protocol was not also disabled via
+ SSL_OP_NO_SSLv2.
+ </description>
+ <advisory url="/news/secadv/20160128.txt"/>
+ <reported source="Nimrod Aviram and Sebastian Schinzel" date="20151226"/>
+ </issue>
+ <issue public="20150811">
+ <impact severity="Low"/>
+ <cve name="2015-1794"/>
+ <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"/>
+ <fixed base="1.0.2" version="1.0.2e" date="20151203"/>
+
+ <description>
+ If a client receives a ServerKeyExchange for an anonymous DH ciphersuite with
+ the value of p set to 0 then a seg fault can occur leading to a possible denial
+ of service attack.
+ </description>
+ <advisory url="/news/secadv/20151203.txt"/>
+ <reported source="Guy Leaver (Cisco)" date="20150803"/>
+ </issue>
+ <issue public="20151203">
+ <cve name="2015-3193"/>
+ <impact severity="Moderate"/>
+ <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"/>
+ <fixed base="1.0.2" version="1.0.2e" date="20151203"/>
+
+ <description>
+ There is a carry propagating bug in the x86_64 Montgomery squaring procedure. 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 DH are considered just feasible (although very
+ difficult) 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 very significant and likely only
+ accessible to a limited number of attackers. An attacker would
+ additionally need online access to an unpatched system using the target
+ private key in a scenario with persistent DH parameters and a private
+ key that is shared between multiple clients. For example this can occur by
+ default in OpenSSL DHE based SSL/TLS ciphersuites.
+ </description>
+ <advisory url="/news/secadv/20151203.txt"/>
+ <reported source="Hanno Böck" date="20150813"/>
+ </issue>
+ <issue public="20151203">
+ <cve name="2015-3194"/>
+ <impact severity="Moderate"/>
+ <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.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"/>
+ <fixed base="1.0.2" version="1.0.2e" date="20151203"/>
+ <fixed base="1.0.1" version="1.0.1q" date="20151203"/>
+
+ <description>
+ The signature verification routines will crash with a NULL pointer dereference
+ if presented with an ASN.1 signature using the RSA PSS algorithm and absent
+ mask generation function parameter. Since these routines are used to verify
+ certificate signature algorithms this can be used to crash any certificate
+ verification operation and exploited in a DoS attack. Any application which
+ performs certificate verification is vulnerable including OpenSSL clients and
+ servers which enable client authentication.
+ </description>
+ <advisory url="/news/secadv/20151203.txt"/>
+ <reported source="Loïc Jonas Etienne (Qnective AG)" date="20150827"/>
+ </issue>
+ <issue public="20151203">
+ <cve name="2015-3195"/>
+ <impact severity="Moderate"/>
+ <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="0.9.8" version="0.9.8zf"/>
+ <affects base="0.9.8" version="0.9.8zg"/>
+ <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.0h"/>
+ <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.0" version="1.0.0r"/>
+ <affects base="1.0.0" version="1.0.0s"/>
+ <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.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"/>
+ <fixed base="1.0.2" version="1.0.2e" date="20151203"/>
+ <fixed base="1.0.1" version="1.0.1q" date="20151203"/>
+ <fixed base="1.0.0" version="1.0.0t" date="20151203"/>
+ <fixed base="0.9.8" version="0.9.8zh" date="20151203"/>
+
+ <description>
+ When presented with a malformed X509_ATTRIBUTE structure OpenSSL will leak
+ memory. This structure is used by the PKCS#7 and CMS routines so any
+ application which reads PKCS#7 or CMS data from untrusted sources is affected.
+ SSL/TLS is not affected.
+ </description>
+ <advisory url="/news/secadv/20151203.txt"/>
+ <reported source="Adam Langley (Google/BoringSSL) using libFuzzer" date="20151109"/>
+ </issue>
+ <issue public="20151203">
+ <cve name="2015-3196"/>
+ <impact severity="Low"/>
+ <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.0h"/>
+ <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.0" version="1.0.0r"/>
+ <affects base="1.0.0" version="1.0.0s"/>
+ <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.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"/>
+ <fixed base="1.0.2" version="1.0.2d" date="20150709"/>
+ <fixed base="1.0.1" version="1.0.1p" date="20150709"/>
+ <fixed base="1.0.0" version="1.0.0t" date="20151203"/>
+
+ <description>
+ If PSK identity hints are received by a multi-threaded client then
+ the values are wrongly updated in the parent SSL_CTX structure. This can
+ result in a race condition potentially leading to a double free of the
+ identify hint data.
+ </description>
+ <advisory url="/news/secadv/20151203.txt"/>
+ <reported source="Stephen Henson (OpenSSL)"/>
+ </issue>
+
+ <issue public="20150709">
+ <cve name="2015-1793"/>
+ <impact severity="High"/>
+ <affects base="1.0.1" version="1.0.1n"/>
+ <affects base="1.0.1" version="1.0.1o"/>
+ <affects base="1.0.2" version="1.0.2b"/>
+ <affects base="1.0.2" version="1.0.2c"/>
+ <fixed base="1.0.2" version="1.0.2d" date="20150709"/>
+ <fixed base="1.0.1" version="1.0.1p" date="20150709"/>
+
+ <description>
+ An error in the implementation of the alternative certificate
+ chain logic could allow an attacker to cause certain checks on
+ untrusted certificates to be bypassed, such as the CA flag,
+ enabling them to use a valid leaf certificate to act as a CA and
+ "issue" an invalid certificate.
+ </description>
+ <advisory url="/news/secadv/20150709.txt"/>
+ <reported source="Adam Langley and David Benjamin (Google/BoringSSL)" date="20150624"/>
+ </issue>
+ <issue public="20150611">
+ <cve name="2015-1788"/>
+ <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="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.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.2" version="1.0.2"/>
+ <affects base="1.0.2" version="1.0.2a"/>
+ <fixed base="1.0.2" version="1.0.2b" date="20150611"/>
+ <fixed base="1.0.1" version="1.0.1n" date="20150611"/>
+ <fixed base="1.0.0" version="1.0.0e" date="20110906"/>
+ <fixed base="0.9.8" version="0.9.8s" date="20120104"/>
+
+ <description>
+ When processing an ECParameters structure OpenSSL enters an infinite loop if
+ the curve specified is over a specially malformed binary polynomial field.
+
+ This can be used to perform denial of service against any
+ system which processes public keys, certificate requests or
+ certificates. This includes TLS clients and TLS servers with
+ client authentication enabled.
+ </description>
+ <advisory url="/news/secadv/20150611.txt"/>
+ <reported source="Joseph Birr-Pixton" date="20150406"/>
+ </issue>
+
+ <issue public="20150611">
+ <cve name="2015-1789"/>
+ <impact severity="Moderate"/>
+ <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="0.9.8" version="0.9.8zf"/>
+ <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.0" version="1.0.0r"/>
+ <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.2" version="1.0.2"/>
+ <affects base="1.0.2" version="1.0.2a"/>
+ <fixed base="1.0.2" version="1.0.2b" date="20150611"/>
+ <fixed base="1.0.1" version="1.0.1n" date="20150611"/>
+ <fixed base="1.0.0" version="1.0.0s" date="20150611"/>
+ <fixed base="0.9.8" version="0.9.8zg" date="20150611"/>
+
+ <description>
+ X509_cmp_time does not properly check the length of the ASN1_TIME
+ string and can read a few bytes out of bounds. In addition,
+ X509_cmp_time accepts an arbitrary number of fractional seconds in the
+ time string.
+
+ An attacker can use this to craft malformed certificates and CRLs of
+ various sizes and potentially cause a segmentation fault, resulting in
+ a DoS on applications that verify certificates or CRLs. TLS clients
+ that verify CRLs are affected. TLS clients and servers with client
+ authentication enabled may be affected if they use custom verification
+ callbacks.
+ </description>
+ <advisory url="/news/secadv/20150611.txt"/>
+ <reported source="Robert Święcki (Google Security Team)" date="20150408"/>
+ <reported source="Hanno Böck" date="20150411"/>
+ </issue>
+
+ <issue public="20150611">
+ <cve name="2015-1790"/>
+ <impact severity="Moderate"/>
+ <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="0.9.8" version="0.9.8zf"/>
+ <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.0" version="1.0.0r"/>
+ <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.2" version="1.0.2"/>
+ <affects base="1.0.2" version="1.0.2a"/>
+ <fixed base="1.0.2" version="1.0.2b" date="20150611"/>
+ <fixed base="1.0.1" version="1.0.1n" date="20150611"/>
+ <fixed base="1.0.0" version="1.0.0s" date="20150611"/>
+ <fixed base="0.9.8" version="0.9.8zg" date="20150611"/>
+
+ <description>
+ The PKCS#7 parsing code does not handle missing inner EncryptedContent
+ correctly. An attacker can craft malformed ASN.1-encoded PKCS#7 blobs
+ with missing content and trigger a NULL pointer dereference on parsing.
+
+ Applications that decrypt PKCS#7 data or otherwise parse PKCS#7
+ structures from untrusted sources are affected. OpenSSL clients and
+ servers are not affected.
+ </description>
+ <advisory url="/news/secadv/20150611.txt"/>
+ <reported source="Michal Zalewski (Google)" date="20150418"/>
+ </issue>
+
+ <issue public="20150611">
+ <cve name="2015-1792"/>
+ <impact severity="Moderate"/>
+ <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="0.9.8" version="0.9.8zf"/>
+ <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.0" version="1.0.0r"/>
+ <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.2" version="1.0.2"/>
+ <affects base="1.0.2" version="1.0.2a"/>
+ <fixed base="1.0.2" version="1.0.2b" date="20150611"/>
+ <fixed base="1.0.1" version="1.0.1n" date="20150611"/>
+ <fixed base="1.0.0" version="1.0.0s" date="20150611"/>
+ <fixed base="0.9.8" version="0.9.8zg" date="20150611"/>
+
+ <description>
+ When verifying a signedData message the CMS code can enter an infinite loop
+ if presented with an unknown hash function OID.
+
+ This can be used to perform denial of service against any system which
+ verifies signedData messages using the CMS code.
+ </description>
+ <advisory url="/news/secadv/20150611.txt"/>
+ <reported source="Johannes Bauer" date="20150331"/>
+ </issue>
+
+ <issue public="20150602">
+ <cve name="2015-1791"/>
+ <impact severity="Low"/>
+ <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="0.9.8" version="0.9.8zf"/>
+ <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.0" version="1.0.0r"/>
+ <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.2" version="1.0.2"/>
+ <affects base="1.0.2" version="1.0.2a"/>
+ <fixed base="1.0.2" version="1.0.2b" date="20150611"/>
+ <fixed base="1.0.1" version="1.0.1n" date="20150611"/>
+ <fixed base="1.0.0" version="1.0.0s" date="20150611"/>
+ <fixed base="0.9.8" version="0.9.8zg" date="20150611"/>
+
+ <description>
+ If a NewSessionTicket is received by a multi-threaded client when attempting to
+ reuse a previous ticket then a race condition can occur potentially leading to
+ a double free of the ticket data.
+ </description>
+ <advisory url="/news/secadv/20150611.txt"/>
+ <reported source="Emilia Käsper (OpenSSL)"/>
+ </issue>
+
+ <issue public="20150611">
+ <cve name="2014-8176"/>
+ <impact severity="Moderate"/>
+ <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="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.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"/>
+ <fixed base="1.0.1" version="1.0.1h" date="20140605"/>
+ <fixed base="1.0.0" version="1.0.0m" date="20140605"/>
+ <fixed base="0.9.8" version="0.9.8za" date="20140605"/>
+ <description>
+ This vulnerability does not affect current versions of OpenSSL. It
+ existed in previous OpenSSL versions and was fixed in June 2014.
+
+ If a DTLS peer receives application data between the ChangeCipherSpec
+ and Finished messages, buffering of such data may cause an invalid
+ free, resulting in a segmentation fault or potentially, memory
+ corruption.
+ </description>
+ <advisory url="/news/secadv/20150611.txt"/>
+ <reported source="Praveen Kariyanahalli, and subsequently by Ivan Fratric and Felix Groebert (Google)" date="20140328"/>
+ </issue>
<issue public="20150319">
<impact severity="High"/>
<cve name="2015-0291"/>
invalid signature algorithms extension a NULL pointer dereference will occur.
This can be exploited in a DoS attack against the server.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150319.txt"/>
- <reported source=" David Ramos (Stanford University)"/>
+ <advisory url="/news/secadv/20150319.txt"/>
+ <reported source=" David Ramos (Stanford University)" date="20150226"/>
</issue>
<issue public="20150319">
it is likely that a segmentation fault will be triggered, thus enabling a
potential DoS attack.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150319.txt"/>
- <reported source="Daniel Danner and Rainer Mueller"/>
+ <advisory url="/news/secadv/20150319.txt"/>
+ <reported source="Daniel Danner and Rainer Mueller" date="20150213"/>
</issue>
<issue public="20150319">
example of such an error could be that a DTLS1.0 only client is attempting to
connect to a DTLS1.2 only server.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150319.txt"/>
- <reported source="Per Allansson"/>
+ <advisory url="/news/secadv/20150319.txt"/>
+ <reported source="Per Allansson" date="20150127"/>
</issue>
<issue public="20150319">
application which performs certificate verification is vulnerable including
OpenSSL clients and servers which enable client authentication.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150319.txt"/>
+ <advisory url="/news/secadv/20150319.txt"/>
<reported source="Stephen Henson (OpenSSL development team)"/>
</issue>
application which performs certificate verification is vulnerable including
OpenSSL clients and servers which enable client authentication.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150319.txt"/>
- <reported source="Brian Carpenter"/>
+ <advisory url="/news/secadv/20150319.txt"/>
+ <reported source="Brian Carpenter" date="20150131"/>
</issue>
<issue public="20150319">
memory corruption via an invalid write. Such reuse is and has been
strongly discouraged and is believed to be rare.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150319.txt"/>
+ <advisory url="/news/secadv/20150319.txt"/>
<reported source="Emilia Käsper (OpenSSL development team)"/>
</issue>
otherwise parse PKCS#7 structures from untrusted sources are
affected. OpenSSL clients and servers are not affected.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150319.txt"/>
- <reported source="Michal Zalewski (Google)"/>
+ <advisory url="/news/secadv/20150319.txt"/>
+ <reported source="Michal Zalewski (Google)" date="20150216"/>
</issue>
<issue public="20150319">
Maliciously crafted base 64 data could trigger a segmenation fault or memory
corruption.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150319.txt"/>
- <reported source="Robert Dugal, also David Ramos"/>
+ <advisory url="/news/secadv/20150319.txt"/>
+ <reported source="Robert Dugal, also David Ramos, also Huzaifa Sidhpurwala (Red Hat)"/>
</issue>
<issue public="20150319">
servers that both support SSLv2 and enable export cipher suites by sending
a specially crafted SSLv2 CLIENT-MASTER-KEY message.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150319.txt"/>
+ <advisory url="/news/secadv/20150319.txt"/>
<reported source="Sean Burford (Google) and Emilia Käsper (OpenSSL development team)"/>
</issue>
ciphersuite being selected and a zero length ClientKeyExchange message being
sent by the client. This could be exploited in a DoS attack.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150319.txt"/>
+ <advisory url="/news/secadv/20150319.txt"/>
<reported source="Matt Caswell (OpenSSL development team)"/>
</issue>
been generated from a PRNG with insufficient entropy and therefore the output
may be predictable.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150319.txt"/>
+ <advisory url="/news/secadv/20150319.txt"/>
<reported source="Matt Caswell (OpenSSL development team)"/>
</issue>
for applications that receive EC private keys from untrusted
sources. This scenario is considered rare.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150319.txt"/>
+ <advisory url="/news/secadv/20150319.txt"/>
<reported source="The BoringSSL project"/>
</issue>
The function X509_to_X509_REQ will crash with a NULL pointer dereference if
the certificate key is invalid. This function is rarely used in practice.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150319.txt"/>
+ <advisory url="/news/secadv/20150319.txt"/>
<reported source="Brian Carpenter"/>
</issue>
memory leak could be exploited by an attacker in a Denial of Service
attack through memory exhaustion.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150108.txt"/>
+ <advisory url="/news/secadv/20150108.txt"/>
<reported source="Chris Mueller"/>
</issue>
<issue public="20141021">
<cve name="2014-3569"/>
- <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="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.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"/>
<fixed base="1.0.1" version="1.0.1k" date="20150108"/>
<fixed base="1.0.0" version="1.0.0p" date="20150108"/>
received the ssl method would be set to NULL which could later result in
a NULL pointer dereference.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150108.txt"/>
+ <advisory url="/news/secadv/20150108.txt"/>
<reported source="Frank Schmirler"/>
</issue>
ciphersuite using an ECDSA certificate if the server key exchange message
is omitted. This effectively removes forward secrecy from the ciphersuite.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150108.txt"/>
+ <advisory url="/news/secadv/20150108.txt"/>
<reported source="Karthikeyan Bhargavan of the PROSECCO team at INRIA"/>
</issue>
non-export RSA key exchange ciphersuite. A server could present a weak
temporary key and downgrade the security of the session.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150108.txt"/>
+ <advisory url="/news/secadv/20150108.txt"/>
<reported source="Karthikeyan Bhargavan of the PROSECCO team at INRIA"/>
</issue>
certificates containing DH keys: these are extremely rare and hardly ever
encountered.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150108.txt"/>
+ <advisory url="/news/secadv/20150108.txt"/>
<reported source="Karthikeyan Bhargavan of the PROSECCO team at INRIA"/>
</issue>
applications that rely on the uniqueness of the fingerprint (e.g.
certificate blacklists) may be affected.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150108.txt"/>
+ <advisory url="/news/secadv/20150108.txt"/>
<reported source="Antti Karjalainen and Tuomo Untinen from the Codenomicon CROSS program/Konrad Kraszewski from Google"/>
</issue>
attacker cannot control when the bug triggers, or no private key material
is involved.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20150108.txt"/>
+ <advisory url="/news/secadv/20150108.txt"/>
<reported source="Pieter Wuille (Blockstream)"/>
</issue>
whether SRTP is used or configured. Implementations of OpenSSL that
have been compiled with OPENSSL_NO_SRTP defined are not affected.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20141015.txt"/>
+ <advisory url="/news/secadv/20141015.txt"/>
<reported source="LibreSSL project"/>
</issue>
tickets an attacker could exploit this issue in a Denial Of Service
attack.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20141015.txt"/>
+ <advisory url="/news/secadv/20141015.txt"/>
</issue>
<issue public="20141015">
<cve name=""/> <!-- this is deliberate -->
could accept and complete a SSL 3.0 handshake, and clients could be
configured to send them.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20141015.txt"/>
+ <advisory url="/news/secadv/20141015.txt"/>
<reported source="Akamai Technologies"/>
</issue>
<issue public="20140806">
stack. Applications may be affected if they echo pretty printing output to the
attacker. OpenSSL SSL/TLS clients and servers themselves are not affected.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20140806.txt"/>
+ <advisory url="/news/secadv/20140806.txt"/>
<reported source="Ivan Fratric (Google)"/>
</issue>
<affects base="1.0.1" version="1.0.1h"/>
<fixed base="1.0.1" version="1.0.1i" date="20140806">
</fixed>
- <advisory url="http://www.openssl.org/news/secadv_20140806.txt"/>
+ <advisory url="/news/secadv/20140806.txt"/>
<reported source="Joonas Kuorilehto and Riku Hietamäki (Codenomicon)"/>
</issue>
<fixed base="1.0.0" version="1.0.0n" date="20140806">
</fixed>
<reported source="Gabor Tyukasz (LogMeIn Inc)"/>
- <advisory url="http://www.openssl.org/news/secadv_20140806.txt"/>
+ <advisory url="/news/secadv/20140806.txt"/>
</issue>
<issue public="20140806">
Denial of Service attack.
</description>
<reported source="Adam Langley and Wan-Teh Chang (Google)"/>
- <advisory url="http://www.openssl.org/news/secadv_20140806.txt"/>
+ <advisory url="/news/secadv/20140806.txt"/>
</issue>
<issue public="20140806">
Service attack.
</description>
<reported source="Adam Langley (Google)"/>
- <advisory url="http://www.openssl.org/news/secadv_20140806.txt"/>
+ <advisory url="/news/secadv/20140806.txt"/>
</issue>
<issue public="20140806">
leak memory. This could lead to a Denial of Service attack.
</description>
<reported source="Adam Langley (Google)"/>
- <advisory url="http://www.openssl.org/news/secadv_20140806.txt"/>
+ <advisory url="/news/secadv/20140806.txt"/>
</issue>
<issue public="20140806">
sending carefully crafted handshake messages.
</description>
<reported source="Felix Gröbert (Google)"/>
- <advisory url="http://www.openssl.org/news/secadv_20140806.txt"/>
+ <advisory url="/news/secadv/20140806.txt"/>
</issue>
<issue public="20140806">
protocol version, by modifying the client's TLS records.
</description>
<reported source="David Benjamin and Adam Langley (Google)"/>
- <advisory url="http://www.openssl.org/news/secadv_20140806.txt"/>
+ <advisory url="/news/secadv/20140806.txt"/>
</issue>
<issue public="20140806">
use are affected.
</description>
<reported source="Sean Devlin and Watson Ladd (Cryptography Services, NCC Group)"/>
- <advisory url="http://www.openssl.org/news/secadv_20140806.txt"/>
+ <advisory url="/news/secadv/20140806.txt"/>
</issue>
<issue public="20020730">
<affects base="0.9.6" version="0.9.6c"/>
<affects base="0.9.6" version="0.9.6d"/>
<fixed base="0.9.6" version="0.9.6e" date="20020730"/>
- <advisory url="http://www.openssl.org/news/secadv_20020730.txt"/>
+ <advisory url="/news/secadv/20020730.txt"/>
<reported source="OpenSSL Group (A.L. Digital)"/>
<description>
Inproper handling of ASCII representations of integers on
<affects base="0.9.6" version="0.9.6c"/>
<affects base="0.9.6" version="0.9.6d"/>
<fixed base="0.9.6" version="0.9.6e" date="20020730"/>
- <advisory url="http://www.openssl.org/news/secadv_20020730.txt"/>
+ <advisory url="/news/secadv/20020730.txt"/>
<reported source="OpenSSL Group (A.L. Digital)"/>
<description>
A buffer overflow allowed remote attackers to execute
<issue public="20020730">
<cve name="2002-0657"/>
- <advisory url="http://www.openssl.org/news/secadv_20020730.txt"/>
+ <advisory url="/news/secadv/20020730.txt"/>
+ <affects base="0.9.7" version="0.9.7-beta3"/>
+ <fixed base="0.9.7" version="0.9.7" date="20021210"/>
<reported source="OpenSSL Group (A.L. Digital)"/>
<description>
A buffer overflow when Kerberos is enabled allowed attackers
<issue public="20020730">
<cve name="2002-0659"/>
+ <advisory url="/news/secadv/20020730.txt"/>
<affects base="0.9.6" version="0.9.6a"/>
<affects base="0.9.6" version="0.9.6b"/>
<affects base="0.9.6" version="0.9.6c"/>
</description>
</issue>
- <issue>
+ <issue public="20020808">
<cve name="2002-1568"/>
<affects base="0.9.6" version="0.9.6e"/>
- <fixed base="0.9.6" version="0.9.6f" date="20020808"/>
+ <fixed base="0.9.6" version="0.9.6f" date="20020808">
+ <git hash="517a0e7fa0f5453c860a3aec17b678bd55d5aad7"/>
+ </fixed>
<description>
The use of assertions when detecting buffer overflow attacks
allowed remote attackers to cause a denial of service (crash) by
<affects base="0.9.6" version="0.9.6h"/>
<fixed base="0.9.7" version="0.9.7a" date="20030219"/>
<fixed base="0.9.6" version="0.9.6i" date="20030219"/>
- <advisory url="http://www.openssl.org/news/secadv_20030219.txt"/>
+ <advisory url="/news/secadv/20030219.txt"/>
<description>
sl3_get_record in s3_pkt.c did not perform a MAC computation if an
incorrect block cipher padding was used, causing an information leak
<affects base="0.9.7" version="0.9.7a"/>
<fixed base="0.9.6" version="0.9.6j" date="20030410"/>
<fixed base="0.9.7" version="0.9.7b" date="20030410"/>
- <advisory url="http://www.openssl.org/news/secadv_20030319.txt"/>
+ <advisory url="/news/secadv/20030319.txt"/>
<description>
The SSL and TLS components allowed remote attackers to perform an
unauthorized RSA private key operation via a modified Bleichenbacher
<affects base="0.9.6" version="0.9.6i"/>
<affects base="0.9.7" version="0.9.7"/>
<affects base="0.9.7" version="0.9.7a"/>
- <advisory url="http://www.openssl.org/news/secadv_20030317.txt"/>
+ <advisory url="/news/secadv/20030317.txt"/>
<fixed base="0.9.7" version="0.9.7b" date="20030410"/>
<fixed base="0.9.6" version="0.9.6j" date="20030410"/>
<description>
<affects base="0.9.7" version="0.9.7b"/>
<fixed base="0.9.7" version="0.9.7c" date="20030930"/>
<fixed base="0.9.6" version="0.9.6k" date="20030930"/>
- <advisory url="http://www.openssl.org/news/secadv_20030930.txt"/>
+ <advisory url="/news/secadv/20030930.txt"/>
<reported source="NISCC"/>
<description>
An integer overflow could allow remote attackers to cause a denial of
<affects base="0.9.6" version="0.9.6j"/>
<fixed base="0.9.6" version="0.9.6k" date="20030930"/>
<fixed base="0.9.7" version="0.9.7c" date="20030930"/>
- <advisory url="http://www.openssl.org/news/secadv_20030930.txt"/>
+ <advisory url="/news/secadv/20030930.txt"/>
<reported source="NISCC"/>
<description>
Incorrect tracking of the number of characters in certain
<affects base="0.9.7" version="0.9.7a"/>
<affects base="0.9.7" version="0.9.7b"/>
<fixed base="0.9.7" version="0.9.7c" date="20030930"/>
- <advisory url="http://www.openssl.org/news/secadv_20030930.txt"/>
+ <advisory url="/news/secadv/20030930.txt"/>
<reported source="NISCC"/>
<description>
Certain ASN.1 encodings that were rejected as invalid by the parser could
<cve name="2003-0851"/>
<affects base="0.9.6" version="0.9.6k"/>
<fixed base="0.9.6" version="0.9.6l" date="20031104"/>
- <advisory url="http://www.openssl.org/news/secadv_20031104.txt"/>
+ <advisory url="/news/secadv/20031104.txt"/>
<reported source="Novell"/>
<description>
A flaw in OpenSSL 0.9.6k (only) would cause certain ASN.1 sequences to
<affects base="0.9.7" version="0.9.7c"/>
<fixed base="0.9.7" version="0.9.7d" date="20040317"/>
<fixed base="0.9.6" version="0.9.6m" date="20040317"/>
- <advisory url="http://www.openssl.org/news/secadv_20040317.txt"/>
+ <advisory url="/news/secadv/20040317.txt"/>
<reported source="OpenSSL group"/>
<description>
The Codenomicon TLS Test Tool uncovered a null-pointer assignment in the
<affects base="0.9.6" version="0.9.6a"/>
<affects base="0.9.6" version="0.9.6b"/>
<affects base="0.9.6" version="0.9.6c"/>
- <advisory url="http://www.openssl.org/news/secadv_20030317.txt"/>
+ <fixed base="0.9.6" version="0.9.6d" date="20020603"/> <!-- guessed date -->
+
+ <advisory url="/news/secadv/20030317.txt"/>
<reported source="OpenSSL group"/>
<description>
The Codenomicon TLS Test Tool found that some unknown message types
<affects base="0.9.7" version="0.9.7c"/>
<fixed base="0.9.7" version="0.9.7d" date="20040317"/>
<reported source="OpenSSL group (Stephen Henson)"/>
- <advisory url="http://www.openssl.org/news/secadv_20040317.txt"/>
+ <advisory url="/news/secadv/20040317.txt"/>
<description>
A flaw in SSL/TLS handshaking code when using Kerberos ciphersuites.
A remote attacker could perform a carefully crafted SSL/TLS handshake
<affects base="0.9.6" version="0.9.6k"/>
<affects base="0.9.6" version="0.9.6l"/>
<affects base="0.9.6" version="0.9.6m"/>
- <fixed base="0.9.7" version="0.9.7f" date="20050322"/>
+ <fixed base="0.9.7" version="0.9.7f" date="20050322">
+ <git hash="5fee606442a6738fd06a756d7076be53b7b7734c"/>
+ </fixed>
<fixed base="0.9.6" version="0.9.6-cvs" date="20041114"/>
<!-- der_chop was removed 20041114 -->
<fixed base="0.9.7" version="0.9.7h" date="20051011"/>
<fixed base="0.9.8" version="0.9.8a" date="20051011"/>
- <advisory url="http://www.openssl.org/news/secadv_20051011.txt"/>
+ <advisory url="/news/secadv/20051011.txt"/>
<reported source="researcher"/>
<description>
<fixed base="0.9.7" version="0.9.7k" date="20060905"/>
<fixed base="0.9.8" version="0.9.8c" date="20060905"/>
- <advisory url="http://www.openssl.org/news/secadv_20060905.txt"/>
+ <advisory url="/news/secadv/20060905.txt"/>
<reported source="openssl"/>
<description>
<fixed base="0.9.7" version="0.9.7l" date="20060928"/>
<fixed base="0.9.8" version="0.9.8d" date="20060928"/>
- <advisory url="http://www.openssl.org/news/secadv_20060928.txt"/>
+ <advisory url="/news/secadv/20060928.txt"/>
<reported source="openssl"/>
<description>
<fixed base="0.9.7" version="0.9.7l" date="20060928"/>
<fixed base="0.9.8" version="0.9.8d" date="20060928"/>
- <advisory url="http://www.openssl.org/news/secadv_20060928.txt"/>
+ <advisory url="/news/secadv/20060928.txt"/>
<reported source="openssl"/>
<description>
<fixed base="0.9.7" version="0.9.7l" date="20060928"/>
<fixed base="0.9.8" version="0.9.8d" date="20060928"/>
- <advisory url="http://www.openssl.org/news/secadv_20060928.txt"/>
+ <advisory url="/news/secadv/20060928.txt"/>
<reported source="openssl"/>
<description>
<fixed base="0.9.7" version="0.9.7l" date="20060928"/>
<fixed base="0.9.8" version="0.9.8d" date="20060928"/>
- <advisory url="http://www.openssl.org/news/secadv_20060928.txt"/>
+ <advisory url="/news/secadv/20060928.txt"/>
<reported source="openssl"/>
<description>
<affects base="0.9.8" version="0.9.8d"/>
<affects base="0.9.8" version="0.9.8e"/>
<fixed base="0.9.8" version="0.9.8f" date="20071012"/>
- <advisory url="http://www.openssl.org/news/secadv_20071012.txt"/>
+ <advisory url="/news/secadv/20071012.txt"/>
<reported source="Andy Polyakov"/>
<description>
<affects base="0.9.8" version="0.9.8d"/>
<affects base="0.9.8" version="0.9.8e"/>
<fixed base="0.9.8" version="0.9.8f" date="20071012"/>
- <advisory url="http://www.openssl.org/news/secadv_20071012.txt"/>
+ <advisory url="/news/secadv/20071012.txt"/>
<reported source="Moritz Jodeit"/>
<description>
<issue public="20071129">
<cve name="2007-5502"/>
- <advisory url="http://www.openssl.org/news/secadv_20071129.txt"/>
+ <advisory url="/news/secadv/20071129.txt"/>
<reported source="Geoff Lowe"/>
-
+ <affects base="fips-1.1" version="fips-1.1.1"/>
+ <fixed base="fips-1.1" version="fips-1.1.2" date="20071201"/>
<description>
The PRNG implementation for the OpenSSL FIPS Object Module 1.1.1 does
not perform auto-seeding during the FIPS self-test, which generates
<affects base="0.9.8" version="0.9.8f"/>
<affects base="0.9.8" version="0.9.8g"/>
<fixed base="0.9.8" version="0.9.8h" date="20080528"/>
- <advisory url="http://www.openssl.org/news/secadv_20080528.txt"/>
+ <advisory url="/news/secadv/20080528.txt"/>
<reported source="codenomicon"/>
<description>
Testing using the Codenomicon TLS test suite discovered a flaw in the
<affects base="0.9.8" version="0.9.8f"/>
<affects base="0.9.8" version="0.9.8g"/>
<fixed base="0.9.8" version="0.9.8h" date="20080528"/>
- <advisory url="http://www.openssl.org/news/secadv_20080528.txt"/>
+ <advisory url="/news/secadv/20080528.txt"/>
<reported source="codenomicon"/>
<description>
Testing using the Codenomicon TLS test suite discovered a flaw if the
<affects base="0.9.8" version="0.9.8h"/>
<affects base="0.9.8" version="0.9.8i"/>
<fixed base="0.9.8" version="0.9.8j" date="20090107"/>
- <advisory url="http://www.openssl.org/news/secadv_20090107.txt"/>
+ <advisory url="/news/secadv/20090107.txt"/>
<reported source="google"/>
<description>
<affects base="0.9.8" version="0.9.8i"/>
<affects base="0.9.8" version="0.9.8j"/>
<fixed base="0.9.8" version="0.9.8k" date="20090325"/>
- <advisory url="http://www.openssl.org/news/secadv_20090325.txt"/>
+ <advisory url="/news/secadv/20090325.txt"/>
<description>
The function ASN1_STRING_print_ex() when used to print a BMPString or
UniversalString will crash with an invalid memory access if the
<affects base="0.9.8" version="0.9.8i"/>
<affects base="0.9.8" version="0.9.8j"/>
<fixed base="0.9.8" version="0.9.8k" date="20090325"/>
- <advisory url="http://www.openssl.org/news/secadv_20090325.txt"/>
+ <advisory url="/news/secadv/20090325.txt"/>
<reported source="Ivan Nestlerode, IBM"/>
<description>
The function CMS_verify() does not correctly handle an error condition
<affects base="0.9.8" version="0.9.8j"/>
<fixed base="0.9.8" version="0.9.8k" date="20090325"/>
<reported source="Paolo Ganci"/>
- <advisory url="http://www.openssl.org/news/secadv_20090325.txt"/>
+ <advisory url="/news/secadv/20090325.txt"/>
<description>
When a malformed ASN1 structure is received it's contents are freed up and
zeroed and an error condition returned. On a small number of platforms where
<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"/>
- <fixed base="0.9.8" version="0.9.8i" date="20080915"/>
+ <fixed base="0.9.8" version="0.9.8i" date="20080915">
+ <git hash="1cbf663a6c89dcf8f7706d30a8bae675e2e0199a"/>
+ </fixed>
<reported source="Alex Lam"/>
<description>
Fix a NULL pointer dereference if a DTLS server recieved
<affects base="0.9.8" version="0.9.8k"/>
<affects base="0.9.8" version="0.9.8l"/>
<fixed base="0.9.8" version="0.9.8m" date="20100120"/>
- <advisory url="http://www.openssl.org/news/secadv_20091111.txt"/>
+ <advisory url="/news/secadv/20091111.txt"/>
<description>
Implement RFC5746 to address vulnerabilities in SSL/TLS renegotiation.
</description>
<issue public="20090205">
<cve name="2009-1387"/>
+ <advisory url="https://rt.openssl.org/Ticket/Display.html?id=1838&user=guest&pass=guest"/>
<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"/>
<issue public="20090512">
<cve name="2009-1377"/>
+ <advisory url="https://rt.openssl.org/Ticket/Display.html?id=1930&user=guest&pass=guest"/>
+ <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"/>
+ <fixed base="0.9.8" version="0.9.8m" date="20100120">
+ <git hash="88b48dc68024dcc437da4296c9fb04419b0ccbe1"/>
+ </fixed>
+ <reported source="Daniel Mentz, Robin Seggelmann"/>
+ <description>
+Fix a denial of service flaw in the DTLS implementation.
+Records are buffered if they arrive with a future epoch to be
+processed after finishing the corresponding handshake. There is
+currently no limitation to this buffer allowing an attacker to perform
+a DOS attack to a DTLS server by sending records with future epochs until there is no
+memory left.
+ </description>
+ </issue>
+
+ <issue public="20090512">
<cve name="2009-1378"/>
+ <advisory url="https://rt.openssl.org/Ticket/Display.html?id=1931&user=guest&pass=guest"/>
+ <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"/>
+ <fixed base="0.9.8" version="0.9.8m" date="20100120">
+ <git hash="abda7c114791fa7fe95672ec7a66fc4733c40dbc"/>
+ </fixed>
+ <reported source="Daniel Mentz, Robin Seggelmann"/>
+ <description>
+ Fix a denial of service flaw in the DTLS implementation.
+In dtls1_process_out_of_seq_message() the check if the current message
+is already buffered was missing. For every new message was memory
+allocated, allowing an attacker to perform an denial of service attack
+against a DTLS server by sending out of seq handshake messages until there is no memory
+left.
+ </description>
+ </issue>
+
+ <issue public="20090512">
<cve name="2009-1379"/>
+ <advisory url="https://rt.openssl.org/Ticket/Display.html?id=1923&user=guest&pass=guest"/>
<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.8j"/>
<affects base="0.9.8" version="0.9.8k"/>
<affects base="0.9.8" version="0.9.8l"/>
- <fixed base="0.9.8" version="0.9.8m" date="20100120"/>
+ <fixed base="0.9.8" version="0.9.8m" date="20100120">
+ <git hash="561cbe567846a376153bea7f1f2d061e78029c2d"/>
+ </fixed>
<reported source="Daniel Mentz, Robin Seggelmann"/>
<description>
-Fix denial of service flaws in the DTLS implementation. A
-remote attacker could use these flaws to cause a DTLS server to use
-excessive amounts of memory, or crash.
+ Use-after-free vulnerability in the dtls1_retrieve_buffered_fragment
+ function could cause a client accessing a malicious DTLS server to
+ crash.
</description>
</issue>
<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"/>
- <fixed base="0.9.8" version="0.9.8m" date="20100120"/>
+ <fixed base="0.9.8" version="0.9.8m" date="20100120">
+ <git hash="1b31b5ad560b16e2fe1cad54a755e3e6b5e778a3"/>
+ </fixed>
<reported source="Michael K Johnson and Andy Grimm (rPath)"/>
<description>
A memory leak in the zlib_stateful_finish function in crypto/comp/c_zlib.c
<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"/>
- <fixed base="0.9.8" version="0.9.8m" date="20100120"/>
+ <fixed base="0.9.8" version="0.9.8m" date="20100120">
+ <git hash="7e4cae1d2f555cbe9226b377aff4b56c9f7ddd4d"/>
+ </fixed>
<reported source="Martin Olsson, Neel Mehta"/>
<description>
It was discovered that OpenSSL did not always check the return value of the
<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"/>
- <fixed base="0.9.8" version="0.9.8n" date="20100324"/>
+ <fixed base="0.9.8" version="0.9.8n" date="20100324">
+ <git hash="cca1cd9a3447dd067503e4a85ebd1679ee78a48e"/>
+ </fixed>
<reported source="Todd Rinaldo, Tomas Hoger (Red Hat)"/>
<description>
A missing return value check flaw was discovered in OpenSSL, that could
<affects base="0.9.8" version="0.9.8l"/>
<affects base="0.9.8" version="0.9.8m"/>
<fixed base="0.9.8" version="0.9.8n" date="20100324"/>
- <advisory url="http://www.openssl.org/news/secadv_20100324.txt"/>
+ <advisory url="/news/secadv/20100324.txt"/>
<reported source="Bodo Moeller and Adam Langley (Google)"/>
<description>
In TLS connections, certain incorrectly formatted records can cause an
<affects base="0.9.8" version="0.9.8n"/>
<fixed base="0.9.8" version="0.9.8o" date="20100601"/>
<fixed base="1.0.0" version="1.0.0a" date="20100601"/>
- <advisory url="http://www.openssl.org/news/secadv_20100601.txt"/>
+ <advisory url="/news/secadv/20100601.txt"/>
<reported source="Ronald Moesbergen"/>
<description>
A flaw in the handling of CMS structures containing OriginatorInfo was found which
<cve name="2010-1633"/>
<affects base="1.0.0" version="1.0.0"/>
<fixed base="1.0.0" version="1.0.0a" date="20100601"/>
- <advisory url="http://www.openssl.org/news/secadv_20100601.txt"/>
+ <advisory url="/news/secadv/20100601.txt"/>
<reported source="Peter-Michael Hager"/>
<description>
An invalid Return value check in pkey_rsa_verifyrecover was
<affects base="1.0.0" version="1.0.0a"/>
<fixed base="1.0.0" version="1.0.0b" date="20101116"/>
<fixed base="0.9.8" version="0.9.8p" date="20101116"/>
- <advisory url="http://www.openssl.org/news/secadv_20101116.txt"/>
+ <advisory url="/news/secadv/20101116.txt"/>
<reported source="Rob Hulswit"/>
<description>
<affects base="1.0.0" version="1.0.0a"/>
<affects base="1.0.0" version="1.0.0b"/>
<fixed base="1.0.0" version="1.0.0c" date="20101202"/>
- <advisory url="http://www.openssl.org/news/secadv_20101202.txt"/>
+ <advisory url="/news/secadv/20101202.txt"/>
<reported source="Sebastian Martini"/>
<description>
An error in OpenSSL's experimental J-PAKE implementation which could
<affects base="1.0.0" version="1.0.0b"/>
<fixed base="1.0.0" version="1.0.0c" date="20101202"/>
<fixed base="0.9.8" version="0.9.8q" date="20101202"/>
- <advisory url="http://www.openssl.org/news/secadv_20101202.txt"/>
+ <advisory url="/news/secadv/20101202.txt"/>
<reported source="Martin Rex"/>
<description>
A flaw in the OpenSSL SSL/TLS server code where an old bug workaround
<affects base="1.0.0" version="1.0.0c"/>
<affects base="1.0.0" version="1.0.0d"/>
<fixed base="1.0.0" version="1.0.0e" date="20110906"/>
- <advisory url="http://www.openssl.org/news/secadv_20110906.txt"/>
+ <advisory url="/news/secadv/20110906.txt"/>
<reported source="Kaspar Brand"/>
<description>
Under certain circumstances OpenSSL's internal certificate
<affects base="1.0.0" version="1.0.0c"/>
<affects base="1.0.0" version="1.0.0d"/>
<fixed base="1.0.0" version="1.0.0e" date="20110906"/>
- <advisory url="http://www.openssl.org/news/secadv_20110906.txt"/>
+ <advisory url="/news/secadv/20110906.txt"/>
<reported source="Adam Langley"/>
<description>
OpenSSL server code for ephemeral ECDH ciphersuites is not
<affects base="1.0.0" version="1.0.0e"/>
<fixed base="1.0.0" version="1.0.0f" date="20120104"/>
<fixed base="0.9.8" version="0.9.8s" date="20120104"/>
- <advisory url="http://www.openssl.org/news/secadv_20120104.txt"/>
+ <advisory url="/news/secadv/20120104.txt"/>
<reported source="Nadhem Alfardan and Kenny Paterson"/>
<description>
OpenSSL was susceptable an extension of the
<affects base="0.9.8" version="0.9.8q"/>
<affects base="0.9.8" version="0.9.8r"/>
<fixed base="0.9.8" version="0.9.8s" date="20120104"/>
- <advisory url="http://www.openssl.org/news/secadv_20120104.txt"/>
+ <advisory url="/news/secadv/20120104.txt"/>
<reported source="Ben Laurie"/>
<description>
If X509_V_FLAG_POLICY_CHECK is set in OpenSSL 0.9.8, then a policy
<affects base="1.0.0" version="1.0.0e"/>
<fixed base="1.0.0" version="1.0.0f" date="20120104"/>
<fixed base="0.9.8" version="0.9.8s" date="20120104"/>
- <advisory url="http://www.openssl.org/news/secadv_20120104.txt"/>
+ <advisory url="/news/secadv/20120104.txt"/>
<reported source="Adam Langley"/>
<description>
OpenSSL failed to clear the bytes used as
<affects base="1.0.0" version="1.0.0e"/>
<fixed base="1.0.0" version="1.0.0f" date="20120104"/>
<fixed base="0.9.8" version="0.9.8s" date="20120104"/>
- <advisory url="http://www.openssl.org/news/secadv_20120104.txt"/>
+ <advisory url="/news/secadv/20120104.txt"/>
<reported source="Andrew Chi"/>
<description>
RFC 3779 data can be included in certificates, and if it is malformed,
<affects base="1.0.0" version="1.0.0e"/>
<fixed base="1.0.0" version="1.0.0f" date="20120104"/>
<fixed base="0.9.8" version="0.9.8s" date="20120104"/>
- <advisory url="http://www.openssl.org/news/secadv_20120104.txt"/>
+ <advisory url="/news/secadv/20120104.txt"/>
<reported source="George Kadianakis"/>
<description>
Support for handshake restarts for server gated cryptograpy (SGC) can
<affects base="1.0.0" version="1.0.0d"/>
<affects base="1.0.0" version="1.0.0e"/>
<fixed base="1.0.0" version="1.0.0f" date="20120104"/>
- <advisory url="http://www.openssl.org/news/secadv_20120104.txt"/>
+ <advisory url="/news/secadv/20120104.txt"/>
<reported source="Andrey Kulikov"/>
<description>
A malicious TLS client can send an invalid set of GOST parameters
<affects base="1.0.0" version="1.0.0f"/>
<fixed base="1.0.0" version="1.0.0g" date="20120118"/>
<fixed base="0.9.8" version="0.9.8t" date="20120118"/>
- <advisory url="http://www.openssl.org/news/secadv_20120118.txt"/>
+ <advisory url="/news/secadv/20120118.txt"/>
<reported source="Antonio Martin"/>
<description>
A flaw in the fix to CVE-2011-4108 can be exploited in a denial of
<affects base="1.0.0" version="1.0.0g"/>
<fixed base="1.0.0" version="1.0.0h" date="20120312"/>
<fixed base="0.9.8" version="0.9.8u" date="20120312"/>
- <advisory url="http://www.openssl.org/news/secadv_20120312.txt"/>
+ <advisory url="/news/secadv/20120312.txt"/>
<reported source="Ivan Nestlerode"/>
<description>
A weakness in the OpenSSL CMS and PKCS #7 code can be exploited
<affects base="1.0.0" version="1.0.0c"/>
<fixed base="1.0.0" version="1.0.0d" date="20110208"/>
<fixed base="0.9.8" version="0.9.8r" date="20110208"/>
- <advisory url="http://www.openssl.org/news/secadv_20110208.txt"/>
+ <advisory url="/news/secadv/20110208.txt"/>
<reported source="Neel Mehta"/>
<description>
A buffer over-read flaw was discovered in the way OpenSSL parsed the
<cve name="2012-2131"/>
<affects base="0.9.8" version="0.9.8v"/>
<fixed base="0.9.8" version="0.9.8w" date="20120424"/>
- <advisory url="http://www.openssl.org/news/secadv_20120424.txt"/>
+ <advisory url="/news/secadv/20120424.txt"/>
<reported source="Red Hat"/>
<description>
It was discovered that the fix for CVE-2012-2110 released on 19 Apr
<fixed base="1.0.1" version="1.0.1a" date="20120419"/>
<fixed base="1.0.0" version="1.0.0i" date="20120419"/>
<fixed base="0.9.8" version="0.9.8v" date="20120419"/>
- <advisory url="http://www.openssl.org/news/secadv_20120419.txt"/>
+ <advisory url="/news/secadv/20120419.txt"/>
<reported source="Tavis Ormandy"/>
<description>
Multiple numeric conversion errors, leading to a buffer overflow, were
<fixed base="1.0.1" version="1.0.1c" date="20120510"/>
<fixed base="1.0.0" version="1.0.0j" date="20120510"/>
<fixed base="0.9.8" version="0.9.8x" date="20120510"/>
- <advisory url="http://www.openssl.org/news/secadv_20120510.txt"/>
+ <advisory url="/news/secadv/20120510.txt"/>
<reported source="Codenomicon"/>
<description>
An integer underflow flaw, leading to a buffer over-read, was found in
<fixed base="1.0.1" version="1.0.1d" date="20130205"/>
<fixed base="1.0.0" version="1.0.0k" date="20130205"/>
<fixed base="0.9.8" version="0.9.8y" date="20130205"/>
- <advisory url="http://www.openssl.org/news/secadv_20130205.txt"/>
+ <advisory url="/news/secadv/20130205.txt"/>
<reported source="Nadhem J. AlFardan and Kenneth G. Paterson of the Information Security Group Royal Holloway, University of London"/>
<description>
A weakness in the handling of CBC ciphersuites in SSL, TLS and DTLS which could
<affects base="1.0.1" version="1.0.1b"/>
<affects base="1.0.1" version="1.0.1c"/>
<fixed base="1.0.1" version="1.0.1d" date="20130205"/>
- <advisory url="http://www.openssl.org/news/secadv_20130205.txt"/>
+ <advisory url="/news/secadv/20130205.txt"/>
<reported source="Adam Langley and Wolfgang Ettlinger"/>
<description>
A flaw in the OpenSSL handling of CBC ciphersuites in TLS 1.1 and TLS 1.2 on
<fixed base="1.0.1" version="1.0.1d" date="20130205"/>
<fixed base="1.0.0" version="1.0.0k" date="20130205"/>
<fixed base="0.9.8" version="0.9.8y" date="20130205"/>
- <advisory url="http://www.openssl.org/news/secadv_20130205.txt"/>
+ <advisory url="/news/secadv/20130205.txt"/>
<reported source="Stephen Henson"/>
<description>
A flaw in the OpenSSL handling of OCSP response verification can be exploited in
</issue>
<issue public="20140106">
- <cve name="2013-4353"/>
+ <cve name="2013-4353"/>
<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"/>
<issue public="20140214">
<cve name="2014-0076"/>
+ <advisory url="/news/secadv/20140605.txt"/>
<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="1.0.1" version="1.0.1f"/>
<fixed base="1.0.1" version="1.0.1g" date="20140409">
</fixed>
- <advisory url="http://www.openssl.org/news/secadv_20140407.txt"/>
+ <advisory url="/news/secadv/20140407.txt"/>
<reported source="Neel Mehta"/>
<description>
A missing bounds check in the handling of the TLS heartbeat extension can be
by a Man-in-the-middle (MITM) attack where the attacker can decrypt and
modify traffic from the attacked client and server.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20140605.txt"/>
+ <advisory url="/news/secadv/20140605.txt"/>
<reported source="KIKUCHI Masashi (Lepidum Co. Ltd.)"/>
</issue>
<fixed base="0.9.8" version="0.9.8za" date="20140605">
</fixed>
<description>By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected.</description>
- <advisory url="http://www.openssl.org/news/secadv_20140605.txt"/>
+ <advisory url="/news/secadv/20140605.txt"/>
<reported source="Imre Rad (Search-Lab Ltd.)"/>
</issue>
to an OpenSSL DTLS client or server. This is potentially exploitable to
run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected.
</description>
- <advisory url="http://www.openssl.org/news/secadv_20140605.txt"/>
+ <advisory url="/news/secadv/20140605.txt"/>
<reported source="Jüri Aedla"/>
</issue>
cause a denial of service via a NULL pointer dereference. This flaw
only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is
enabled, which is not the default and not common.</description>
- <advisory url="http://www.openssl.org/news/secadv_20140605.txt"/>
+ <advisory url="/news/secadv/20140605.txt"/>
</issue>
<issue public="20140408">
This flaw only affects multithreaded applications using OpenSSL 1.0.0
and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the
default and not common.</description>
- <advisory url="http://www.openssl.org/news/secadv_20140605.txt"/>
+ <advisory url="/news/secadv/20140605.txt"/>
</issue>
<issue public="20140530">
<description>OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a
denial of service attack.</description>
<reported source="Felix Gröbert and Ivan Fratrić (Google)"/>
- <advisory url="http://www.openssl.org/news/secadv_20140605.txt"/>
+ <advisory url="/news/secadv/20140605.txt"/>
</issue>
</security>
projects / openssl-web.git / blobdiff