Vulnerabilidades

Resumen del problema: Un servidor CMP (Certificate Management Protocol) controlado por el atacante podría desencadenar una desreferencia de puntero NULL en una aplicación cliente CMP.<br /> <br /> Resumen del impacto: Una desreferencia de puntero NULL causa un fallo de la aplicación y una denegación de servicio.<br /> <br /> Un atacante que controla un servidor CMP (o actuando como un man-in-the-middle) podría elaborar una respuesta CMP que contiene un CertRepMessage CRMF (Certificate Request Message Format) con una estructura EncryptedValue donde el campo symmAlg tiene un OID de algoritmo pero no un campo de parámetros. Cuando el cliente CMP de OpenSSL procesa esta respuesta, la desreferencia NULL ocurre, causando un fallo del cliente CMP.<br /> <br /> Las aplicaciones que procesan mensajes CMP/CRMF no confiables pueden verse afectadas.<br /> <br /> Los módulos FIPS en 4.0, 3.6, 3.5, 3.4 y 3.0 no se ven afectados por este problema, ya que el código afectado está fuera del límite del módulo FIPS de OpenSSL.

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.<br /> <br /> 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.<br /> <br /> El ataque es posible en 2 variantes.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> Eso es un oráculo de Bleichenbacher (Bleichenbacher, CRYPTO &amp;#39;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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> Para evitar estos ataques, cuando el transporte de clave RSA PKCS#1 v1.5 está en uso, la función EVP_PKEY_decrypt() invocada utilizará el mecanismo de rechazo implícito descrito en draft-irtf-cfrg-rsa-guidance. En versiones anteriores de OpenSSL, el rechazo implícito estaba explícitamente deshabilitado.<br /> <br /> El mecanismo de rechazo implícito siempre devuelve un valor de texto plano, la clave simétrica. Este resultado es determinista para el texto cifrado y la clave privada. La longitud del resultado del descifrado puede coincidir con la longitud de la clave del cifrado simétrico que se utilizó para el cifrado del contenido. Cuando no se proporciona un certificado, se utilizará el último RecipientInfo que produzca una clave que parezca válida. Puede causar la obtención de contenido basura en el descifrado. Como una forma adecuada de lidiar con esto, se debe proporcionar un certificado de destinatario para identificar el RecipientInfo particular para el descifrado.<br /> <br /> Los módulos FIPS en 4.0, 3.6, 3.5 y 3.4 no se ven afectados por este problema, ya que el procesamiento de CMS y S/MIME ocurre fuera del límite del módulo FIPS de OpenSSL.

Resumen del Problema: Un error en la función de devolución de llamada utilizada para verificar el certificado proporcionado en una respuesta de mensaje del Protocolo de Gestión de Certificados (CMP) de actualización de clave de CA raíz hizo que la validación del certificado fuera ineficaz, lo que podría llevar a la escalada de credenciales del nivel de Autoridad de Registro (RA) al nivel de Autoridad de Certificación raíz (CA raíz).<br /> <br /> Resumen del Impacto: La Autoridad de Registro podría reemplazar el certificado de CA raíz para los clientes CMP con un certificado de CA raíz arbitrario.<br /> <br /> Una de las partes del Protocolo de Gestión de Certificados (CMP), especificado en RFC 9810, es la Sustitución de Clave de Autoridad de Certificación raíz (CA raíz), que es enviada por el servidor en un mensaje de tipo &amp;#39;id-it-rootCaKeyUpdate&amp;#39;. Como parte de estos mensajes, se proporciona el certificado &amp;#39;newWithOld&amp;#39;, el nuevo certificado de CA raíz firmado con la clave de CA raíz antigua, y verificar su firma es crucial para transferir la confianza de la clave de CA antigua a la nueva.<br /> <br /> Se espera que los mensajes &amp;#39;id-it-rootCaKeyUpdate&amp;#39; sean procesados con OSSL_CMP_get1_rootCaKeyUpdate(), que se espera que verifique el certificado &amp;#39;newWithOld&amp;#39;. Un error tipográfico en el código de construcción de la cadena de certificados llevó a añadir un certificado incorrecto (&amp;#39;newWithOld&amp;#39; en lugar de &amp;#39;oldRoot&amp;#39;) a la cadena de certificados, haciendo que el proceso de verificación del certificado fuera ineficaz (solo el nombre del emisor y los OID del algoritmo fueron verificados por otras partes del código de verificación).<br /> <br /> Un atacante que ya tiene credenciales que satisfacen las comprobaciones de protección de mensajes CMP puede generar un nuevo par de claves y usar un certificado autofirmado manipulado en sus mensajes CMP &amp;#39;id-it-rootCaKeyUpdate&amp;#39; que los clientes CMP afectados aceptarían como un nuevo ancla de confianza.<br /> <br /> Las precondiciones significativas para el ataque (tener credenciales válidas a nivel de RA) son la razón por la que el problema fue asignado con severidad Baja.<br /> <br /> Los módulos FIPS no se ven afectados por este problema, ya que el código afectado está fuera del límite del módulo FIPS de OpenSSL.

Resumen del problema: Cuando se llama a EVP_PKEY_derive_set_peer() con una clave de par DHX (X9.42), la clave de par no se verifica correctamente para la pertenencia al subgrupo.<br /> <br /> Resumen del impacto: Un par malicioso que presenta una clave X9.42 que contiene los parámetros p y g de la víctima, una q forjada = r (un pequeño factor primo del cofactor (p?1)/q_local), y un valor público Y de orden r puede recuperar la clave privada de la víctima después de un pequeño número de intentos de intercambio de claves.<br /> <br /> Cuando se llama a EVP_PKEY_derive_set_peer() con una clave de par DHX (X9.42), la verificación de pertenencia al subgrupo Y^q ? 1 (mod p) se realiza utilizando el propio parámetro q del par, no la q de la clave local. Los parámetros de dominio del par se comparan entonces con los parámetros de dominio de la clave privada, pero el valor de q no se compara.<br /> <br /> Un par malicioso que presenta una clave X9.42 que contiene la p, g de la víctima, una q forjada = r (un pequeño factor primo del cofactor), y un valor público Y de orden r pasa todas las verificaciones. El secreto compartido toma entonces solo r valores distintos, filtrando priv mod r. Repitiendo para cada factor primo pequeño del cofactor y combinando mediante CRT se recupera la clave privada completa (ataque Lim-Lee / de confinamiento de subgrupo pequeño).<br /> <br /> La superficie de ataque realista es estrecha: principalmente despliegues de CMP con claves DHX de RA/CA de larga duración y aplicaciones empresariales o gubernamentales a medida que utilizan claves estáticas DHX X9.42 con protocolos interactivos y, por lo tanto, a este problema se le asignó una severidad Baja.<br /> <br /> Los módulos FIPS en 4.0, 3.6, 3.5, 3.4 y 3.0 se ven afectados por este problema.

Resumen del problema: Cuando una aplicación llama a X509_VERIFY_PARAM_set1_email para validar una dirección de correo electrónico manipulada, como durante la validación de mensajes S/MIME, puede ocurrir una lectura fuera de límites.<br /> <br /> Resumen del impacto: Esta lectura fuera de límites no exfiltrará directamente los datos leídos al atacante, por lo que el resultado más probable es un fallo y una denegación de servicio.<br /> <br /> Una función auxiliar interna llamada desde X509_VERIFY_PARAM_[set|add]_email() utilizó una longitud incorrecta al validar la parte local de una dirección de correo electrónico. Esto podría causar que no se aplicara el límite de 64 octetos en la parte local de una dirección de correo electrónico, o causar una lectura fuera de límites y potencialmente un fallo.<br /> <br /> El error es alcanzable a través de la validación S-MIME con una dirección From: manipulada proporcionada en un mensaje de correo electrónico que puede causar potencialmente un fallo.<br /> <br /> Ningún módulo FIPS se ve afectado por este problema, ya que el código afectado está fuera del límite del módulo FIPS de OpenSSL.

Lectura excesiva de búfer en el controlador de filtro del sistema de archivos proyectado de Windows permite a un atacante autorizado elevar privilegios localmente.

Svelte es un framework web orientado al rendimiento. Desde la versión 5.51.5 hasta antes de la versión 5.55.7, una expresión regular interna en el tiempo de ejecución de Svelte puede tardar un tiempo exponencial en probarse en . Este problema ha sido parcheado en la versión 5.55.7.

Svelte devalue es una biblioteca de JavaScript que serializa valores en cadenas cuando JSON.stringify no es suficiente para la tarea. Desde la versión 5.6.3 hasta antes de la versión 5.8.1, devalue.parse podría, debido a peculiaridades en algunos motores de JavaScript, ser inducido a asignar mucha más memoria de la necesaria al deserializar arrays dispersos, lo que lleva a un consumo excesivo de memoria. Este problema ha sido parcheado en la versión 5.8.1.

Svelte es un framework web orientado al rendimiento. Antes de la versión 5.55.7, Svelte era vulnerable a DOM clobbering de su estado interno del framework en elementos, lo que podría llevar a ataques XSS. Este problema ha sido parcheado en la versión 5.55.7.

Svelte es un framework web orientado al rendimiento. Antes de la versión 5.55.7, al usar la sintaxis de propagación (spread syntax) para renderizar atributos de datos no confiables, las propiedades de los gestores de eventos se incluyen en la salida HTML renderizada. Si una aplicación propaga datos controlados por el usuario o externos como atributos de elementos, un atacante puede inyectar gestores de eventos maliciosos que se ejecutan en los navegadores de las víctimas. Tenga en cuenta que esta vulnerabilidad solo se activa si el navegador del usuario tiene JavaScript habilitado, pero el mecanismo de hidratación de Svelte no alcanza el elemento vulnerable antes de que se dispare el evento. Este problema ha sido parcheado en la versión 5.55.7.

Resumen del problema: Recibir un paquete inicial QUIC con un token inválido puede desencadenar una desreferencia de puntero NULL en el servidor QUIC de OpenSSL con la validación de direcciones deshabilitada.<br /> <br /> Resumen del impacto: La desreferencia de puntero NULL típicamente causa la terminación anormal del proceso del servidor QUIC afectado y una denegación de servicio.<br /> <br /> Si la validación de direcciones está deshabilitada en la implementación del servidor QUIC de OpenSSL, un atacante puede bloquear el servidor enviando un paquete inicial con un token inválido o caducado.<br /> <br /> Por defecto, la validación de direcciones del cliente está habilitada en la implementación del servidor QUIC de OpenSSL, lo que hace que la configuración predeterminada no sea vulnerable a este problema. Sin embargo, si se utiliza SSL_LISTENER_FLAG_NO_VALIDATE con la llamada a SSL_new_listener(), la validación de direcciones se deshabilita, haciendo que el código vulnerable sea accesible.<br /> <br /> Los módulos FIPS en 4.0, 3.6, 3.5, 3.4 y 3.0 no se ven afectados por este problema, ya que el código afectado está fuera del límite del módulo FIPS de OpenSSL.

Resumen del problema: Cuando la verificación de certificado de cadena parcial está habilitada junto con la comprobación de respuesta OCSP para toda la cadena, ocurrirá una desreferencia de NULL si la cadena verificada no tiene un ancla de confianza autofirmada, bloqueando el proceso.<br /> <br /> Resumen del impacto: Una desreferencia de puntero NULL puede desencadenar un bloqueo que lleva a una Denegación de Servicio para una aplicación.<br /> <br /> Al realizar la comprobación de respuesta OCSP para certificados en la cadena de verificación, el código siempre intenta acceder al siguiente certificado como emisor. Hay una comprobación para un certificado autofirmado. Sin embargo, con la verificación de cadena parcial habilitada, cuando la cadena no tiene un ancla de confianza autofirmada, el emisor será NULL para el último certificado de la cadena. Entonces ocurre una desreferencia de puntero NULL.<br /> <br /> Este problema afecta solo a las aplicaciones que habilitan tanto la verificación OCSP de la cadena de certificados (X509_V_FLAG_OCSP_RESP_CHECK_ALL) como la verificación de cadena parcial (X509_V_FLAG_PARTIAL_CHAIN) en la verificación de certificados. Ambas banderas están deshabilitadas por defecto. Por esa razón, hemos asignado una severidad Baja al problema.<br /> <br /> Ningún módulo FIPS se ve afectado por este problema ya que el código afectado está fuera del límite del módulo FIPS de OpenSSL.