Vulnerabilities

Issue summary: An attacker-controlled CMP (Certificate Management Protocol)<br /> server could trigger a NULL pointer dereference in a CMP client application.<br /> <br /> Impact summary: A NULL pointer dereference causes a crash of the<br /> application and a Denial of Service.<br /> <br /> An attacker controlling a CMP server (or acting as a man-in-the-middle) could<br /> craft a CMP response containing a CRMF (Certificate Request Message Format)<br /> CertRepMessage with an EncryptedValue structure where the symmAlg field<br /> has an algorithm OID but no parameters field. When the OpenSSL CMP client<br /> processes this response, the NULL dereference occurs, causing a crash of<br /> the CMP client.<br /> <br /> Applications that process untrusted CMP/CRMF messages may be affected.<br /> <br /> The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this<br /> issue, as the affected code is outside the OpenSSL FIPS module boundary.

Issue summary: The CMS_decrypt and PKCS7_decrypt functions are vulnerable to<br /> Bleichenbacher-style attack when an attacker is able to provide the CMS or<br /> S/MIME messages and observe the error code and/or decryption output.<br /> <br /> Impact summary: The Bleichenbacher-style attack allows an attacker to use the<br /> victim&amp;#39;s vulnerable application as a way to decrypt or sign messages with the<br /> victim&amp;#39;s private RSA key.<br /> <br /> The attack is possible in 2 variants.<br /> <br /> 1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used without<br /> providing the recipient certificate. In this case OpenSSL iterates over every<br /> KeyTransRecipientInfo (KTRI) without stopping at the first success.<br /> <br /> An attacker who authors a message with two KTRI entries — the first one<br /> wrapping a real CEK under the victim&amp;#39;s public key, the second with an<br /> arbitrary probe ciphertext — obtains opportunity to iterate the 2nd KTRI to<br /> get a valid PKCS#1 v1.5 padding if the error code of the application is<br /> available.<br /> <br /> That is a Bleichenbacher oracle (Bleichenbacher, CRYPTO &amp;#39;98): an<br /> adaptive-chosen-ciphertext side channel from which the attacker decrypts any<br /> RSA ciphertext to the victim&amp;#39;s key or forges any PKCS#1 v1.5 signature under<br /> it.<br /> <br /> 2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is provided with<br /> the recipient certificate, and the recipient is not found, a random<br /> key is substituted.<br /> <br /> An attacker who authors a message and is able to compare both error code and<br /> the result of the decryption, can mount a Bleichenbacher oracle.<br /> <br /> We are not aware of any applications that provide a remote attacker<br /> an opportunity to mount an attack described in these scenarios. We consider<br /> the existence of such application very unlikely, and for this reason this<br /> CVE has been evaluated as Low severity.<br /> <br /> To avoid these attacks, when RSA PKCS#1 v1.5 Key Transport is in use, the<br /> invoked EVP_PKEY_decrypt() will use the implicit rejection mechanism described<br /> in draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicit<br /> rejection was explicitly disabled.<br /> <br /> The implicit rejection mechanism always returns a plaintext value,<br /> the symmetric key. This result is deterministic for the ciphertext and the<br /> private key. The length of the decryption result can happen to match the<br /> length of the key of the symmetric cipher that was used for the content<br /> encryption. When a certificate is not provided, the last RecipientInfo<br /> producing a key that looks valid will be used. It may cause getting garbage<br /> content on decryption. As a proper way to deal with this a recipient<br /> certificate has to be provided to identify the particular RecipientInfo for<br /> decryption.<br /> <br /> The FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected by this issue, as<br /> CMS and S/MIME processing happens outside the OpenSSL FIPS module boundary.

Issue Summary: An error in the callback used to verify the certificate<br /> provided in a Root CA key update Certificate Management Protocol (CMP)<br /> message response rendered the certificate validation ineffectual, which<br /> could lead to escalation of credentials from the Registration Authority (RA)<br /> level to the root Certification Authority (root CA) level.<br /> <br /> Impact Summary: The Registration Autority could replace the root CA<br /> certificate for the CMP clients with an arbitrary root CA certificate.<br /> <br /> One of the parts of the Certificate Management Protocol (CMP), specified in<br /> RFC 9810, is Root Certification Authority (root CA) key Rollover,<br /> which is sent by the server in a message with type &amp;#39;id-it-rootCaKeyUpdate&amp;#39;.<br /> As part of these messages, &amp;#39;newWithOld&amp;#39; certificate, the new root CA<br /> certificate signed with the old root CA key, is provided, and verifying its<br /> signature is crucial for transferring the trust from the old CA key to the<br /> new one.<br /> <br /> The &amp;#39;id-it-rootCaKeyUpdate&amp;#39; messages are expected to be processed with<br /> OSSL_CMP_get1_rootCaKeyUpdate(), that is expected to verify the &amp;#39;newWithOld&amp;#39;<br /> certificate. A typo in the certificate chain building code led to adding<br /> an incorrect certificate (&amp;#39;newWithOld&amp;#39; instead of &amp;#39;oldRoot&amp;#39;) to the<br /> certificate chain, rendering the certificate verification process ineffectual<br /> (only the issuer name and the algorithm OIDs were verified by other parts<br /> of the verification code).<br /> <br /> An attacker who already has credentials that satisfy the CMP message<br /> protection checks can generate a new key pair and use a crafted self-signed<br /> certificate in its &amp;#39;id-it-rootCaKeyUpdate&amp;#39; CMP messages which affected CMP<br /> clients would accept as a new trust anchor.<br /> <br /> Significant preconditions for the attack (having valid RA-level credentials)<br /> are the reason the issue was assigned Low severity.<br /> <br /> The FIPS modules are not affected by this issue, as the affected code is<br /> outside the OpenSSL FIPS module boundary.

Issue summary: When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42)<br /> peer key, the peer key is not properly checked for the subgroup membership.<br /> <br /> Impact summary: A malicious peer which presents an X9.42 key carrying the<br /> victim&amp;#39;s p and g parameters, a forged q = r (a small prime factor of the<br /> cofactor (p−1)/q_local), and a public value Y of order r can recover the<br /> victim&amp;#39;s private key after a small number of key exchange attempts.<br /> <br /> When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42) peer key, the<br /> subgroup membership check Y^q ≡ 1 (mod p) is performed using the peer&amp;#39;s<br /> own q parameter, not the local key&amp;#39;s q. The peer&amp;#39;s domain parameters are<br /> then matched against the domain parameters of the private key, but the value<br /> of q is not compared.<br /> <br /> A malicious peer who presents an X9.42 key carrying the victim&amp;#39;s p, g,<br /> a forged q = r (a small prime factor of the cofactor), and a public<br /> value Y of order r passes all checks. The shared secret then takes only<br /> r distinct values, leaking priv mod r. Repeating for each small-prime<br /> factor of the cofactor and combining via CRT recovers the full private<br /> key (Lim–Lee / small-subgroup-confinement attack).<br /> <br /> The realistic attack surface is narrow: principally CMP deployments with<br /> long-lived RA/CA DHX keys and bespoke enterprise or government applications<br /> using X9.42 DHX static keys with interactive protocols and therefore this<br /> issue was assigned Low severity.<br /> <br /> The FIPS modules in 4.0, 3.6, 3.5, 3.4, 3.1.2 and 3.0 are affected by this<br /> issue.

Issue summary: When the X509_VERIFY_PARAM_set1_email is called by an<br /> application to validate a crafted e-mail address, such as during S/MIME<br /> message validation, an out of bounds read can happen.<br /> <br /> Impact summary: This out of bounds read will not directly exfiltrate<br /> the data read to the attacker so the most likely result is a crash and<br /> a Denial of Service.<br /> <br /> An internal helper function called from X509_VERIFY_PARAM_[set|add]_email()<br /> used a wrong length when validating the local part of an email address.<br /> This could cause the 64 octet limit on the local part of an email address<br /> to be not enforced, or cause an out of bound read and potentially a crash.<br /> <br /> The bug is reachable via S-MIME validation with a crafted From: address<br /> supplied in an email message that can potentially cause a crash.<br /> <br /> No FIPS modules are affected by this issue as the affected code is outside<br /> the OpenSSL FIPS module boundary.

Buffer over-read in Windows Projected File System Filter Driver allows an authorized attacker to elevate privileges locally.

Svelte is a performance oriented web framework. From version 5.51.5 to before version 5.55.7, an internal regex in the Svelte runtime can take exponential time to test in . This issue has been patched in version 5.55.7.

Svelte devalue is a JavaScript library that serializes values into strings when JSON.stringify isn&amp;#39;t sufficient for the job. From version 5.6.3 to before version 5.8.1, devalue.parse could, due to quirks in some JavaScript engines, be convinced to allocate much more memory than was needed when deserializing sparse arrays, leading to excessive memory consumption. This issue has been patched in version 5.8.1.

Svelte is a performance oriented web framework. Prior to version 5.55.7, Svelte was vulnerable to DOM clobbering of its internal framework state on elements, potentially leading to XSS attacks. This issue has been patched in version 5.55.7.

Svelte is a performance oriented web framework. Prior to version 5.55.7, when using spread syntax to render attributes from untrusted data, event handler properties are included in the rendered HTML output. If an application spreads user-controlled or external data as element attributes, an attacker can inject malicious event handlers that execute in victims&amp;#39; browsers. Note that this vulnerability only triggers if the user&amp;#39;s browser has JavaScript enabled but Svelte&amp;#39;s hydration mechanism does not reach the vulnerable element before the event fires. This issue has been patched in version 5.55.7.

Issue summary: Receiving a QUIC initial packet with an invalid token may<br /> trigger a NULL pointer dereference in the OpenSSL QUIC server with<br /> address validation disabled.<br /> <br /> Impact summary: NULL pointer dereference typically causes abnormal termination<br /> of the affected QUIC server process and a Denial of Service.<br /> <br /> If the address validation is disabled in the OpenSSL QUIC server<br /> implementation, an attacker can crash the server by sending an initial<br /> packet with an invalid or expired token.<br /> <br /> By default, the client address validation is enabled in the OpenSSL QUIC server<br /> implementation, which makes the default configuration not vulnerable<br /> to this issue. However if the SSL_LISTENER_FLAG_NO_VALIDATE is used with<br /> the SSL_new_listener() call, the address validation is disabled making the<br /> vulnerable code reachable.<br /> <br /> The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this<br /> issue, as the affected code is outside the OpenSSL FIPS module boundary.

Issue summary: When a partial-chain certificate verification is enabled<br /> together with OCSP response checking for the whole chain, a NULL dereference<br /> will happen if the verified chain does not have a self-signed trusted anchor,<br /> crashing the process.<br /> <br /> Impact summary: A NULL pointer dereference can trigger a crash which leads to a<br /> Denial of Service for an application.<br /> <br /> When performing OCSP response checking for certificates in the verification<br /> chain, the code always tries to access the next certificate as the issuer.<br /> There is a check for a self-signed certificate. However with the partial<br /> chain verification enabled when the chain does not have a self-signed trusted<br /> anchor, the issuer will be NULL for the last certificate in the chain. A NULL<br /> pointer dereference then happens.<br /> <br /> This issue affects only applications which enable both OCSP verification<br /> of the certificate chain (X509_V_FLAG_OCSP_RESP_CHECK_ALL) and partial<br /> chain verification (X509_V_FLAG_PARTIAL_CHAIN) in the certificate<br /> verification. Both flags are disabled by default. For that reason, we have<br /> assigned Low severity to the issue.<br /> <br /> No FIPS modules are affected by this issue as the affected code is outside<br /> the OpenSSL FIPS module boundary.