OpenSSL

Cryptography and SSL/TLS Toolkit

Vulnerabilities

If you think you have found a security bug in OpenSSL, please report it to us.

Show issues fixed only in OpenSSL 3.1, 3.0, 1.1.1, 1.1.0, 1.0.2, 1.0.1, 1.0.0, 0.9.8, 0.9.7, 0.9.6, or all versions

Fixed in OpenSSL 1.1.0

OpenSSL 1.1.0 is out of support since 12th September 2019 and no longer receiving updates.

Jump to year: 2019, 2018, 2017, 2016

2019

CVE-2019-1563 Padding Oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey [Low severity] 10 September 2019:
In situations where an attacker receives automated notification of the success or failure of a decryption attempt an attacker, after sending a very large number of messages to be decrypted, can recover a CMS/PKCS7 transported encryption key or decrypt any RSA encrypted message that was encrypted with the public RSA key, using a Bleichenbacher padding oracle attack. Applications are not affected if they use a certificate together with the private RSA key to the CMS_decrypt or PKCS7_decrypt functions to select the correct recipient info to decrypt.
Found by Bernd Edlinger.
  • Fixed in OpenSSL 1.1.0l (git commit) (Affected since 1.1.0)
  • This issue was also addressed in OpenSSL 1.1.1d, OpenSSL 1.0.2t
CVE-2019-1547 ECDSA remote timing attack [Low severity] 10 September 2019:
Normally in OpenSSL EC groups always have a co-factor present and this is used in side channel resistant code paths. However, in some cases, it is possible to construct a group using explicit parameters (instead of using a named curve). In those cases it is possible that such a group does not have the cofactor present. This can occur even where all the parameters match a known named curve. If such a curve is used then OpenSSL falls back to non-side channel resistant code paths which may result in full key recovery during an ECDSA signature operation. In order to be vulnerable an attacker would have to have the ability to time the creation of a large number of signatures where explicit parameters with no co-factor present are in use by an application using libcrypto. For the avoidance of doubt libssl is not vulnerable because explicit parameters are never used.
Found by Cesar Pereida García, Sohaib ul Hassan, Nicola Tuveri, Iaroslav Gridin, Alejandro Cabrera Aldaya, and Billy Brumley.
  • Fixed in OpenSSL 1.1.0l (git commit) (Affected since 1.1.0)
  • This issue was also addressed in OpenSSL 1.1.1d, OpenSSL 1.0.2t
CVE-2019-1552 Windows builds with insecure path defaults [Low severity] 30 July 2019:
OpenSSL has internal defaults for a directory tree where it can find a configuration file as well as certificates used for verification in TLS. This directory is most commonly referred to as OPENSSLDIR, and is configurable with the --prefix / --openssldir configuration options. For OpenSSL versions 1.1.0 and 1.1.1, the mingw configuration targets assume that resulting programs and libraries are installed in a Unix-like environment and the default prefix for program installation as well as for OPENSSLDIR should be '/usr/local'. However, mingw programs are Windows programs, and as such, find themselves looking at sub-directories of 'C:/usr/local', which may be world writable, which enables untrusted users to modify OpenSSL's default configuration, insert CA certificates, modify (or even replace) existing engine modules, etc. For OpenSSL 1.0.2, '/usr/local/ssl' is used as default for OPENSSLDIR on all Unix and Windows targets, including Visual C builds. However, some build instructions for the diverse Windows targets on 1.0.2 encourage you to specify your own --prefix. OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue. Due to the limited scope of affected deployments this has been assessed as low severity and therefore we are not creating new releases at this time.
Found by Rich Mirch.
  • Fixed in OpenSSL 1.1.0l (git commit) (Affected since 1.1.0)
  • This issue was also addressed in OpenSSL 1.1.1d, OpenSSL 1.0.2t
CVE-2019-1543 ChaCha20-Poly1305 with long nonces [Low severity] 06 March 2019:
ChaCha20-Poly1305 is an AEAD cipher, and requires a unique nonce input for every encryption operation. RFC 7539 specifies that the nonce value (IV) should be 96 bits (12 bytes). OpenSSL allows a variable nonce length and front pads the nonce with 0 bytes if it is less than 12 bytes. However it also incorrectly allows a nonce to be set of up to 16 bytes. In this case only the last 12 bytes are significant and any additional leading bytes are ignored. It is a requirement of using this cipher that nonce values are unique. Messages encrypted using a reused nonce value are susceptible to serious confidentiality and integrity attacks. If an application changes the default nonce length to be longer than 12 bytes and then makes a change to the leading bytes of the nonce expecting the new value to be a new unique nonce then such an application could inadvertently encrypt messages with a reused nonce. Additionally the ignored bytes in a long nonce are not covered by the integrity guarantee of this cipher. Any application that relies on the integrity of these ignored leading bytes of a long nonce may be further affected. Any OpenSSL internal use of this cipher, including in SSL/TLS, is safe because no such use sets such a long nonce value. However user applications that use this cipher directly and set a non-default nonce length to be longer than 12 bytes may be vulnerable. OpenSSL versions 1.1.1 and 1.1.0 are affected by this issue. Due to the limited scope of affected deployments this has been assessed as low severity and therefore we are not creating new releases at this time.
Found by Joran Dirk Greef of Ronomon.
  • Fixed in OpenSSL 1.1.0k (git commit) (Affected since 1.1.0)
  • This issue was also addressed in OpenSSL 1.1.1c

2018

CVE-2018-5407 Microarchitecture timing vulnerability in ECC scalar multiplication [Low severity] 02 November 2018:
OpenSSL ECC scalar multiplication, used in e.g. ECDSA and ECDH, has been shown to be vulnerable to a microarchitecture timing side channel attack. An attacker with sufficient access to mount local timing attacks during ECDSA signature generation could recover the private key.
Found by Alejandro Cabrera Aldaya, Billy Brumley, Sohaib ul Hassan, Cesar Pereida Garcia and Nicola Tuveri.
  • Fixed in OpenSSL 1.1.0i (git commit) (Affected since 1.1.0)
  • This issue was also addressed in OpenSSL 1.0.2q
CVE-2018-0734 Timing attack against DSA [Low severity] 30 October 2018:
The OpenSSL DSA signature algorithm has been shown to be vulnerable to a timing side channel attack. An attacker could use variations in the signing algorithm to recover the private key.
Found by Samuel Weiser.
  • Fixed in OpenSSL 1.1.0j (git commit) (Affected since 1.1.0)
  • This issue was also addressed in OpenSSL 1.1.1a, OpenSSL 1.0.2q
CVE-2018-0735 Timing attack against ECDSA signature generation [Low severity] 29 October 2018:
The OpenSSL ECDSA signature algorithm has been shown to be vulnerable to a timing side channel attack. An attacker could use variations in the signing algorithm to recover the private key.
Found by Samuel Weiser.
  • Fixed in OpenSSL 1.1.0j (git commit) (Affected since 1.1.0)
  • This issue was also addressed in OpenSSL 1.1.1a
CVE-2018-0732 Client DoS due to large DH parameter [Low severity] 12 June 2018:
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.
Found by Guido Vranken.
  • Fixed in OpenSSL 1.1.0i (git commit) (Affected since 1.1.0)
  • This issue was also addressed in OpenSSL 1.0.2p
CVE-2018-0737 Cache timing vulnerability in RSA Key Generation [Low severity] 16 April 2018:
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.
Found by Alejandro Cabrera Aldaya, Billy Brumley, Cesar Pereida Garcia and Luis Manuel Alvarez Tapia.
  • Fixed in OpenSSL 1.1.0i (git commit) (Affected since 1.1.0)
  • This issue was also addressed in OpenSSL 1.0.2p
CVE-2018-0739 Constructed ASN.1 types with a recursive definition could exceed the stack [Moderate severity] 27 March 2018:
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.
Found by OSS-fuzz.
  • Fixed in OpenSSL 1.1.0h (git commit) (Affected since 1.1.0)
  • This issue was also addressed in OpenSSL 1.0.2o
CVE-2018-0733 Incorrect CRYPTO_memcmp on HP-UX PA-RISC [Moderate severity] 27 March 2018:
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.
Found by Peter Waltenberg (IBM).

2017

CVE-2017-3738 bn_sqrx8x_internal carry bug on x86_64 [Low severity] 07 December 2017:
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.
Found by David Benjamin (Google)/Google OSS-Fuzz.
  • Fixed in OpenSSL 1.1.0h (git commit) (Affected since 1.1.0)
  • This issue was also addressed in OpenSSL 1.0.2n
CVE-2017-3736 bn_sqrx8x_internal carry bug on x86_64 [Moderate severity] 02 November 2017:
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.
Found by Google OSS-Fuzz.
  • Fixed in OpenSSL 1.1.0g (git commit) (Affected since 1.1.0)
  • This issue was also addressed in OpenSSL 1.0.2m
CVE-2017-3735 Possible Overread in parsing X.509 IPAdressFamily [Low severity] 28 August 2017:
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.
Found by Google OSS-Fuzz.
  • Fixed in OpenSSL 1.1.0g (git commit) (Affected since 1.1.0)
  • This issue was also addressed in OpenSSL 1.0.2m
CVE-2017-3733 Encrypt-Then-Mac renegotiation crash [High severity] 16 February 2017:
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.
Found by Joe Orton (Red Hat).
CVE-2017-3732 BN_mod_exp may produce incorrect results on x86_64 [Moderate severity] 26 January 2017:
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.
Found by OSS-Fuzz project.
  • Fixed in OpenSSL 1.1.0d (git commit) (Affected since 1.1.0)
  • This issue was also addressed in OpenSSL 1.0.2k
CVE-2017-3731 Truncated packet could crash via OOB read [Moderate severity] 26 January 2017:
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.
Found by Robert Święcki of Google.
  • Fixed in OpenSSL 1.1.0d (git commit) (Affected since 1.1.0)
  • This issue was also addressed in OpenSSL 1.0.2k
CVE-2017-3730 Bad (EC)DHE parameters cause a client crash [Moderate severity] 26 January 2017:
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.
Found by Guido Vranken.

2016

CVE-2016-7055 Montgomery multiplication may produce incorrect results [Low severity] 10 November 2016:
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.
Found by Publicly reported.
  • Fixed in OpenSSL 1.1.0c (git commit) (Affected since 1.1.0)
  • This issue was also addressed in OpenSSL 1.0.2k
CVE-2016-7054 ChaCha20/Poly1305 heap-buffer-overflow [High severity] 10 November 2016:
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.
Found by Robert Święcki (Google Security Team).
CVE-2016-7053 CMS Null dereference [Moderate severity] 10 November 2016:
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.
Found by Tyler Nighswander (ForAllSecure).
CVE-2016-6309 (OpenSSL Advisory) [Critical severity] 26 September 2016:
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.
Found by Robert Święcki (Google Security Team).
  • Fixed in OpenSSL 1.1.0b (git commit) (Affected since 1.1.0a)
CVE-2016-6305 (OpenSSL Advisory) [Moderate severity] 22 September 2016:
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.
Found by Alex Gaynor.
CVE-2016-6304 (OpenSSL Advisory) [High severity] 22 September 2016:
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.
Found by Shi Lei (Gear Team, Qihoo 360 Inc.).
  • Fixed in OpenSSL 1.1.0a (git commit) (Affected since 1.1.0)
  • This issue was also addressed in OpenSSL 1.0.1u, OpenSSL 1.0.2i
CVE-2016-6308 (OpenSSL Advisory) [Low severity] 21 September 2016:
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.
Found by Shi Lei (Gear Team, Qihoo 360 Inc.).
CVE-2016-6307 (OpenSSL Advisory) [Low severity] 21 September 2016:
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.
Found by Shi Lei (Gear Team, Qihoo 360 Inc.).
CVE-2016-2183 SWEET32 attack on Triple-DES [Low severity] 24 August 2016:
Because DES (and triple-DES) has only a 64-bit block size, birthday attacks are a real concern. For example, with the ability to run Javascript in a browser, it is possible to send enough traffic to cause a collision, and then use that information to recover something like a session Cookie. Triple-DES, which shows up as “DES-CBC3” in an OpenSSL cipher string, is still used on the Web, and major browsers are not yet willing to completely disable it. If you run a server, you should disable triple-DES. This is generally a configuration issue. If you run an old server that doesn’t support any better ciphers than DES or RC4, you should upgrade. For 1.0.2 and 1.0.1, we removed the triple-DES ciphers from the “HIGH” keyword and put them into “MEDIUM.” Note that we did not remove them from the “DEFAULT” keyword. For the 1.1.0 release, we treat triple-DES just like we are treating RC4. It is not compiled by default; you have to use “enable-weak-ssl-ciphers” as a config option. Even when those ciphers are compiled, triple-DES is only in the “MEDIUM” keyword. In addition we also removed it from the “DEFAULT” keyword.
Found by Karthik Bhargavan and Gaetan Leurent from Inria.
  • This issue was also addressed in OpenSSL 1.0.2i