Cryptography and SSL/TLS Toolkit

Vulnerabilities

If you think you have found a security bug in OpenSSL,
please send mail to openssl-security@openssl.org.
If you want to encrypt the mail, you can use our
team's PGP Key. Or you can
send mail to one or more individual OMC Members,
encrypted or plaintext.
We will work with you to assess and fix the flaw,
as discussed in our
Security Policy.

Fixed in OpenSSL 1.1.0

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.

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.

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.

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).

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.

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.

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.

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.

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).

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).

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).

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.).

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.).

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.).