You are viewing this page in an unauthorized frame window.
This is a potential security issue, you are being redirected to
https://nvd.nist.gov
An official website of the United States government
Official websites use .gov
A .gov website belongs to an official government organization in the United States.
Secure .gov websites use HTTPS
A lock () or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.
Issue summary: The CMS_decrypt and PKCS7_decrypt functions are vulnerable to
Bleichenbacher-style attack when an attacker is able to provide the CMS or
S/MIME messages and observe the error code and/or decryption output.
Impact summary: The Bleichenbacher-style attack allows an attacker to use the
victim's vulnerable application as a way to decrypt or sign messages with the
victim's private RSA key.
The attack is possible in 2 variants.
1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used without
providing the recipient certificate. In this case OpenSSL iterates over every
KeyTransRecipientInfo (KTRI) without stopping at the first success.
An attacker who authors a message with two KTRI entries — the first one
wrapping a real CEK under the victim's public key, the second with an
arbitrary probe ciphertext — obtains opportunity to iterate the 2nd KTRI to
get a valid PKCS#1 v1.5 padding if the error code of the application is
available.
That is a Bleichenbacher oracle (Bleichenbacher, CRYPTO '98): an
adaptive-chosen-ciphertext side channel from which the attacker decrypts any
RSA ciphertext to the victim's key or forges any PKCS#1 v1.5 signature under
it.
2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is provided with
the recipient certificate, and the recipient is not found, a random
key is substituted.
An attacker who authors a message and is able to compare both error code and
the result of the decryption, can mount a Bleichenbacher oracle.
We are not aware of any applications that provide a remote attacker
an opportunity to mount an attack described in these scenarios. We consider
the existence of such application very unlikely, and for this reason this
CVE has been evaluated as Low severity.
To avoid these attacks, when RSA PKCS#1 v1.5 Key Transport is in use, the
invoked EVP_PKEY_decrypt() will use the implicit rejection mechanism described
in draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicit
rejection was explicitly disabled.
The implicit rejection mechanism always returns a plaintext value,
the symmetric key. This result is deterministic for the ciphertext and the
private key. The length of the decryption result can happen to match the
length of the key of the symmetric cipher that was used for the content
encryption. When a certificate is not provided, the last RecipientInfo
producing a key that looks valid will be used. It may cause getting garbage
content on decryption. As a proper way to deal with this a recipient
certificate has to be provided to identify the particular RecipientInfo for
decryption.
The FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected by this issue, as
CMS and S/MIME processing happens outside the OpenSSL FIPS module boundary.
Metrics
NVD enrichment efforts reference publicly available information to associate
vector strings. CVSS information contributed by other sources is also
displayed.
By selecting these links, you will be leaving NIST webspace.
We have provided these links to other web sites because they
may have information that would be of interest to you. No
inferences should be drawn on account of other sites being
referenced, or not, from this page. There may be other web
sites that are more appropriate for your purpose. NIST does
not necessarily endorse the views expressed, or concur with
the facts presented on these sites. Further, NIST does not
endorse any commercial products that may be mentioned on
these sites. Please address comments about this page to [email protected].
Title: OpenSSL, Description: Resumen del problema: Las funciones CMS_decrypt y PKCS7_decrypt son vulnerables a un ataque de estilo Bleichenbacher cuando un atacante es capaz de proporcionar los mensajes CMS o S/MIME y observar el código de error y/o la salida del descifrado.
Resumen del impacto: El ataque de estilo Bleichenbacher permite a un atacante usar la aplicación vulnerable de la víctima como una forma de descifrar o firmar mensajes con la clave RSA privada de la víctima.
El ataque es posible en 2 variantes.
1. La API de descifrado (CMS_decrypt(), PKCS7_decrypt()) se utiliza sin proporcionar el certificado del destinatario. En este caso, OpenSSL itera sobre cada KeyTransRecipientInfo (KTRI) sin detenerse en el primer éxito.
Un atacante que crea un mensaje con dos entradas KTRI - la primera envolviendo una CEK real bajo la clave pública de la víctima, la segunda con un texto cifrado de sondeo arbitrario - obtiene la oportunidad de iterar la segunda KTRI para obtener un relleno PKCS#1 v1.5 válido si el código de error de la aplicación está disponible.
Eso es un oráculo de Bleichenbacher (Bleichenbacher, CRYPTO '98): un canal lateral de texto cifrado elegido adaptativo desde el cual el atacante descifra cualquier texto cifrado RSA a la clave de la víctima o falsifica cualquier firma PKCS#1 v1.5 bajo ella.
2. Cuando la API de descifrado (CMS_decrypt(), PKCS7_decrypt()) se proporciona con el certificado del destinatario, y el destinatario no se encuentra, se sustituye una clave aleatoria.
Un atacante que crea un mensaje y es capaz de comparar tanto el código de error como el resultado del descifrado, puede montar un oráculo de Bleichenbacher.
No tenemos conocimiento de ninguna aplicación que proporcione a un atacante remoto la oportunidad de montar un ataque descrito en estos escenarios. Consideramos muy improbable la existencia de dicha aplicación, y por esta razón este CVE ha sido evaluado como de severidad Baja.
Para evitar estos ataques, cuando el transporte de clave RSA PKCS#1 v1.5 está en uso, la
OR
*cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:* versions from (including) 3.4.0 up to (excluding) 3.4.6
*cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:* versions from (including) 3.5.0 up to (excluding) 3.5.7
*cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:* versions from (including) 3.6.0 up to (excluding) 3.6.3
*cpe:2.3:a:openssl:openssl:4.0.0:-:*:*:*:*:*:*
Issue summary: The CMS_decrypt and PKCS7_decrypt functions are vulnerable to
Bleichenbacher-style attack when an attacker is able to provide the CMS or
S/MIME messages and observe the error code and/or decryption output.
Impact summary: The Bleichenbacher-style attack allows an attacker to use the
victim's vulnerable application as a way to decrypt or sign messages with the
victim's private RSA key.
The attack is possible in 2 variants.
1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used without
providing the recipient certificate. In this case OpenSSL iterates over every
KeyTransRecipientInfo (KTRI) without stopping at the first success.
An attacker who authors a message with two KTRI entries — the first one
wrapping a real CEK under the victim's public key, the second with an
arbitrary probe ciphertext — obtains opportunity to iterate the 2nd KTRI to
get a valid PKCS#1 v1.5 padding if the error code of the application is
available.
That is a Bleichenbacher oracle (Bleichenbacher, CRYPTO '98): an
adaptive-chosen-ciphertext side channel from which the attacker decrypts any
RSA ciphertext to the victim's key or forges any PKCS#1 v1.5 signature under
it.
2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is provided with
the recipient certificate, and the recipient is not found, a random
key is substituted.
An attacker who authors a message and is able to compare both error code and
the result of the decryption, can mount a Bleichenbacher oracle.
We are not aware of any applications that provide a remote attacker
an opportunity to mount an attack described in these scenarios. We consider
the existence of such application very unlikely, and for this reason this
CVE has been evaluated as Low severity.
To avoid these attacks, when RSA PKCS#1 v1.5 Key Transport is in use, the
invoked EVP_PKEY_decrypt() will use the implicit rejection mechanism described
in draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicit
rejection was explicitly disabled.
The implicit rejection mecha