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

Integer overflow in the MDC2Update function in crypto/mdc2/mdc2dgst.c in OpenSSL before 1.1.0 allows remote attackers to cause a denial of service (out-of-bounds write and application crash) or possibly have unspecified other impact via unknown vectors.

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.

Last updated 24 July 2024

crypto/rsa/rsaameth.c in OpenSSL 1.0.1 before 1.0.1q and 1.0.2 before 1.0.2e allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via an RSA PSS ASN.1 signature that lacks a mask generation function parameter.

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.

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 vulnerability existed in previous versions of OpenSSL related to the processing of base64-encoded data. Any code path that reads base64 data from an untrusted source could be affected (such as the PEM processing routines). Maliciously crafted base 64 data could trigger a segmenation fault or memory corruption. This was addressed in previous versions of OpenSSL but has not been included in any security advisory until now.

This issue affects OpenSSL versions 1.0.1, 1.0.0, and 0.9.8. This issue is fixed in versions: 1.0.1h, 1.0.0m, and 0.9.8za.

Acknowledgements:

Red Hat would like to thank the OpenSSL project for reporting this issue. Upstream acknowledges Robert Dugal and David Ramos as the original reporters.

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.

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.

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.

A use-after-free flaw was found in the way OpenSSL imported malformed Elliptic Curve private keys. A specially crafted key file could cause an application using OpenSSL to crash when imported.

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.

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.

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.

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.

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.

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.

The ASN1TYPEcmp function in crypto/asn1/atype.c 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 does not properly perform boolean-type comparisons, which allows remote attackers to cause a denial of service (invalid read operation and application crash) via a crafted X.509 certificate to an endpoint that uses the certificate-verification feature.

Multiple flaws were found in the way OpenSSL parsed X.509 certificates. An attacker could use these flaws to modify an X.509 certificate to produce a certificate with a different fingerprint without invalidating its signature, and possibly bypass fingerprint-based blacklisting in applications.

A NULL pointer dereference flaw was found in OpenSSL's X509toX509REQ() function. A remote attacker could use this flaw to crash an OpenSSL server with an invalid certificate key. Note that this function is rarely used in practice.

This issue affects OpenSSL versions: 1.0.2, 1.0.1, 1.0.0, and 0.9.8. This issue is fixed in versions: 1.0.2a, 1.0.1m, 1.0.0r, and 0.9.8zf.

Upstream patch:

https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=28a00bcd8e318da18031b2ac8778c64147cd54f9

Acknowledgements:

Red Hat would like to thank the OpenSSL project for reporting this issue. Upstream acknowledges Brian Carpenter as the original reporter.

A malicious client can trigger an OPENSSLassert (i.e., an abort) in servers that both support SSLv2 and enable export cipher suites by sending a specially crafted SSLv2 CLIENT-MASTER-KEY message.

This issue affects OpenSSL versions: 1.0.2, 1.0.1, 1.0.0, and 0.9.8. This issue is fixed in versions: 1.0.2a, 1.0.1m, 1.0.0r, and 0.9.8zf.

Acknowledgements:

Name: the OpenSSL project Upstream: Sean Burford (Google), Emilia Käsper (the OpenSSL development team)

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.

Applications that parse structures containing CHOICE or ANY DEFINED BY components may be affected. Certificate parsing (d2iX509 and related functions) are however not affected. OpenSSL clients and servers are not affected.

This issue affects OpenSSL versions: 1.0.2, 1.0.1, 1.0.0, and 0.9.8. This issue is fixed in versions: 1.0.2a, 1.0.1m, 1.0.0r, and 0.9.8zf.

Acknowledgements:

Red Hat would like to thank the OpenSSL project for reporting this issue. Upstream acknowledges Emilia Käsper as the original reporter.

The PKCS#7 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 does not properly handle a lack of outer ContentInfo, which allows attackers to cause a denial of service (NULL pointer dereference and application crash) by leveraging an application that processes arbitrary PKCS#7 data and providing malformed data with ASN.1 encoding, related to crypto/pkcs7/pk7doit.c and crypto/pkcs7/pk7lib.c.

A flaw was found in the way that OpenSSL handled OCSP response verification, which could be exploited to conduct a denial of service attack. This flaw affects all versions of OpenSSL and is fixed in versions 1.0.1d, 1.0.0k, and 0.9.8y.

External References:

http://www.openssl.org/news/secadv20130205.txt

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.

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.

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

Memory leak in the dtls1bufferrecord function in d1pkt.c in OpenSSL 1.0.0 before 1.0.0p and 1.0.1 before 1.0.1k allows remote attackers to cause a denial of service (memory consumption) by sending many duplicate records for the next epoch, leading to failure of replay detection.