Viktor Dukhovni

Processing a certificate containing numerous `nameRelativeToCRLIssuer` CRL distribution points can cause disproportionate heap growth when X.509 extensions are cached. A malicious peer can send a crafted certificate that, while remaining under the accepted size limit of approximately 100 KiB, triggers the allocation of several hundred MiB of resident memory during a standard TLS handshake. This excessive memory allocation can lead to significant memory pressure and a potential Denial of Service, potentially crashing the client or server if multiple concurrent connections occur.

SM2 signature generation uses non-constant-time arithmetic on secret values, creating a timing side-channel. The process computes the signature value using variable-time BIGNUM operations on the private key and the secret nonce, meaning the time required to produce a signature depends on these secret values. An attacker capable of measuring signing times may obtain information about the per-signature secret nonce, which could lead to the recovery of the private key through a lattice or Hidden Number Problem attack.

A NULL pointer dereference can occur in server or client configurations where RFC7250 Raw Public Keys (RPKs) are enabled and only a private key is configured locally without an associated certificate. This happens when a remote peer requests raw public keys and includes the `signature algorithms cert` TLS extension. This issue can lead to a Denial of Service (DoS) due to an application abort. A NULL pointer dereference is a software error where the program attempts to read or write to a memory address that is NULL, typically causing the application to crash.

When using the AES-OCB cipher with the one-shot `EVP Cipher()` interface, the application-supplied initialisation vector (IV) is silently discarded. This causes every message encrypted with the same key to use the same effective nonce, leading to (key, nonce) reuse and a loss of confidentiality. If the same path is used to compute the authentication tag, the tag depends only on the (key, IV) pair rather than the plaintext or ciphertext, which allows for universal forgery of arbitrary ciphertext from a single captured message. This occurs because the one-shot handler fails to flush the IV into the OCB context, unlike the streaming handler. If `EVP EncryptFinal ex()` is later used to obtain the authentication tag, the deferred IV setup clears the running checksum that should have been accumulated over the plaintext.

When the `EVP PKEY derive set peer()` function is called with a DHX (X9.42) peer key, the software fails to properly verify subgroup membership. Specifically, the check `Y^q ≡ 1 (mod p)` is performed using the `q` parameter provided by the peer instead of the local key's `q` parameter. While other domain parameters are matched against the private key, the `q` value is not compared. This allows a malicious peer to present an X9.42 key with the victim's `p` and `g` parameters, a forged `q` equal to `r` (a small prime factor of the cofactor `(p−1)/q local`), and a public value `Y` of order `r`. This bypasses checks and results in a shared secret with only `r` distinct values, leaking the private key modulo `r`. By repeating this process for each small-prime factor of the cofactor and combining the results via the Chinese Remainder Theorem (CRT), an attacker can recover the full private key. This is known as a Lim–Lee or small-subgroup-confinement attack.

An uncommon configuration of clients performing DANE TLSA-based server authentication, when paired with uncommon server DANE TLSA records, may result in a use-after-free and/or double-free on the client side. A use after free can lead to data corruption, crashes, or arbitrary code execution. The issue affects clients that use TLSA records with both PKIX-TA(0/PKIX-EE(1)) and DANE-TA(2) certificate usages. Clients that treat PKIX TLSA records as unusable or support only PKIX usages are not vulnerable. The client must also communicate with a server publishing a TLSA RRset with both types of TLSA records.

A signed integer overflow occurs when sizing the destination buffer for Unicode output in the `ASN1 mbstring ncopy()` function, which can lead to a heap buffer overflow. This happens in `ASN1 mbstring copy()` and `ASN1 mbstring ncopy()` because the destination size for Unicode output is computed as a signed integer. Specifically, the calculation overflows when the input reaches approximately 2^30 characters through a left shift of the input character count for BMPSTRING (UTF-16) and UNIVERSALSTRING (UTF-32), or by summing per-character byte counts for UTF8STRING. In the worst-case scenario involving UNIVERSALSTRING at 2^30 characters, the size wraps to zero, resulting in a minimal allocation that is subsequently overwritten by several gigabytes of data. This may lead to a crash, undefined behavior, or attacker-controlled code execution. Triggering this issue requires an application to call `ASN1 mbstring copy()` or `ASN1 mbstring ncopy()` directly, or register a custom string type via `ASN1 STRING TABLE add()` with attacker-controlled input of half a gigabyte or more.

An integer truncation in the ASN.1 decoder occurs when parsing a crafted DER-encoded ASN.1 structure with a primitive element exceeding 2 gigabytes in length. This issue specifically affects 64-bit Unix and Unix-like platforms. The truncated length may be treated as a request to scan binary content for a terminating zero byte, leading to a heap buffer over-read. This can result in a Denial of Service by crashing the application or cause memory beyond the input buffer to be loaded into the decoded ASN.1 object. Applications that pass attacker-supplied data to decoding functions such as "d2i X509()", "d2i PKCS7()", or any other "d2i *" functions are affected.

An issue exists in OpenSSL TLS 1.3 servers where the server may fail to negotiate the expected preferred key exchange group when its key exchange group configuration includes the default by using the 'DEFAULT' keyword. This can result in a less preferred key exchange being used, even when a more secure group is supported by both the client and server, if the preferred group was not included in the client's initial keyshare predictions. This is particularly relevant with new hybrid post-quantum groups, where the client might defer their use until specifically requested by the server. The root cause is an implementation defect that causes the 'DEFAULT' list to lose its 'tuple' structure, treating all server-supported groups as a single sufficiently secure tuple, and preventing the server from sending a Hello Retry Request (HRR) when a more preferred group is mutually supported. The issue does not affect OpenSSL FIPS modules.

OpenSSL contains vulnerabilities due to out-of-bounds read and write issues. Specifically, an out-of-bounds read and write can occur when decrypting CMS messages encrypted using password-based encryption, potentially leading to a crash or memory corruption. Additionally, an out-of-bounds read can occur in the HTTP client API functions when the 'no proxy' environment variable is set and the host portion of the authority component of the HTTP URL is an IPv6 address. The FIPS modules in OpenSSL versions 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected.

Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a server may fail to detect that the server was not authenticated. This occurs because TLS and DTLS handshakes do not abort as expected when the `SSL VERIFY PEER` verification mode is set. This issue can lead to man-in-the-middle attacks if the client relies on the handshake failure to identify an authentication mismatch. RPKs are disabled by default; the issue only manifests when clients explicitly enable RPK use and the server sends an RPK instead of an X.509 certificate chain. Clients that verify the result by calling the `SSL get verify result()` function and take appropriate action are not affected. FIPS modules in versions 3.0 through 3.4 are not impacted.

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. This can lead a user to believe an entire file is authenticated when trailing data beyond 16MB remains unauthenticated. The issue affects only the command-line tool behavior and does not impact verifiers that process the full message using library APIs. Streaming digest algorithms for 'openssl dgst' and library users are also unaffected. The issue occurs when using one-shot signing algorithms such as Ed25519, Ed448, or ML-DSA. The tool truncates the input to the first 16MB and continues without signaling an error, creating 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 is related to a denial of service in X.509 name checks. Applications performing certificate name checks, such as TLS clients checking server certificates, may attempt to read an invalid memory address when comparing the expected name with an `otherName` subject alternative name of an X.509 certificate. This may result in an exception that terminates the application program. Basic certificate chain validation is not affected, and the denial of service can occur only when the application also specifies an expected DNS name, Email address, or IP address. TLS servers are generally not affected, and the severity of the issue is Moderate.

Name of the Vulnerable Software and Affected Versions: OpenSSL versions prior to 3.3.3 Description: The issue arises from the use of low-level GF(2^m) elliptic curve APIs with untrusted explicit values for the field polynomial, leading to out-of-bounds memory reads or writes. This can cause an application crash or potentially allow for remote code execution. However, the likelihood of a vulnerable application is low, as most protocols involving Elliptic Curve Cryptography either support only "named curves" or specify an X9.62 encoding of binary (GF(2^m)) curves that cannot represent problematic input values. The affected APIs include `EC GROUP new curve GF2m()`, `EC GROUP new from params()`, and various supporting `BN GF2m *()` functions. Recommendations: For versions prior to 3.3.3, update to version 3.3.3 or later to resolve the issue. As a temporary workaround, consider restricting the use of the vulnerable `EC GROUP new curve GF2m()` and `EC GROUP new from params()` functions, as well as the supporting `BN GF2m *()` functions, until a patch is available. Avoid using "exotic" explicit binary (GF(2^m)) curve parameters that can represent invalid field polynomials with a zero constant term.

A read buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. 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. The read buffer overrun might result in a crash, which could lead to a denial of service attack. In theory, it could also result in the disclosure of private memory contents, such as private keys or sensitive plaintext, although no working exploit leading to memory contents disclosure is known at the time of release of this advisory. 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.

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

A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. 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.

The issue is related to the ` krb5 extract ticket()` function, which obtains service-principal names in a way that violates the Kerberos 5 protocol specification. This allows remote attackers to impersonate services with Orpheus' Lyre attacks. The problem arises because the function uses the unencrypted version of the service name stored in `ticket` instead of the encrypted version stored in `enc part`. This provides an opportunity for successful server impersonation and other attacks.

A security-feature bypass issue allows attackers to affect the system. This issue is related to Kerberos failing to prevent tampering with the SNAME field during ticket exchange.

The issue is related to the lack of protection for internal data in the Tcl component of the operating system. It can be exploited by a remote attacker to obtain sensitive information by leveraging SSLv2 support.