Vulnerabilities

Out-of-bounds write in Windows Hotpatch Monitoring Service allows an authorized attacker to elevate privileges locally.

Improper access control in Windows Administrator Protection allows an authorized attacker to bypass a security feature locally.

Improper neutralization of special elements in output used by a downstream component ('injection') in Microsoft Teams for Android allows an authorized attacker to disclose information over a network.

Concurrent execution using shared resource with improper synchronization ('race condition') in Function Discovery Service (fdwsd.dll) allows an authorized attacker to elevate privileges locally.

Out-of-bounds read in Windows Projected File System Filter Driver allows an authorized attacker to elevate privileges locally.

Improper authorization in Microsoft PowerToys allows an authorized attacker to elevate privileges locally.

Null pointer dereference in Windows Kerberos allows an authorized attacker to deny service over a network.

Heap-based buffer overflow in Windows TCP/IP allows an unauthorized attacker to elevate privileges over an adjacent network.

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.