| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| OpenSSL 3.0.0 through 3.3.2 on the PowerPC architecture is vulnerable to a Minerva attack, exploitable by measuring the time of signing of random messages using the EVP_DigestSign API, and then using the private key to extract the K value (nonce) from the signatures. Next, based on the bit size of the extracted nonce, one can compare the signing time of full-sized nonces to signatures that used smaller nonces, via statistical tests. There is a side-channel in the P-364 curve that allows private key extraction (also, there is a dependency between the bit size of K and the size of the side channel). NOTE: This CVE is disputed because the OpenSSL security policy explicitly notes that any side channels which require same physical system to be detected are outside of the threat model for the software. The timing signal is so small that it is infeasible to be detected without having the attacking process running on the same physical system. |
| Issue summary: A timing side-channel which could potentially allow recovering
the private key exists in the ECDSA signature computation.
Impact summary: A timing side-channel in ECDSA signature computations
could allow recovering the private key by an attacker. However, measuring
the timing would require either local access to the signing application or
a very fast network connection with low latency.
There is a timing signal of around 300 nanoseconds when the top word of
the inverted ECDSA nonce value is zero. This can happen with significant
probability only for some of the supported elliptic curves. In particular
the NIST P-521 curve is affected. To be able to measure this leak, the attacker
process must either be located in the same physical computer or must
have a very fast network connection with low latency. For that reason
the severity of this vulnerability is Low.
The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are affected by this issue. |
| Issue summary: Checking excessively long DSA keys or parameters may be very
slow.
Impact summary: Applications that use the functions EVP_PKEY_param_check()
or EVP_PKEY_public_check() to check a DSA public key or DSA parameters may
experience long delays. Where the key or parameters that are being checked
have been obtained from an untrusted source this may lead to a Denial of
Service.
The functions EVP_PKEY_param_check() or EVP_PKEY_public_check() perform
various checks on DSA parameters. Some of those computations take a long time
if the modulus (`p` parameter) is too large.
Trying to use a very large modulus is slow and OpenSSL will not allow using
public keys with a modulus which is over 10,000 bits in length for signature
verification. However the key and parameter check functions do not limit
the modulus size when performing the checks.
An application that calls EVP_PKEY_param_check() or EVP_PKEY_public_check()
and supplies a key or parameters obtained from an untrusted source could be
vulnerable to a Denial of Service attack.
These functions are not called by OpenSSL itself on untrusted DSA keys so
only applications that directly call these functions may be vulnerable.
Also vulnerable are the OpenSSL pkey and pkeyparam command line applications
when using the `-check` option.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are affected by this issue. |
| Issue summary: Calling the OpenSSL API function SSL_free_buffers may cause
memory to be accessed that was previously freed in some situations
Impact summary: A use after free can have a range of potential consequences such
as the corruption of valid data, crashes or execution of arbitrary code.
However, only applications that directly call the SSL_free_buffers function are
affected by this issue. Applications that do not call this function are not
vulnerable. Our investigations indicate that this function is rarely used by
applications.
The SSL_free_buffers function is used to free the internal OpenSSL buffer used
when processing an incoming record from the network. The call is only expected
to succeed if the buffer is not currently in use. However, two scenarios have
been identified where the buffer is freed even when still in use.
The first scenario occurs where a record header has been received from the
network and processed by OpenSSL, but the full record body has not yet arrived.
In this case calling SSL_free_buffers will succeed even though a record has only
been partially processed and the buffer is still in use.
The second scenario occurs where a full record containing application data has
been received and processed by OpenSSL but the application has only read part of
this data. Again a call to SSL_free_buffers will succeed even though the buffer
is still in use.
While these scenarios could occur accidentally during normal operation a
malicious attacker could attempt to engineer a stituation where this occurs.
We are not aware of this issue being actively exploited.
The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue. |
| A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the `.' character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service). In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.
|
| A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution. Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler. Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described above have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible. In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects. Fixed in OpenSSL 3.0.7 (Affected 3.0.0,3.0.1,3.0.2,3.0.3,3.0.4,3.0.5,3.0.6). |
| 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. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc). |
| Issue summary: PBMAC1 parameters in PKCS#12 files are missing validation
which can trigger a stack-based buffer overflow, invalid pointer or NULL
pointer dereference during MAC verification.
Impact summary: The stack buffer overflow or NULL pointer dereference may
cause a crash leading to Denial of Service for an application that parses
untrusted PKCS#12 files. The buffer overflow may also potentially enable
code execution depending on platform mitigations.
When verifying a PKCS#12 file that uses PBMAC1 for the MAC, the PBKDF2
salt and keylength parameters from the file are used without validation.
If the value of keylength exceeds the size of the fixed stack buffer used
for the derived key (64 bytes), the key derivation will overflow the buffer.
The overflow length is attacker-controlled. Also, if the salt parameter is
not an OCTET STRING type this can lead to invalid or NULL pointer
dereference.
Exploiting this issue requires a user or application to process
a maliciously crafted PKCS#12 file. It is uncommon to accept untrusted
PKCS#12 files in applications as they are usually used to store private
keys which are trusted by definition. For this reason the issue was assessed
as Moderate severity.
The FIPS modules in 3.6, 3.5 and 3.4 are not affected by this issue, as
PKCS#12 processing is outside the OpenSSL FIPS module boundary.
OpenSSL 3.6, 3.5 and 3.4 are vulnerable to this issue.
OpenSSL 3.3, 3.0, 1.1.1 and 1.0.2 are not affected by this issue as they do
not support PBMAC1 in PKCS#12. |
| Issue summary: Parsing CMS AuthEnvelopedData or EnvelopedData message with
maliciously crafted AEAD parameters can trigger a stack buffer overflow.
Impact summary: A stack buffer overflow may lead to a crash, causing Denial
of Service, or potentially remote code execution.
When parsing CMS (Auth)EnvelopedData structures that use AEAD ciphers such as
AES-GCM, the IV (Initialization Vector) encoded in the ASN.1 parameters is
copied into a fixed-size stack buffer without verifying that its length fits
the destination. An attacker can supply a crafted CMS message with an
oversized IV, causing a stack-based out-of-bounds write before any
authentication or tag verification occurs.
Applications and services that parse untrusted CMS or PKCS#7 content using
AEAD ciphers (e.g., S/MIME (Auth)EnvelopedData with AES-GCM) are vulnerable.
Because the overflow occurs prior to authentication, no valid key material
is required to trigger it. While exploitability to remote code execution
depends on platform and toolchain mitigations, the stack-based write
primitive represents a severe risk.
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this
issue, as the CMS implementation is outside the OpenSSL FIPS module
boundary.
OpenSSL 3.6, 3.5, 3.4, 3.3 and 3.0 are vulnerable to this issue.
OpenSSL 1.1.1 and 1.0.2 are not affected by this issue. |
| Issue summary: If an application using the SSL_CIPHER_find() function in
a QUIC protocol client or server receives an unknown cipher suite from
the peer, a NULL dereference occurs.
Impact summary: A NULL pointer dereference leads to abnormal termination of
the running process causing Denial of Service.
Some applications call SSL_CIPHER_find() from the client_hello_cb callback
on the cipher ID received from the peer. If this is done with an SSL object
implementing the QUIC protocol, NULL pointer dereference will happen if
the examined cipher ID is unknown or unsupported.
As it is not very common to call this function in applications using the QUIC
protocol and the worst outcome is Denial of Service, the issue was assessed
as Low severity.
The vulnerable code was introduced in the 3.2 version with the addition
of the QUIC protocol support.
The FIPS modules in 3.6, 3.5, 3.4 and 3.3 are not affected by this issue,
as the QUIC implementation is outside the OpenSSL FIPS module boundary.
OpenSSL 3.6, 3.5, 3.4 and 3.3 are vulnerable to this issue.
OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue. |
| Issue summary: The 'openssl dgst' command-line tool silently truncates input
data to 16MB when using one-shot signing algorithms and reports success instead
of an error.
Impact summary: A user signing or verifying files larger than 16MB with
one-shot algorithms (such as Ed25519, Ed448, or ML-DSA) may believe the entire
file is authenticated while trailing data beyond 16MB remains unauthenticated.
When the 'openssl dgst' command is used with algorithms that only support
one-shot signing (Ed25519, Ed448, ML-DSA-44, ML-DSA-65, ML-DSA-87), the input
is buffered with a 16MB limit. If the input exceeds this limit, the tool
silently truncates to the first 16MB and continues without signaling an error,
contrary to what the documentation states. This creates an integrity gap where
trailing bytes can be modified without detection if both signing and
verification are performed using the same affected codepath.
The issue affects only the command-line tool behavior. Verifiers that process
the full message using library APIs will reject the signature, so the risk
primarily affects workflows that both sign and verify with the affected
'openssl dgst' command. Streaming digest algorithms for 'openssl dgst' and
library users are unaffected.
The FIPS modules in 3.5 and 3.6 are not affected by this issue, as the
command-line tools are outside the OpenSSL FIPS module boundary.
OpenSSL 3.5 and 3.6 are vulnerable to this issue.
OpenSSL 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are not affected by this issue. |
| Issue summary: A TLS 1.3 connection using certificate compression can be
forced to allocate a large buffer before decompression without checking
against the configured certificate size limit.
Impact summary: An attacker can cause per-connection memory allocations of
up to approximately 22 MiB and extra CPU work, potentially leading to
service degradation or resource exhaustion (Denial of Service).
In affected configurations, the peer-supplied uncompressed certificate
length from a CompressedCertificate message is used to grow a heap buffer
prior to decompression. This length is not bounded by the max_cert_list
setting, which otherwise constrains certificate message sizes. An attacker
can exploit this to cause large per-connection allocations followed by
handshake failure. No memory corruption or information disclosure occurs.
This issue only affects builds where TLS 1.3 certificate compression is
compiled in (i.e., not OPENSSL_NO_COMP_ALG) and at least one compression
algorithm (brotli, zlib, or zstd) is available, and where the compression
extension is negotiated. Both clients receiving a server CompressedCertificate
and servers in mutual TLS scenarios receiving a client CompressedCertificate
are affected. Servers that do not request client certificates are not
vulnerable to client-initiated attacks.
Users can mitigate this issue by setting SSL_OP_NO_RX_CERTIFICATE_COMPRESSION
to disable receiving compressed certificates.
The FIPS modules in 3.6, 3.5, 3.4 and 3.3 are not affected by this issue,
as the TLS implementation is outside the OpenSSL FIPS module boundary.
OpenSSL 3.6, 3.5, 3.4 and 3.3 are vulnerable to this issue.
OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue. |
| 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. Fixed in OpenSSL 3.0.4 (Affected 3.0.0,3.0.1,3.0.2,3.0.3). Fixed in OpenSSL 1.1.1p (Affected 1.1.1-1.1.1o). Fixed in OpenSSL 1.0.2zf (Affected 1.0.2-1.0.2ze). |
| 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. Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2). Fixed in OpenSSL 1.1.1o (Affected 1.1.1-1.1.1n). Fixed in OpenSSL 1.0.2ze (Affected 1.0.2-1.0.2zd). |
| Action1 Uncontrolled Search Path Element Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Action1. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.
The specific flaw exists within the configuration of OpenSSL. The product loads an OpenSSL configuration file from an unsecured location. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of SYSTEM. Was ZDI-CAN-26767. |
| A NULL pointer can be dereferenced when signatures are being
verified on PKCS7 signed or signedAndEnveloped data. In case the hash
algorithm used for the signature is known to the OpenSSL library but
the implementation of the hash algorithm is not available the digest
initialization will fail. There is a missing check for the return
value from the initialization function which later leads to invalid
usage of the digest API most likely leading to a crash.
The unavailability of an algorithm can be caused by using FIPS
enabled configuration of providers or more commonly by not loading
the legacy provider.
PKCS7 data is processed by the SMIME library calls and also by the
time stamp (TS) library calls. The TLS implementation in OpenSSL does
not call these functions however third party applications would be
affected if they call these functions to verify signatures on untrusted
data. |
| There is a type confusion vulnerability relating to X.400 address processing
inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but
the public structure definition for GENERAL_NAME incorrectly specified the type
of the x400Address field as ASN1_TYPE. This field is subsequently interpreted by
the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather than an
ASN1_STRING.
When CRL checking is enabled (i.e. the application sets the
X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass
arbitrary pointers to a memcmp call, enabling them to read memory contents or
enact a denial of service. In most cases, the attack requires the attacker to
provide both the certificate chain and CRL, neither of which need to have a
valid signature. If the attacker only controls one of these inputs, the other
input must already contain an X.400 address as a CRL distribution point, which
is uncommon. As such, this vulnerability is most likely to only affect
applications which have implemented their own functionality for retrieving CRLs
over a network. |
| An invalid pointer dereference on read can be triggered when an
application tries to check a malformed DSA public key by the
EVP_PKEY_public_check() function. This will most likely lead
to an application crash. This function can be called on public
keys supplied from untrusted sources which could allow an attacker
to cause a denial of service attack.
The TLS implementation in OpenSSL does not call this function
but applications might call the function if there are additional
security requirements imposed by standards such as FIPS 140-3. |
| An invalid pointer dereference on read can be triggered when an
application tries to load malformed PKCS7 data with the
d2i_PKCS7(), d2i_PKCS7_bio() or d2i_PKCS7_fp() functions.
The result of the dereference is an application crash which could
lead to a denial of service attack. The TLS implementation in OpenSSL
does not call this function however third party applications might
call these functions on untrusted data. |
| The public API function BIO_new_NDEF is a helper function used for streaming
ASN.1 data via a BIO. It is primarily used internally to OpenSSL to support the
SMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by
end user applications.
The function receives a BIO from the caller, prepends a new BIO_f_asn1 filter
BIO onto the front of it to form a BIO chain, and then returns the new head of
the BIO chain to the caller. Under certain conditions, for example if a CMS
recipient public key is invalid, the new filter BIO is freed and the function
returns a NULL result indicating a failure. However, in this case, the BIO chain
is not properly cleaned up and the BIO passed by the caller still retains
internal pointers to the previously freed filter BIO. If the caller then goes on
to call BIO_pop() on the BIO then a use-after-free will occur. This will most
likely result in a crash.
This scenario occurs directly in the internal function B64_write_ASN1() which
may cause BIO_new_NDEF() to be called and will subsequently call BIO_pop() on
the BIO. This internal function is in turn called by the public API functions
PEM_write_bio_ASN1_stream, PEM_write_bio_CMS_stream, PEM_write_bio_PKCS7_stream,
SMIME_write_ASN1, SMIME_write_CMS and SMIME_write_PKCS7.
Other public API functions that may be impacted by this include
i2d_ASN1_bio_stream, BIO_new_CMS, BIO_new_PKCS7, i2d_CMS_bio_stream and
i2d_PKCS7_bio_stream.
The OpenSSL cms and smime command line applications are similarly affected. |
