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.0.2
OpenSSL 1.0.2 is out of support since 1st January 2020 and is no longer receiving updates. Extended support is available from OpenSSL Software Services for premium support customers
Jump to year: 2022, 2021, 2020, 2019, 2018, 2017, 2016, 2015
2022
- CVE-2022-2068 (OpenSSL advisory) [Moderate severity] 21 June 2022:
- In addition to the c_rehash shell command injection identified in
CVE-2022-1292, further circumstances where the c_rehash script does not
properly sanitise shell metacharacters to prevent command injection were
found by code review.
When the CVE-2022-1292 was fixed it was not discovered that there
are other places in the script where the file names of certificates
being hashed were possibly passed to a command executed through the shell.
This script is distributed by some operating systems in a manner where
it is automatically executed. On such operating systems, an attacker
could execute arbitrary commands with the privileges of the script.
Use of the c_rehash script is considered obsolete and should be replaced
by the OpenSSL rehash command line tool. Reported by Chancen (Qingteng 73lab).
- Fixed in OpenSSL 1.0.2zf (git commit) (Affected 1.0.2-1.0.2ze)
- This issue was also addressed in OpenSSL 3.0.4, OpenSSL 1.1.1p
- CVE-2022-1292 (OpenSSL advisory) [Moderate severity] 03 May 2022:
- The c_rehash script does not properly sanitise shell metacharacters to
prevent command injection. This script is distributed by some operating
systems in a manner where it is automatically executed. On such operating
systems, an attacker could execute arbitrary commands with the privileges
of the script.
Use of the c_rehash script is considered obsolete and should be replaced
by the OpenSSL rehash command line tool. Reported by Elison Niven (Sophos).
- Fixed in OpenSSL 1.0.2ze (git commit) (Affected 1.0.2-1.0.2zd)
- This issue was also addressed in OpenSSL 3.0.3, OpenSSL 1.1.1o
- CVE-2022-0778 (OpenSSL advisory) [High severity] 15 March 2022:
- The BN_mod_sqrt() function, which computes a modular square root, contains
a bug that can cause it to loop forever for non-prime moduli.
Internally this function is used when parsing certificates that contain
elliptic curve public keys in compressed form or explicit elliptic curve
parameters with a base point encoded in compressed form.
It is possible to trigger the infinite loop by crafting a certificate that
has invalid explicit curve parameters.
Since certificate parsing happens prior to verification of the certificate
signature, any process that parses an externally supplied certificate may thus
be subject to a denial of service attack. The infinite loop can also be
reached when parsing crafted private keys as they can contain explicit
elliptic curve parameters.
Thus vulnerable situations include:
- TLS clients consuming server certificates
- TLS servers consuming client certificates
- Hosting providers taking certificates or private keys from customers
- Certificate authorities parsing certification requests from subscribers
- Anything else which parses ASN.1 elliptic curve parameters
Also any other applications that use the BN_mod_sqrt() where the attacker
can control the parameter values are vulnerable to this DoS issue.
In the OpenSSL 1.0.2 version the public key is not parsed during initial
parsing of the certificate which makes it slightly harder to trigger
the infinite loop. However any operation which requires the public key
from the certificate will trigger the infinite loop. In particular the
attacker can use a self-signed certificate to trigger the loop during
verification of the certificate signature.
This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was
addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. Reported by Tavis Ormandy (Google).
- Fixed in OpenSSL 1.0.2zd (git commit) (Affected 1.0.2-1.0.2zc)
- This issue was also addressed in OpenSSL 3.0.2, OpenSSL 1.1.1n
- CVE-2021-4160 (OpenSSL advisory) [Moderate severity] 28 January 2022:
- There is a carry propagation bug in the MIPS32 and MIPS64 squaring
procedure. Many EC algorithms are affected, including some of the
TLS 1.3 default curves. Impact was not analyzed in detail, because the
pre-requisites for attack are considered unlikely and include reusing
private keys. 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 significant. However,
for an attack on TLS to be meaningful, the server would have to share
the DH private key among multiple clients, which is no longer an option
since CVE-2016-0701.
This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0.0. It was
addressed in the releases of 1.1.1m and 3.0.1 on the 15th of December 2021. For
the 1.0.2 release it is addressed in git commit 6fc1aaaf3 that is available to
premium support customers only. It will be made available in 1.0.2zc when it is
released.
The issue only affects OpenSSL on MIPS platforms. Reported by Bernd Edlinger.
- Fixed in OpenSSL 1.0.2zc-dev (git commit) (Affected 1.0.2-1.0.2zb)
- This issue was also addressed in OpenSSL 3.0.1, OpenSSL 1.1.1m
2021
- CVE-2021-3712 (OpenSSL advisory) [Moderate severity] 24 August 2021:
- ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING
structure which contains a buffer holding the string data and a field holding
the buffer length. This contrasts with normal C strings which are repesented as
a buffer for the string data which is terminated with a NUL (0) byte.
Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's
own "d2i" functions (and other similar parsing functions) as well as any string
whose value has been set with the ASN1_STRING_set() function will additionally
NUL terminate the byte array in the ASN1_STRING structure.
However, it is possible for applications to directly construct valid ASN1_STRING
structures which do not NUL terminate the byte array by directly setting the
"data" and "length" fields in the ASN1_STRING array. This can also happen by
using the ASN1_STRING_set0() function.
Numerous OpenSSL functions that print ASN.1 data have been found to assume that
the ASN1_STRING byte array will be NUL terminated, even though this is not
guaranteed for strings that have been directly constructed. Where an application
requests an ASN.1 structure to be printed, and where that ASN.1 structure
contains ASN1_STRINGs that have been directly constructed by the application
without NUL terminating the "data" field, then a read buffer overrun can occur.
The same thing can also occur during name constraints processing of certificates
(for example if a certificate has been directly constructed by the application
instead of loading it via the OpenSSL parsing functions, and the certificate
contains non NUL terminated ASN1_STRING structures). It can also occur in the
X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions.
If a malicious actor can cause an application to directly construct an
ASN1_STRING and then process it through one of the affected OpenSSL functions
then this issue could be hit. This might result in a crash (causing a Denial of
Service attack). It could also result in the disclosure of private memory
contents (such as private keys, or sensitive plaintext). Reported by Ingo Schwarze.
- Fixed in OpenSSL 1.0.2za (git commit) (Affected 1.0.2-1.0.2y)
- This issue was also addressed in OpenSSL 1.1.1l
- CVE-2021-23841 (OpenSSL advisory) [Moderate severity] 16 February 2021:
- The OpenSSL public API function X509_issuer_and_serial_hash() attempts to
create a unique hash value based on the issuer and serial number data contained
within an X509 certificate. However it fails to correctly handle any errors
that may occur while parsing the issuer field (which might occur if the issuer
field is maliciously constructed). This may subsequently result in a NULL
pointer deref and a crash leading to a potential denial of service attack.
The function X509_issuer_and_serial_hash() is never directly called by OpenSSL
itself so applications are only vulnerable if they use this function directly
and they use it on certificates that may have been obtained from untrusted
sources.
OpenSSL versions 1.1.1i and below are affected by this issue. Users of these
versions should upgrade to OpenSSL 1.1.1j.
OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL
1.0.2 is out of support and no longer receiving public updates. Premium support
customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade
to 1.1.1j. Reported by Tavis Ormandy (Google).
- Fixed in OpenSSL 1.0.2y (git commit) (Affected 1.0.2-1.0.2x)
- This issue was also addressed in OpenSSL 1.1.1j
- CVE-2021-23840 (OpenSSL advisory) [Low severity] 16 February 2021:
- Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow
the output length argument in some cases where the input length is close to the
maximum permissable length for an integer on the platform. In such cases the
return value from the function call will be 1 (indicating success), but the
output length value will be negative. This could cause applications to behave
incorrectly or crash.
OpenSSL versions 1.1.1i and below are affected by this issue. Users of these
versions should upgrade to OpenSSL 1.1.1j.
OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL
1.0.2 is out of support and no longer receiving public updates. Premium support
customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade
to 1.1.1j. Reported by Paul Kehrer.
- Fixed in OpenSSL 1.0.2y (git commit) (Affected 1.0.2-1.0.2x)
- This issue was also addressed in OpenSSL 1.1.1j
- CVE-2021-23839 (OpenSSL advisory) [Low severity] 16 February 2021:
- OpenSSL 1.0.2 supports SSLv2. If a client attempts to negotiate SSLv2 with a
server that is configured to support both SSLv2 and more recent SSL and TLS
versions then a check is made for a version rollback attack when unpadding an
RSA signature. Clients that support SSL or TLS versions greater than SSLv2 are
supposed to use a special form of padding. A server that supports greater than
SSLv2 is supposed to reject connection attempts from a client where this special
form of padding is present, because this indicates that a version rollback has
occurred (i.e. both client and server support greater than SSLv2, and yet this
is the version that is being requested).
The implementation of this padding check inverted the logic so that the
connection attempt is accepted if the padding is present, and rejected if it
is absent. This means that such as server will accept a connection if a version
rollback attack has occurred. Further the server will erroneously reject a
connection if a normal SSLv2 connection attempt is made.
Only OpenSSL 1.0.2 servers from version 1.0.2s to 1.0.2x are affected by this
issue. In order to be vulnerable a 1.0.2 server must:
1) have configured SSLv2 support at compile time (this is off by default),
2) have configured SSLv2 support at runtime (this is off by default),
3) have configured SSLv2 ciphersuites (these are not in the default ciphersuite
list)
OpenSSL 1.1.1 does not have SSLv2 support and therefore is not vulnerable to
this issue. The underlying error is in the implementation of the
RSA_padding_check_SSLv23() function. This also affects the RSA_SSLV23_PADDING
padding mode used by various other functions. Although 1.1.1 does not support
SSLv2 the RSA_padding_check_SSLv23() function still exists, as does the
RSA_SSLV23_PADDING padding mode. Applications that directly call that function
or use that padding mode will encounter this issue. However since there is no
support for the SSLv2 protocol in 1.1.1 this is considered a bug and not a
security issue in that version.
OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium
support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should
upgrade to 1.1.1j. Reported by D. Katz and Joel Luellwitz (Trustwave).
- Fixed in OpenSSL 1.0.2y (git commit) (Affected 1.0.2s-1.0.2x)
2020
- CVE-2020-1971 (OpenSSL advisory) [High severity] 08 December 2020:
- The X.509 GeneralName type is a generic type for representing different types
of names. One of those name types is known as EDIPartyName. OpenSSL provides a
function GENERAL_NAME_cmp which compares different instances of a GENERAL_NAME
to see if they are equal or not. This function behaves incorrectly when both
GENERAL_NAMEs contain an EDIPARTYNAME. A NULL pointer dereference and a crash
may occur leading to a possible denial of service attack.
OpenSSL itself uses the GENERAL_NAME_cmp function for two purposes:
1) Comparing CRL distribution point names between an available CRL and a CRL
distribution point embedded in an X509 certificate
2) When verifying that a timestamp response token signer matches the timestamp
authority name (exposed via the API functions TS_RESP_verify_response and
TS_RESP_verify_token)
If an attacker can control both items being compared then that attacker could
trigger a crash. For example if the attacker can trick a client or server into
checking a malicious certificate against a malicious CRL then this may occur.
Note that some applications automatically download CRLs based on a URL embedded
in a certificate. This checking happens prior to the signatures on the
certificate and CRL being verified. OpenSSL's s_server, s_client and verify
tools have support for the "-crl_download" option which implements automatic
CRL downloading and this attack has been demonstrated to work against those
tools.
Note that an unrelated bug means that affected versions of OpenSSL cannot parse
or construct correct encodings of EDIPARTYNAME. However it is possible to
construct a malformed EDIPARTYNAME that OpenSSL's parser will accept and hence
trigger this attack.
All OpenSSL 1.1.1 and 1.0.2 versions are affected by this issue. Other OpenSSL
releases are out of support and have not been checked. Reported by David Benjamin (Google).
- Fixed in OpenSSL 1.0.2x (git commit) (Affected 1.0.2-1.0.2w)
- This issue was also addressed in OpenSSL 1.1.1i
- CVE-2020-1968 (OpenSSL advisory) [Low severity] 09 September 2020:
- The Raccoon attack exploits a flaw in the TLS specification which can lead to
an attacker being able to compute the pre-master secret in connections which
have used a Diffie-Hellman (DH) based ciphersuite. In such a case this would
result in the attacker being able to eavesdrop on all encrypted communications
sent over that TLS connection. The attack can only be exploited if an
implementation re-uses a DH secret across multiple TLS connections. Note that
this issue only impacts DH ciphersuites and not ECDH ciphersuites.
This issue affects OpenSSL 1.0.2 which is out of support and no longer
receiving public updates. OpenSSL 1.1.1 is not vulnerable to this
issue. Reported by Robert Merget, Marcus Brinkmann, Nimrod Aviram, and Juraj Somorovsky.
- Fixed in OpenSSL 1.0.2w (Affected 1.0.2-1.0.2v)
2019
- CVE-2019-1551 (OpenSSL advisory) [Low severity] 06 December 2019:
- There is an overflow bug in the x64_64 Montgomery squaring procedure used in
exponentiation with 512-bit moduli. No EC algorithms are affected. Analysis
suggests that attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as a
result of this defect would be very difficult to perform and are not believed
likely. Attacks against DH512 are considered just feasible. However, for an
attack the target would have to re-use the DH512 private key, which is not
recommended anyway. Also applications directly using the low level API
BN_mod_exp may be affected if they use BN_FLG_CONSTTIME. Reported by OSS-Fuzz and Guido Vranken.
- Fixed in OpenSSL 1.0.2u (git commit) (Affected 1.0.2-1.0.2t)
- This issue was also addressed in OpenSSL 1.1.1e
- 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.0.2t (git commit) (Affected 1.0.2-1.0.2s)
- This issue was also addressed in OpenSSL 1.1.1d, OpenSSL 1.1.0l
- 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.0.2t (git commit) (Affected 1.0.2-1.0.2s)
- This issue was also addressed in OpenSSL 1.1.1d, OpenSSL 1.1.0l
- 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.0.2t (git commit) (Affected 1.0.2-1.0.2s)
- This issue was also addressed in OpenSSL 1.1.1d, OpenSSL 1.1.0l
- CVE-2019-1559 (OpenSSL advisory) [Moderate severity] 26 February 2019:
- If an application encounters a fatal protocol error and then calls
SSL_shutdown() twice (once to send a close_notify, and once to receive one) then
OpenSSL can respond differently to the calling application if a 0 byte record is
received with invalid padding compared to if a 0 byte record is received with an
invalid MAC. If the application then behaves differently based on that in a way
that is detectable to the remote peer, then this amounts to a padding oracle
that could be used to decrypt data.
In order for this to be exploitable "non-stitched" ciphersuites must be in use.
Stitched ciphersuites are optimised implementations of certain commonly used
ciphersuites. Also the application must call SSL_shutdown() twice even if a
protocol error has occurred (applications should not do this but some do
anyway). AEAD ciphersuites are not impacted. Reported by Juraj Somorovsky, Robert Merget and Nimrod Aviram, with additional investigation by Steven Collison and Andrew Hourselt.
- Fixed in OpenSSL 1.0.2r (git commit) (Affected 1.0.2-1.0.2q)
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.0.2q (git commit) (Affected 1.0.2-1.0.2p)
- This issue was also addressed in OpenSSL 1.1.0i
- 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.0.2q (git commit) (Affected 1.0.2-1.0.2p)
- This issue was also addressed in OpenSSL 1.1.1a, OpenSSL 1.1.0j
- 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.0.2p (git commit) (Affected 1.0.2-1.0.2o)
- This issue was also addressed in OpenSSL 1.1.0i
- 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.0.2p (git commit) (Affected 1.0.2-1.0.2o)
- This issue was also addressed in OpenSSL 1.1.0i
- 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.0.2o (git commit) (Affected 1.0.2b-1.0.2n)
- This issue was also addressed in OpenSSL 1.1.0h
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.0.2n (git commit) (Affected 1.0.2-1.0.2m)
- This issue was also addressed in OpenSSL 1.1.0h
- CVE-2017-3737 (OpenSSL advisory) [Moderate severity] 07 December 2017:
- 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. Reported by David Benjamin (Google).
- Fixed in OpenSSL 1.0.2n (git commit) (Affected 1.0.2b-1.0.2m)
- 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.0.2m (git commit) (Affected 1.0.2-1.0.2l)
- This issue was also addressed in OpenSSL 1.1.0g
- 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.0.2m (git commit) (Affected 1.0.2-1.0.2l)
- This issue was also addressed in OpenSSL 1.1.0g
- 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.0.2k (git commit) (Affected 1.0.2-1.0.2j)
- This issue was also addressed in OpenSSL 1.1.0d
- 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.0.2k (git commit) (Affected 1.0.2-1.0.2j)
- This issue was also addressed in OpenSSL 1.1.0d
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.0.2k (git commit) (Affected 1.0.2-1.0.2j)
- This issue was also addressed in OpenSSL 1.1.0c
- CVE-2016-7052 (OpenSSL advisory) [Moderate severity] 26 September 2016:
- 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. Reported by Bruce Stephens and Thomas Jakobi.
- Fixed in OpenSSL 1.0.2j (git commit) (Affected 1.0.2i)
- 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.0.2i (git commit) (Affected 1.0.2-1.0.2h)
- This issue was also addressed in OpenSSL 1.1.0a, OpenSSL 1.0.1u
- CVE-2016-6306 (OpenSSL advisory) [Low severity] 21 September 2016:
- 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. Reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
- Fixed in OpenSSL 1.0.2i (git commit) (Affected 1.0.2-1.0.2h)
- This issue was also addressed in OpenSSL 1.0.1u
- CVE-2016-6303 (OpenSSL advisory) [Low severity] 24 August 2016:
- 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. Reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
- Fixed in OpenSSL 1.0.2i (git commit) (Affected 1.0.2-1.0.2h)
- This issue was also addressed in OpenSSL 1.0.1u
- 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.0.2i (Affected 1.0.2-1.0.2h)
- This issue was also addressed in OpenSSL 1.1.0
- CVE-2016-6302 (OpenSSL advisory) [Low severity] 23 August 2016:
- 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. Reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
- Fixed in OpenSSL 1.0.2i (git commit) (Affected 1.0.2-1.0.2h)
- This issue was also addressed in OpenSSL 1.0.1u
- CVE-2016-2179 (OpenSSL advisory) [Low severity] 22 August 2016:
- 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. Reported by Quan Luo.
- Fixed in OpenSSL 1.0.2i (git commit) (Affected 1.0.2-1.0.2h)
- This issue was also addressed in OpenSSL 1.0.1u
- CVE-2016-2181 (OpenSSL advisory) [Low severity] 19 August 2016:
- 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. Reported by OCAP audit team.
- Fixed in OpenSSL 1.0.2i (git commit) (Affected 1.0.2-1.0.2h)
- This issue was also addressed in OpenSSL 1.0.1u
- CVE-2016-2182 (OpenSSL advisory) [Low severity] 16 August 2016:
- 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. Reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
- Fixed in OpenSSL 1.0.2i (Affected 1.0.2-1.0.2h)
- This issue was also addressed in OpenSSL 1.0.1u
- CVE-2016-2180 (OpenSSL advisory) [Low severity] 22 July 2016:
- 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. Reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
- Fixed in OpenSSL 1.0.2i (Affected 1.0.2-1.0.2h)
- This issue was also addressed in OpenSSL 1.0.1u
- CVE-2016-2178 (OpenSSL advisory) [Low severity] 07 June 2016:
- 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. Reported by César Pereida (Aalto University), Billy Brumley (Tampere University of Technology), and Yuval Yarom (The University of Adelaide and NICTA).
- Fixed in OpenSSL 1.0.2i (Affected 1.0.2-1.0.2h)
- This issue was also addressed in OpenSSL 1.0.1u
- CVE-2016-2177 (OpenSSL advisory) [Low severity] 01 June 2016:
- 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. Reported by Guido Vranken.
- Fixed in OpenSSL 1.0.2i (Affected 1.0.2-1.0.2h)
- This issue was also addressed in OpenSSL 1.0.1u
- CVE-2016-2176 (OpenSSL advisory) [Low severity] 03 May 2016:
- 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. Reported by Guido Vranken.
- Fixed in OpenSSL 1.0.2h (Affected 1.0.2-1.0.2g)
- This issue was also addressed in OpenSSL 1.0.1t
- CVE-2016-2109 (OpenSSL advisory) [Low severity] 03 May 2016:
- 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. Reported by Brian Carpenter.
- Fixed in OpenSSL 1.0.2h (Affected 1.0.2-1.0.2g)
- This issue was also addressed in OpenSSL 1.0.1t
- CVE-2016-2108 (OpenSSL advisory) [High severity] 03 May 2016:
- 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. Reported by Huzaifa Sidhpurwala (Red Hat), Hanno Böck, David Benjamin (Google).
- Fixed in OpenSSL 1.0.2c (Affected 1.0.2-1.0.2b)
- This issue was also addressed in OpenSSL 1.0.1o
- CVE-2016-2107 (OpenSSL advisory) [High severity] 03 May 2016:
- 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. Reported by Juraj Somorovsky.
- Fixed in OpenSSL 1.0.2h (git commit) (Affected 1.0.2-1.0.2g)
- This issue was also addressed in OpenSSL 1.0.1t
- CVE-2016-2106 (OpenSSL advisory) [Low severity] 03 May 2016:
- 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. Reported by Guido Vranken.
- Fixed in OpenSSL 1.0.2h (Affected 1.0.2-1.0.2g)
- This issue was also addressed in OpenSSL 1.0.1t
- CVE-2016-2105 (OpenSSL advisory) [Low severity] 03 May 2016:
- 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). Reported by Guido Vranken.
- Fixed in OpenSSL 1.0.2h (Affected 1.0.2-1.0.2g)
- This issue was also addressed in OpenSSL 1.0.1t
- CVE-2016-0800 (OpenSSL advisory) [High severity] 01 March 2016:
- 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. Reported by Nimrod Aviram and Sebastian Schinzel.
- Fixed in OpenSSL 1.0.2g (Affected 1.0.2-1.0.2f)
- This issue was also addressed in OpenSSL 1.0.1s
- CVE-2016-0799 (OpenSSL advisory) [Low severity] 01 March 2016:
- 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. Reported by Guido Vranken.
- Fixed in OpenSSL 1.0.2g (Affected 1.0.2-1.0.2f)
- This issue was also addressed in OpenSSL 1.0.1s
- CVE-2016-0798 (OpenSSL advisory) [Low severity] 01 March 2016:
- 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. Reported by Emilia Käsper (OpenSSL).
- Fixed in OpenSSL 1.0.2g (Affected 1.0.2-1.0.2f)
- This issue was also addressed in OpenSSL 1.0.1s
- CVE-2016-0797 (OpenSSL advisory) [Low severity] 01 March 2016:
- 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. Reported by Guido Vranken.
- Fixed in OpenSSL 1.0.2g (Affected 1.0.2-1.0.2f)
- This issue was also addressed in OpenSSL 1.0.1s
- CVE-2016-0705 (OpenSSL advisory) [Low severity] 01 March 2016:
- 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. Reported by Adam Langley (Google/BoringSSL).
- Fixed in OpenSSL 1.0.2g (Affected 1.0.2-1.0.2f)
- This issue was also addressed in OpenSSL 1.0.1s
- CVE-2016-0704 (OpenSSL advisory) [Moderate severity] 01 March 2016:
- 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. Reported by David Adrian and J.Alex Halderman (University of Michigan).
- CVE-2016-0703 (OpenSSL advisory) [High severity] 01 March 2016:
- 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. Reported by David Adrian and J.Alex Halderman (University of Michigan).
- CVE-2016-0702 (OpenSSL advisory) [Low severity] 01 March 2016:
- 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. Reported by Yuval Yarom, The University of Adelaide and NICTA, Daniel Genkin, Technion and Tel Aviv University, and Nadia Heninger, University of Pennsylvania.
- Fixed in OpenSSL 1.0.2g (Affected 1.0.2-1.0.2f)
- This issue was also addressed in OpenSSL 1.0.1s
- CVE-2016-0701 (OpenSSL advisory) [High severity] 28 January 2016:
- 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. Reported by Antonio Sanso (Adobe).
- Fixed in OpenSSL 1.0.2f (Affected 1.0.2-1.0.2e)
- CVE-2015-3197 (OpenSSL advisory) [Low severity] 28 January 2016:
- 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. Reported by Nimrod Aviram and Sebastian Schinzel.
- Fixed in OpenSSL 1.0.2f (Affected 1.0.2-1.0.2e)
- This issue was also addressed in OpenSSL 1.0.1r
2015
- CVE-2015-3196 (OpenSSL advisory) [Low severity] 03 December 2015:
- 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. Reported by Stephen Henson (OpenSSL).
- CVE-2015-3195 (OpenSSL advisory) [Moderate severity] 03 December 2015:
- 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. Reported by Adam Langley (Google/BoringSSL) using libFuzzer.
- CVE-2015-3194 (OpenSSL advisory) [Moderate severity] 03 December 2015:
- 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. Reported by Loïc Jonas Etienne (Qnective AG).
- Fixed in OpenSSL 1.0.2e (Affected 1.0.2-1.0.2d)
- This issue was also addressed in OpenSSL 1.0.1q
- CVE-2015-3193 (OpenSSL advisory) [Moderate severity] 03 December 2015:
- 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. Reported by Hanno Böck.
- Fixed in OpenSSL 1.0.2e (Affected 1.0.2-1.0.2d)
- CVE-2015-1794 (OpenSSL advisory) [Low severity] 11 August 2015:
- 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. Reported by Guy Leaver (Cisco).
- Fixed in OpenSSL 1.0.2e (Affected 1.0.2-1.0.2d)
- CVE-2015-1793 (OpenSSL advisory) [High severity] 09 July 2015:
- 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. Reported by Adam Langley and David Benjamin (Google/BoringSSL).
- Fixed in OpenSSL 1.0.2d (Affected 1.0.2b-1.0.2c)
- This issue was also addressed in OpenSSL 1.0.1p
- CVE-2015-1792 (OpenSSL advisory) [Moderate severity] 11 June 2015:
- 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. Reported by Johannes Bauer.
- CVE-2015-1790 (OpenSSL advisory) [Moderate severity] 11 June 2015:
- 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. Reported by Michal Zalewski (Google).
- CVE-2015-1789 (OpenSSL advisory) [Moderate severity] 11 June 2015:
- 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. Reported by Robert Święcki (Google Security Team). Reported by Hanno Böck.
- CVE-2015-1788 (OpenSSL advisory) [Moderate severity] 11 June 2015:
- 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. Reported by Joseph Birr-Pixton.
- CVE-2015-1791 (OpenSSL advisory) [Low severity] 02 June 2015:
- 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. Reported by Emilia Käsper (OpenSSL).
- CVE-2015-1787 (OpenSSL advisory) [Moderate severity] 19 March 2015:
- Empty CKE with client auth and DHE.
If client auth is used then a server can seg fault in the event of a DHE
ciphersuite being selected and a zero length ClientKeyExchange message being
sent by the client. This could be exploited in a DoS attack. Reported by Matt Caswell (OpenSSL development team).
- Fixed in OpenSSL 1.0.2a (Affected 1.0.2)
- CVE-2015-0293 (OpenSSL advisory) [Moderate severity] 19 March 2015:
- DoS via reachable assert in SSLv2 servers. A malicious client can trigger an OPENSSL_assert in servers that both support SSLv2 and enable export cipher suites by sending a specially crafted SSLv2 CLIENT-MASTER-KEY message. Reported by Sean Burford (Google) and Emilia Käsper (OpenSSL development team).
- CVE-2015-0291 (OpenSSL advisory) [High severity] 19 March 2015:
- ClientHello sigalgs DoS. If a client connects to an OpenSSL 1.0.2 server and renegotiates with an
invalid signature algorithms extension a NULL pointer dereference will occur.
This can be exploited in a DoS attack against the server. Reported by David Ramos (Stanford University).
- Fixed in OpenSSL 1.0.2a (Affected 1.0.2)
- CVE-2015-0290 (OpenSSL advisory) [Moderate severity] 19 March 2015:
- Multiblock corrupted pointer.
OpenSSL 1.0.2 introduced the "multiblock" performance improvement. This feature
only applies on 64 bit x86 architecture platforms that support AES NI
instructions. A defect in the implementation of "multiblock" can cause OpenSSL's
internal write buffer to become incorrectly set to NULL when using non-blocking
IO. Typically, when the user application is using a socket BIO for writing, this
will only result in a failed connection. However if some other BIO is used then
it is likely that a segmentation fault will be triggered, thus enabling a
potential DoS attack. Reported by Daniel Danner and Rainer Mueller.
- Fixed in OpenSSL 1.0.2a (Affected 1.0.2)
- CVE-2015-0289 (OpenSSL advisory) [Moderate severity] 19 March 2015:
- PKCS#7 NULL pointer dereference. The PKCS#7 parsing code does not handle missing outer ContentInfo 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 verify PKCS#7 signatures, decrypt PKCS#7 data or otherwise parse PKCS#7 structures from untrusted sources are affected. OpenSSL clients and servers are not affected. Reported by Michal Zalewski (Google).
- CVE-2015-0287 (OpenSSL advisory) [Moderate severity] 19 March 2015:
- ASN.1 structure reuse memory corruption. Reusing a structure in ASN.1 parsing may allow an attacker to cause memory corruption via an invalid write. Such reuse is and has been strongly discouraged and is believed to be rare. Reported by Emilia Käsper (OpenSSL development team).
- CVE-2015-0286 (OpenSSL advisory) [Moderate severity] 19 March 2015:
- Segmentation fault in ASN1_TYPE_cmp. The function ASN1_TYPE_cmp will crash with an invalid read if an attempt is made to compare ASN.1 boolean types. Since ASN1_TYPE_cmp is used to check certificate signature algorithm consistency 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. Reported by Stephen Henson (OpenSSL development team).
- CVE-2015-0209 (OpenSSL advisory) [Low severity] 19 March 2015:
- Use After Free following d2i_ECPrivatekey error. A malformed EC private key file consumed via the d2i_ECPrivateKey function could cause a use after free condition. This, in turn, could cause a double free in several private key parsing functions (such as d2i_PrivateKey or EVP_PKCS82PKEY) and could lead to a DoS attack or memory corruption for applications that receive EC private keys from untrusted sources. This scenario is considered rare. Reported by The BoringSSL project.
- CVE-2015-0208 (OpenSSL advisory) [Moderate severity] 19 March 2015:
- Segmentation fault for invalid PSS parameters.
The signature verification routines will crash with a NULL pointer
dereference if presented with an ASN.1 signature using the RSA PSS
algorithm and invalid parameters. 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. Reported by Brian Carpenter.
- Fixed in OpenSSL 1.0.2a (Affected 1.0.2)
- CVE-2015-0207 (OpenSSL advisory) [Moderate severity] 19 March 2015:
- Segmentation fault in DTLSv1_listen.
A defect in the implementation of DTLSv1_listen means that state is preserved in
the SSL object from one invocation to the next that can lead to a segmentation
fault. Errors processing the initial ClientHello can trigger this scenario. An
example of such an error could be that a DTLS1.0 only client is attempting to
connect to a DTLS1.2 only server. Reported by Per Allansson.
- Fixed in OpenSSL 1.0.2a (Affected 1.0.2)
- CVE-2015-0285 (OpenSSL advisory) [Low severity] 10 March 2015:
- Under certain conditions an OpenSSL 1.0.2 client can complete a handshake with
an unseeded PRNG. If the handshake succeeds then the client random that has been used will have
been generated from a PRNG with insufficient entropy and therefore the output
may be predictable. Reported by Matt Caswell (OpenSSL development team).
- Fixed in OpenSSL 1.0.2a (Affected 1.0.2)
- CVE-2015-0288 (OpenSSL advisory) [Low severity] 02 March 2015:
- X509_to_X509_REQ NULL pointer deref. 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. Reported by Brian Carpenter.