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.

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

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.

The getclientmasterkey function in s2srvr.c in the SSLv2 implementation in OpenSSL before 0.9.8zf, 1.0.0 before 1.0.0r, 1.0.1 before 1.0.1m, and 1.0.2 before 1.0.2a accepts a nonzero CLIENT-MASTER-KEY CLEAR-KEY-LENGTH value for an arbitrary cipher, which allows man-in-the-middle attackers to determine the MASTER-KEY value and decrypt TLS ciphertext data by leveraging a Bleichenbacher RSA padding oracle, a related issue to CVE-2016-0800.

An oracle protection mechanism in the getclientmasterkey function in s2srvr.c in the SSLv2 implementation in OpenSSL before 0.9.8zf, 1.0.0 before 1.0.0r, 1.0.1 before 1.0.1m, and 1.0.2 before 1.0.2a overwrites incorrect MASTER-KEY bytes during use of export cipher suites, which makes it easier for remote attackers to decrypt TLS ciphertext data by leveraging a Bleichenbacher RSA padding oracle, a related issue to CVE-2016-0800.

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.

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.

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.

As per Upstream security advisory:

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.

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 Jan 8th 2016 by Yuval Yarom, The University of Adelaide and NICTA, Daniel Genkin, Technion and Tel Aviv University, and Nadia Heninger, University of Pennsylvania with more information at http://cachebleed.info. The fix was developed by Andy Polyakov of OpenSSL.

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.

Last updated 24 July 2024

Memory leak in the tlsdecryptticket function in t1lib.c in OpenSSL before 0.9.8zc, 1.0.0 before 1.0.0o, and 1.0.1 before 1.0.1j allows remote attackers to cause a denial of service (memory consumption) via a crafted session ticket that triggers an integrity-check failure.

OpenSSL before 0.9.8zc, 1.0.0 before 1.0.0o, and 1.0.1 before 1.0.1j does not properly enforce the no-ssl3 build option, which allows remote attackers to bypass intended access restrictions via an SSL 3.0 handshake, related to s23clnt.c and s23srvr.c.

Memory leak in d1srtp.c in the DTLS SRTP extension in OpenSSL 1.0.1 before 1.0.1j allows remote attackers to cause a denial of service (memory consumption) via a crafted handshake message.

The sslsetclientdisabled function in t1lib.c in OpenSSL 1.0.1 before 1.0.1i allows remote SSL servers to cause a denial of service (NULL pointer dereference and client application crash) via a ServerHello message that includes an SRP ciphersuite without the required negotiation of that ciphersuite with the client.

Double free vulnerability in d1both.c in the DTLS implementation in OpenSSL 0.9.8 before 0.9.8zb, 1.0.0 before 1.0.0n, and 1.0.1 before 1.0.1i allows remote attackers to cause a denial of service (application crash) via crafted DTLS packets that trigger an error condition.

Multiple buffer overflows in crypto/srp/srplib.c in the SRP implementation in OpenSSL 1.0.1 before 1.0.1i allow remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via an invalid SRP (1) g, (2) A, or (3) B parameter.

By pathologically modifying a clients ClientHello message with fragmentation, it's possible to cause the server to negotiate TLS 1.0 instead of a higher version, even if both client and server support a higher protocol version.

It was found that OpenSSL DTLS clients using anonymous (EC)DH ciphersuites could be crashed by a malicious server via a handshake message.

It was found that an attacker could force OpenSSL to leak memory and never free it via DTLS packets.

A vulnerability in the processing of DTLS handshake messages was found that results in large amounts of memory being used. Once the Denial Of Service attack has ceased, the memory will be freed.

A race condition was found in the sslparseserverhellotlsext() code that may result in upto 255 bytes being written to memory that had been free'd if an ec point format extension was sent by the server. This issue only affects multi-threaded clients.

It was found that OBJobj2txt may cause pretty printing functions such as X509nameoneline, X509nameprintex, and others, to leak information from the stack. If applications echo pretty printing output, then a remote attacker could exploit this flaw to read information from the stack. OpenSSL clients and servers are not affected by this flaw; only applications that echo pretty printing output are affected.

A flaw was found in the way OpenSSL handled TLS handshakes. A carefully crafted invalid TLS handshake could crash OpenSSL with a NULL pointer exception.

This flaw only affects OpenSSL versions 1.0.1 through 1.0.1e; earlier versions are not affected and this is corrected in upstream version 1.0.1f [1],[2].

[1] http://www.openssl.org/news/vulnerabilities.html#2013-4353 [2] http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=197e0ea817ad64820789d86711d55ff50d71f631

Integer underflow in OpenSSL before 0.9.8x, 1.0.0 before 1.0.0j, and 1.0.1 before 1.0.1c, when TLS 1.1, TLS 1.2, or DTLS is used with CBC encryption, allows remote attackers to cause a denial of service (buffer over-read) or possibly have unspecified other impact via a crafted TLS packet that is not properly handled during a certain explicit IV calculation.