As per Upstream advisory:
The internal |fmtstr| function used in processing a "%s" format string in the BIOprintf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings.
Additionally the internal |doaproutch| 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 INTMAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur.
These issues will only occur on certain platforms where sizeof(sizet) > sizeof(int). E.g. many 64 bit systems. 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 BIOprintf 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.
This issue affects OpenSSL versions 1.0.2 and 1.0.1.
OpenSSL 1.0.2 users should upgrade to 1.0.2g OpenSSL 1.0.1 users should upgrade to 1.0.1s
This issue was reported to OpenSSL on February 23rd by Guido Vranken. The fix was developed by Matt Caswell of the OpenSSL development team.
It was found that doaproutch function in crypto/bio/bprint.c in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g does not verify that a certain memory allocation succeeds, which allows remote attackers to cause a denial of service (out-of-bounds write or memory consumption) or possibly have unspecified other impact via a long string, as demonstrated by a large amount of ASN.1 data. This issues is different than CVE-2016-0799.
Upstream patch:
https://git.openssl.org/?p=openssl.git;a=commit;h=578b956fe741bf8e84055547b1e83c28dd902c73
As per Upstream advisory:
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.
This issue affects OpenSSL versions 1.0.2 and 1.0.1.
OpenSSL 1.0.2 users should upgrade to 1.0.2g OpenSSL 1.0.1 users should upgrade to 1.0.1s
This issue was reported to OpenSSL on 7th February 2016 by Adam Langley (Google/BoringSSL) using libFuzzer. The fix was developed by Dr Stephen Henson of OpenSSL.
A common idiom in the codebase is:
if (p + len > limit) { return; / Too long / }
where p points to some malloc'd data of SIZE bytes and limit == p + SIZE. 'len' could be from some externally supplied data, e.g. TLS message. This idiom is vulnerable to integer overflow vulnerability.
An out of bounds write flaw was discovered in the OpenSSL BNbn2dec() function. An attacker able to make an application using OpenSSL to process a large BIGNUM could cause the application to crash or, possibly, execute arbitrary code.
An overflow can occur in MDC2Update() under certain circumstances resulting in an out of bounds (OOB) error. This attack is impractical on most platforms due to the size of data required to trigger the OOB error.
Node.js is impacted by this flaw but due to the impracticalities of exploiting it and the very low usage of of MDC-2, it is very low severity for Node.js users.
The X509NAMEoneline function in crypto/x509/x509obj.c in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h allows remote attackers to obtain sensitive information from process stack memory or cause a denial of service (buffer over-read) via crafted EBCDIC ASN.1 data.
A potential denial-of-service vector for Node.js TLS servers using client certificate authentication; TLS clients are also impacted. Details are available at <http://openssl.org/news/secadv/20151203.txt>.
An integer overflow flaw, leading to a buffer overflow, was found in the way the EVPEncodeUpdate() function of OpenSSL parsed very large amounts of input data. A remote attacker could use this flaw to crash an application using OpenSSL or, possibly, execute arbitrary code with the permissions of the user running that application.
A denial of service flaw was found in the way OpenSSL parsed certain ASN.1-encoded data from BIO (OpenSSL's I/O abstraction) inputs. An application using OpenSSL that accepts untrusted ASN.1 BIO input could be forced to allocate an excessive amount of data.
An integer overflow flaw, leading to a buffer overflow, was found in the way the EVPEncryptUpdate() function of OpenSSL parsed very large amounts of input data. A remote attacker could use this flaw to crash an application using OpenSSL or, possibly, execute arbitrary code with the permissions of the user running that application.
As per Upstream advisory:
In the BNhex2bn function the number of hex digits is calculated using an int value |i|. Later |bnexpand| is called with a value of |i 4|. For large values of |i| this can result in |bnexpand| 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 BNdec2bn. This could have security consequences if BNhex2bn/BNdec2bn 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.
This issue affects OpenSSL versions 1.0.2 and 1.0.1.
OpenSSL 1.0.2 users should upgrade to 1.0.2g OpenSSL 1.0.1 users should upgrade to 1.0.1s
This issue was reported to OpenSSL on February 19th 2016 by Guido Vranken. The fix was developed by Matt Caswell of the OpenSSL development team.
A malicious client can exhaust a server's memory, resulting in a denial of service (DoS) by sending very large OCSP Status Request extensions in a single session.
This flaw is labelled high severity due to the ease of use for a DoS attack and Node.js servers using TLS are vulnerable.
A flaw was found in the way the DES/3DES cipher was used as part of the TLS/SSL protocol. A man-in-the-middle attacker could use this flaw to recover some plaintext data by capturing large amounts of encrypted traffic between TLS/SSL server and client if the communication used a DES/3DES based ciphersuite.
It was discovered that the Datagram TLS (DTLS) implementation could fail to release memory in certain cases. A malicious DTLS client could cause a DTLS server using OpenSSL to consume an excessive amount of memory and, possibly, exit unexpectedly after exhausting all available memory.
An integer underflow flaw leading to a buffer over-read was found in the way OpenSSL parsed TLS session tickets. A remote attacker could use this flaw to crash a TLS server using OpenSSL if it used SHA-512 as HMAC for session tickets.
An OOB read flaw was found in the RFC 3161 Public Key Infrastructure Time-Stamp Protocol code of OpenSSL. An attacker could use this flaw to cause the openssl binary to crash when specially-crafted time-stamp file is parsed via the "openssl ts" command.
Upstream commit:
master: https://github.com/openssl/openssl/commit/0ed26acce328ec16a3aa635f1ca37365e8c7403a 1.0.1: https://github.com/openssl/openssl/commit/6adf409c7432b90c06d9890787fe56c48f2a16e7
A flaw was found in the Datagram TLS (DTLS) replay protection implementation in OpenSSL. A remote attacker could possibly use this flaw to make a DTLS server using OpenSSL to reject further packets sent from a DTLS client over an established DTLS connection.
An attack may be possible against a Node.js TLS server using DHE key exchange. Details are available at <http://openssl.org/news/secadv/20151203.txt>.
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.0.2, the crash can be triggered when using RC4-MD5; users who have not disabled that algorithm should update to 1.0.2k
External References:
https://www.openssl.org/news/secadv/20170126.txt
Memory leak in the SRPVBASEgetbyuser implementation in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g allows remote attackers to cause a denial of service (memory consumption) by providing an invalid username in a connection attempt, related to apps/sserver.c and crypto/srp/srpvfy.c.
A man-in-the-middle (MITM) attacker may be able to execute a padding oracle attack to decrypt traffic when a connection uses an AES-CBC cipher and the server runs on an Intel CPU supporting AES-NI. This is a common configuration for TLS servers.
The OpenSSL project has labelled this vulnerability high severity.
Last updated 24 July 2024
As noted by the OpenSSL team, the likelihood of being able to craft a practical attack that uses this flaw is very low. In addition, Node.js enables SSLOPSINGLEDHUSE, further decreasing the chance of a successful exploit of this vulnerability in a Node.js service.
All active versions of Node.js are affected, but the severity is very low for Node.js users.
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 (SSLdohandshake(), SSLaccept() and SSLconnect()), however due to a bug it does not work correctly if SSLread() or SSLwrite() is called directly. In that scenario, if the handshake fails then a fatal error will be returned in the initial function call. If SSLread()/SSLwrite() 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 SSLread()/SSLwrite() being issued after having already received a fatal error.
External References:
https://www.openssl.org/news/secadv/20171207.txt
OpenSSL could allow a remote attacker to obtain sensitive information, caused by an overflow bug in the AVX2 Montgomery multiplication procedure used in exponentiation with 1024-bit moduli. An attacker could exploit this vulnerability to obtain information about the private key.
Note: In order to exploit this vulnerability, the server would have to share the DH1024 private key among multiple clients, which is no longer an option since CVE-2016-0701.
The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to send a ServerVerify message before establishing that a client possesses certain plaintext RSA data, which makes it easier for remote attackers to decrypt TLS ciphertext data by leveraging a Bleichenbacher RSA padding oracle, aka a "DROWN" attack.
ssl/s2srvr.c in OpenSSL 1.0.1 before 1.0.1r and 1.0.2 before 1.0.2f does not prevent use of disabled ciphers, which makes it easier for man-in-the-middle attackers to defeat cryptographic protection mechanisms by performing computations on SSLv2 traffic, related to the getclientmasterkey and getclienthello functions.
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.
This is very low severity for Node.js users due to the difficulty in taking advantage of this attack and because DSA is very rarely used.
If an X.509 certificate has a malformed IPAddressFamily extension, OpenSSL could do a one-byte buffer overread. The most likely result would be an erroneous display of the certificate in text format.
External References:
https://www.openssl.org/news/secadv/20170828.txt
References:
https://github.com/openssl/openssl/pull/4276