Vulnerabilities 1.1.0

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

Show issues fixed only in OpenSSL 3.3, 3.2, 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.

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

CVE-2019-1563

Severity
Low
Published at
10 September 2019
Title
Padding Oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey
Found by
Bernd Edlinger
Affected
  • from 1.1.1 before 1.1.1d
  • from 1.1.0 before 1.1.0l
  • from 1.0.2 before 1.0.2t
References

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.

CVE-2019-1552

Severity
Low
Published at
30 July 2019
Title
Windows builds with insecure path defaults
Found by
Rich Mirch
Affected
  • from 1.1.1 before 1.1.1d
  • from 1.1.0 before 1.1.0l
  • from 1.0.2 before 1.0.2t
References

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.

CVE-2019-1547

Severity
Low
Published at
10 September 2019
Title
ECDSA remote timing attack
Found by
Cesar Pereida García, Sohaib ul Hassan, Nicola Tuveri, Iaroslav Gridin, Alejandro Cabrera Aldaya, and Billy Brumley
Affected
  • from 1.1.1 before 1.1.1d
  • from 1.1.0 before 1.1.0l
  • from 1.0.2 before 1.0.2t
References

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.

CVE-2019-1543

Severity
Low
Published at
6 March 2019
Title
ChaCha20-Poly1305 with long nonces
Found by
Joran Dirk Greef of Ronomon
Affected
  • from 1.1.1 before 1.1.1c
  • from 1.1.0 before 1.1.0k
References

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.

CVE-2018-5407

Severity
Low
Published at
2 November 2018
Title
Microarchitecture timing vulnerability in ECC scalar multiplication
Found by
Alejandro Cabrera Aldaya, Billy Brumley, Sohaib ul Hassan, Cesar Pereida Garcia and Nicola Tuveri
Affected
  • from 1.1.0 before 1.1.0i
  • from 1.0.2 before 1.0.2q
References

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.

CVE-2018-0739

Severity
Moderate
Published at
27 March 2018
Title
Constructed ASN.1 types with a recursive definition could exceed the stack
Found by
OSS-fuzz
Affected
  • from 1.1.0 before 1.1.0h
  • from 1.0.2b before 1.0.2o
References

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.

CVE-2018-0737

Severity
Low
Published at
16 April 2018
Title
Cache timing vulnerability in RSA Key Generation
Found by
Alejandro Cabrera Aldaya, Billy Brumley, Cesar Pereida Garcia and Luis Manuel Alvarez Tapia
Affected
  • from 1.1.0 before 1.1.0i
  • from 1.0.2 before 1.0.2p
References

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.

CVE-2018-0735

Severity
Low
Published at
29 October 2018
Title
Timing attack against ECDSA signature generation
Found by
Samuel Weiser
Affected
  • from 1.1.0 before 1.1.0j
  • from 1.1.1 before 1.1.1a
References

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.

CVE-2018-0734

Severity
Low
Published at
30 October 2018
Title
Timing attack against DSA
Found by
Samuel Weiser
Affected
  • from 1.1.1 before 1.1.1a
  • from 1.1.0 before 1.1.0j
  • from 1.0.2 before 1.0.2q
References

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.

CVE-2018-0733

Severity
Moderate
Published at
27 March 2018
Title
Incorrect CRYPTO_memcmp on HP-UX PA-RISC
Found by
Peter Waltenberg (IBM)
Affected
  • from 1.1.0 before 1.1.0h
References

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.

CVE-2018-0732

Severity
Low
Published at
12 June 2018
Title
Client DoS due to large DH parameter
Found by
Guido Vranken
Affected
  • from 1.1.0 before 1.1.0i
  • from 1.0.2 before 1.0.2p
References

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.

CVE-2017-3738

Severity
Low
Published at
7 December 2017
Title
bn_sqrx8x_internal carry bug on x86_64
Found by
David Benjamin (Google)/Google OSS-Fuzz
Affected
  • from 1.0.2 before 1.0.2n
  • from 1.1.0 before 1.1.0h
References

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.

CVE-2017-3736

Severity
Moderate
Published at
2 November 2017
Title
bn_sqrx8x_internal carry bug on x86_64
Found by
Google OSS-Fuzz
Affected
  • from 1.0.2 before 1.0.2m
  • from 1.1.0 before 1.1.0g
References

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.

CVE-2017-3735

Severity
Low
Published at
28 August 2017
Title
Possible Overread in parsing X.509 IPAdressFamily
Found by
Google OSS-Fuzz
Affected
  • from 1.0.2 before 1.0.2m
  • from 1.1.0 before 1.1.0g
References

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.

CVE-2017-3733

Severity
High
Published at
16 February 2017
Title
Encrypt-Then-Mac renegotiation crash
Found by
Joe Orton (Red Hat)
Affected
  • from 1.1.0 before 1.1.0e
References

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.

CVE-2017-3732

Severity
Moderate
Published at
26 January 2017
Title
BN_mod_exp may produce incorrect results on x86_64
Found by
OSS-Fuzz project
Affected
  • from 1.1.0 before 1.1.0d
  • from 1.0.2 before 1.0.2k
References

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.

CVE-2017-3731

Severity
Moderate
Published at
26 January 2017
Title
Truncated packet could crash via OOB read
Found by
Robert Święcki of Google
Affected
  • from 1.1.0 before 1.1.0d
  • from 1.0.2 before 1.0.2k
References

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.

CVE-2017-3730

Severity
Moderate
Published at
26 January 2017
Title
Bad (EC)DHE parameters cause a client crash
Found by
Guido Vranken
Affected
  • from 1.1.0 before 1.1.0d
References

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.

CVE-2016-7055

Severity
Low
Published at
10 November 2016
Title
Montgomery multiplication may produce incorrect results
Found by
Publicly reported
Affected
  • from 1.1.0 before 1.1.0c
  • from 1.0.2 before 1.0.2k
References

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.

CVE-2016-7054

Severity
High
Published at
10 November 2016
Title
ChaCha20/Poly1305 heap-buffer-overflow
Found by
Robert Święcki (Google Security Team)
Affected
  • from 1.1.0 before 1.1.0c
References

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.

CVE-2016-7053

Severity
Moderate
Published at
10 November 2016
Title
CMS Null dereference
Found by
Tyler Nighswander (ForAllSecure)
Affected
  • from 1.1.0 before 1.1.0c
References

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.

CVE-2016-6309

Severity
Critical
Published at
26 September 2016
Found by
Robert Święcki (Google Security Team)
Affected
  • from 1.1.0a before 1.1.0b
References

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.

CVE-2016-6308

Severity
Low
Published at
21 September 2016
Found by
Shi Lei (Gear Team, Qihoo 360 Inc.)
Affected
  • from 1.1.0 before 1.1.0a
References

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.

CVE-2016-6307

Severity
Low
Published at
21 September 2016
Found by
Shi Lei (Gear Team, Qihoo 360 Inc.)
Affected
  • from 1.1.0 before 1.1.0a
References

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.

CVE-2016-6305

Severity
Moderate
Published at
22 September 2016
Found by
Alex Gaynor
Affected
  • from 1.1.0 before 1.1.0a
References

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.

CVE-2016-6304

Severity
High
Published at
22 September 2016
Found by
Shi Lei (Gear Team, Qihoo 360 Inc.)
Affected
  • from 1.0.1 before 1.0.1u
  • from 1.0.2 before 1.0.2i
  • from 1.1.0 before 1.1.0a
References

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.