Vulnerabilities
If you think you have found a security bug in OpenSSL, please report it to us.
Show issues fixed only in OpenSSL 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 (OpenSSL advisory) [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. Reported by Bernd Edlinger.
- Fixed in OpenSSL 1.1.0l (git commit) (Affected 1.1.0-1.1.0k)
- This issue was also addressed in OpenSSL 1.1.1d, OpenSSL 1.0.2t
- CVE-2019-1547 (OpenSSL advisory) [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. Reported 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 1.1.0-1.1.0k)
- This issue was also addressed in OpenSSL 1.1.1d, OpenSSL 1.0.2t
- CVE-2019-1552 (OpenSSL advisory) [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. Reported by Rich Mirch.
- Fixed in OpenSSL 1.1.0l (git commit) (git commit) (Affected 1.1.0-1.1.0k)
- This issue was also addressed in OpenSSL 1.1.1d, OpenSSL 1.0.2t
- CVE-2019-1543 (OpenSSL advisory) [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. Reported by Joran Dirk Greef of Ronomon.
- Fixed in OpenSSL 1.1.0k (git commit) (Affected 1.1.0-1.1.0j)
- This issue was also addressed in OpenSSL 1.1.1c
2018
- CVE-2018-5407 (OpenSSL advisory) [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. Reported by Alejandro Cabrera Aldaya, Billy Brumley, Sohaib ul Hassan, Cesar Pereida Garcia and Nicola Tuveri.
- Fixed in OpenSSL 1.1.0i (git commit) (Affected 1.1.0-1.1.0h)
- This issue was also addressed in OpenSSL 1.0.2q
- CVE-2018-0734 (OpenSSL advisory) [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. Reported by Samuel Weiser.
- Fixed in OpenSSL 1.1.0j (git commit) (Affected 1.1.0-1.1.0i)
- This issue was also addressed in OpenSSL 1.1.1a, OpenSSL 1.0.2q
- CVE-2018-0735 (OpenSSL advisory) [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. Reported by Samuel Weiser.
- Fixed in OpenSSL 1.1.0j (git commit) (Affected 1.1.0-1.1.0i)
- This issue was also addressed in OpenSSL 1.1.1a
- CVE-2018-0732 (OpenSSL advisory) [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. Reported by Guido Vranken.
- Fixed in OpenSSL 1.1.0i (git commit) (Affected 1.1.0-1.1.0h)
- This issue was also addressed in OpenSSL 1.0.2p
- CVE-2018-0737 (OpenSSL advisory) [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. Reported by Alejandro Cabrera Aldaya, Billy Brumley, Cesar Pereida Garcia and Luis Manuel Alvarez Tapia.
- Fixed in OpenSSL 1.1.0i (git commit) (Affected 1.1.0-1.1.0h)
- This issue was also addressed in OpenSSL 1.0.2p
- CVE-2018-0739 (OpenSSL advisory) [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. Reported by OSS-fuzz.
- Fixed in OpenSSL 1.1.0h (git commit) (Affected 1.1.0-1.1.0g)
- This issue was also addressed in OpenSSL 1.0.2o
- CVE-2018-0733 (OpenSSL advisory) [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. Reported by Peter Waltenberg (IBM).
- Fixed in OpenSSL 1.1.0h (git commit) (Affected 1.1.0-1.1.0g)
2017
- CVE-2017-3738 (OpenSSL advisory) [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. Reported by David Benjamin (Google)/Google OSS-Fuzz.
- Fixed in OpenSSL 1.1.0h (git commit) (Affected 1.1.0-1.1.0g)
- This issue was also addressed in OpenSSL 1.0.2n
- CVE-2017-3736 (OpenSSL advisory) [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. Reported by Google OSS-Fuzz.
- Fixed in OpenSSL 1.1.0g (git commit) (Affected 1.1.0-1.1.0f)
- This issue was also addressed in OpenSSL 1.0.2m
- CVE-2017-3735 (OpenSSL advisory) [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. Reported by Google OSS-Fuzz.
- Fixed in OpenSSL 1.1.0g (git commit) (Affected 1.1.0-1.1.0f)
- This issue was also addressed in OpenSSL 1.0.2m
- CVE-2017-3733 (OpenSSL advisory) [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. Reported by Joe Orton (Red Hat).
- Fixed in OpenSSL 1.1.0e (git commit) (Affected 1.1.0-1.1.0d)
- CVE-2017-3732 (OpenSSL advisory) [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. Reported by OSS-Fuzz project.
- Fixed in OpenSSL 1.1.0d (git commit) (Affected 1.1.0-1.1.0c)
- This issue was also addressed in OpenSSL 1.0.2k
- CVE-2017-3731 (OpenSSL advisory) [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 Reported by Robert Święcki of Google.
- Fixed in OpenSSL 1.1.0d (git commit) (Affected 1.1.0-1.1.0c)
- This issue was also addressed in OpenSSL 1.0.2k
- CVE-2017-3730 (OpenSSL advisory) [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. Reported by Guido Vranken.
- Fixed in OpenSSL 1.1.0d (git commit) (Affected 1.1.0-1.1.0c)
2016
- CVE-2016-7055 (OpenSSL advisory) [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. Reported by Publicly reported.
- Fixed in OpenSSL 1.1.0c (git commit) (Affected 1.1.0-1.1.0b)
- This issue was also addressed in OpenSSL 1.0.2k
- CVE-2016-7054 (OpenSSL advisory) [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. Reported by Robert Święcki (Google Security Team).
- Fixed in OpenSSL 1.1.0c (git commit) (Affected 1.1.0-1.1.0b)
- CVE-2016-7053 (OpenSSL advisory) [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. Reported by Tyler Nighswander (ForAllSecure).
- Fixed in OpenSSL 1.1.0c (git commit) (Affected 1.1.0-1.1.0b)
- 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. Reported by Robert Święcki (Google Security Team).
- Fixed in OpenSSL 1.1.0b (git commit) (Affected 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. Reported by Alex Gaynor.
- Fixed in OpenSSL 1.1.0a (git commit) (Affected 1.1.0)
- 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. Reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
- Fixed in OpenSSL 1.1.0a (git commit) (Affected 1.1.0)
- This issue was also addressed in OpenSSL 1.0.2i, OpenSSL 1.0.1u
- 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. Reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
- Fixed in OpenSSL 1.1.0a (git commit) (Affected 1.1.0)
- 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. Reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
- Fixed in OpenSSL 1.1.0a (git commit) (Affected 1.1.0)
- CVE-2016-2183 (OpenSSL advisory) [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. Reported by Karthik Bhargavan and Gaetan Leurent from Inria.
- Fixed in OpenSSL 1.1.0 (Affected )
- This issue was also addressed in OpenSSL 1.0.2i