Llegamos a ustedes gracias a:



Alertas de Seguridad

El proyecto OpenSSL parchea dos vulnerabilidades

Pero rebaja su gravedad

[02/11/2022] El proyecto OpenSSL ha publicado un parche para dos vulnerabilidades de alta gravedad en la biblioteca criptográfica más utilizada del mundo. Los responsables del proyecto advirtieron a los usuarios desde la semana pasada que se prepararan para un parche crítico el 1 de noviembre, pero la gravedad se ha rebajado desde entonces tras la realización de pruebas adicionales.

Las organizaciones deben determinar cuáles de sus aplicaciones y servidores están afectados, y desplegar los parches lo antes posible. Las vulnerabilidades afectan a todas las versiones de OpenSSL 3.0, que está disponible desde el año pasado.

Desbordamientos de búfer en la verificación de certificados X.509

Las dos vulnerabilidades, rastreadas como CVE-2022-3786 y CVE-2022-3602, son condiciones de desbordamiento de búfer en la funcionalidad de decodificación de punycode, que se introdujo por primera vez en OpenSSL 3.0.0 en septiembre del 2021. Punycode es un sistema para representar caracteres Unicode como ASCII y se utiliza, por ejemplo, para representar nombres de dominio internacionalizados en el sistema DNS. En OpenSSL, el código vulnerable se utiliza para procesar las restricciones de los nombres de las direcciones de correo electrónico en los certificados X.509, también conocidos comúnmente como certificados SSL/TLS.

"Cualquier aplicación de OpenSSL 3.0 que verifique certificados X.509 recibidos de fuentes no confiables debe considerarse vulnerable", dijeron los mantenedores de OpenSSL en un aviso. "Esto incluye a los clientes TLS y a los servidores TLS que están configurados para utilizar la autenticación de clientes TLS".

Los protocolos de comunicación encriptada más utilizados, como HTTPS, dependen de que los clientes, como los navegadores o las aplicaciones, comprueben la identidad de los servidores a los que se conectan validando sus certificados. En este escenario, una aplicación tendría que conectarse a un servidor que presentara un certificado malicioso para que se pudiera explotar cualquiera de estas vulnerabilidades. Un atacante también podría forzar esta condición con un ataque de tipo "man-in-the-middle" (MitM), en el que podría interponerse entre la aplicación y el servidor y secuestrar las peticiones de la aplicación.

En los casos en que los servidores están configurados para utilizar la autenticación del cliente, lo que significa que el servidor también valida la identidad del cliente mediante la comprobación de un certificado que presentan, los servidores también serían vulnerables.

Una falla de OpenSSL rebajado de crítico a de alta gravedad

El proyecto OpenSSL no utiliza el sistema de puntuación de vulnerabilidades CVSS. En su lugar, tiene su propio sistema de clasificación de gravedad descrito en su política de seguridad. Según esta política, los problemas críticos son aquellos que afectan a "configuraciones comunes y que además es probable que se puedan explotar". Algunos ejemplos son la divulgación significativa del contenido de la memoria del servidor (que puede revelar detalles del usuario), vulnerabilidades que pueden ser fácilmente explotadas de forma remota para comprometer las claves privadas del servidor, o cuando la ejecución remota de código se considera probable en situaciones comunes".

Los desbordamientos de búfer pueden dar lugar, en teoría, a la ejecución remota de código, pero esto depende en gran medida de las condiciones necesarias para desencadenarla y de las diversas mitigaciones utilizadas en una plataforma o sistema concreto.

Inicialmente, los mantenedores consideraron la CVE-2022-3602 como crítica porque es un desbordamiento de pila de 4 bytes, y la CVE-2022-3786 como de alta gravedad porque el atacante no puede controlar el contenido de la sobreescritura. Sin embargo, tras nuevas discusiones y pruebas realizadas junto con las organizaciones a las que se notificaron previamente los detalles de la vulnerabilidad -incluidos los proveedores de sistemas operativos de uso general que incluyen OpenSSL, como las distribuciones de Linux- se revisó la gravedad.

"En primer lugar, teníamos informes de que en ciertas distribuciones de Linux la disposición de la pila era tal que los 4 bytes sobrescribían un búfer adyacente que aún no se había utilizado y, por lo tanto, no se producía una falla o la posibilidad de causar la ejecución remota de código", dijo el proyecto en su aviso. "En segundo lugar, muchas plataformas modernas implementan protecciones contra el desbordamiento de pila que mitigarían el riesgo de ejecución remota de código y, en cambio, suelen provocar una falla".

Eso no significa que no haya situaciones, configuraciones y plataformas en las que la falla pueda conducir fácilmente a la ejecución remota de código. OpenSSL se distribuye como código y puede ejecutarse en una gran variedad de plataformas, incluidos los sistemas integrados. Las aplicaciones también pueden empaquetarlo directamente y enlazarlo de forma estática, o pueden utilizar la biblioteca incluida por el sistema operativo, si éste la empaqueta. Sin embargo, los responsables de su mantenimiento consideraron que sus criterios de "configuraciones comunes y que también son susceptibles de ser explotadas" para los problemas críticos ya no se cumplían con esta vulnerabilidad.

OpenSSL 3.0 aún no tiene una amplia adopción

En el lado del servidor, la adopción de OpenSSL 3.0 todavía no es muy alta. Según Censys, una empresa que escanea todo el espacio IP de Internet y recopila información sobre los servicios en funcionamiento, casi 1,8 millones de hosts únicos en Internet tienen uno o más servicios que utilizan OpenSSL. Solo unos 7.000 (0,4%) de ellos ejecutan una versión de OpenSSL superior o igual a la 3.0.0. Además, de los que ejecutan OpenSSL 3.0, sólo un subconjunto probablemente realiza la autenticación del lado del cliente y sería vulnerable.

Por supuesto, esta telemetría solo cubre los servidores accesibles desde Internet y no los de las redes internas, que también podrían ser fácilmente alcanzables por los atacantes que consigan entrar en una red. La empresa de seguridad y de la nube Akamai realizó sus propios escaneos en las redes de sus clientes, y encontró que alrededor de la mitad de ellos tenían al menos una máquina con al menos un proceso que utilizaba una versión vulnerable de OpenSSL. El porcentaje de máquinas que utilizaban una versión vulnerable de OpenSSL en esas redes oscilaba entre el 0,2% y el 33%, con una media del 6,1%.

Dado que es más probable que estas vulnerabilidades se puedan explotar en los clientes que en los servidores, es mucho más difícil determinar la magnitud del impacto cuando se trata de aplicaciones cliente que utilizan OpenSSL para conectarse a los servidores. Esto puede considerarse una vulnerabilidad transitiva -vulnerabilidades heredadas de las dependencias de software de terceros- para muchas aplicaciones y éstas pueden ser muy difíciles de rastrear para las organizaciones hasta que esfuerzos como la lista de materiales de software (SBOM) vean una adopción más amplia en la industria.

Afortunadamente, un factor limitante importante para este exploit es que solo puede ocurrir después de que el emisor del certificado haya sido validado. Esto significa que, en la mayoría de los casos, si la validación de certificados se aplica correctamente, los atacantes tendrían que obtener un certificado malicioso de una autoridad de certificación (CA) de confianza.

"Mientras que las fallas de desbordamiento de memoria pueden llevar a los peores escenarios, los detalles de esta vulnerabilidad en particular parecen indicar que el nivel de dificultad para un exploit es muy alto", sostuvo Brian Fox, CTO de la firma de seguridad de la cadena de suministro de software Sonatype, a CSO por correo electrónico. "La vulnerabilidad requiere un certificado malformado que sea de confianza o esté firmado por una autoridad de nombres. Eso significa que las autoridades deberían ser capaces de impedir rápidamente que se creen certificados diseñados para atacar esta vulnerabilidad, limitando aún más el alcance".

Red Hat ha publicado un aviso y ha lanzado parches de OpenSSL para Red Hat Enterprise Linux 9. La compañía califica el impacto de las fallas como Importante y dice que ni SELinux ni Kpatch los mitigan.

Las organizaciones deben actualizar inmediatamente OpenSSL en sus sistemas o en sus aplicaciones a la versión 3.0.7 publicada el martes. El proyecto también publicó al mismo tiempo la versión 1.1.1 de OpenSSL, pero se trata de una versión de corrección de errores que no está relacionada con estas vulnerabilidades. La rama OpenSSL 1.1.x no está afectada y sigue siendo compatible hasta septiembre del 2023, pero los responsables del proyecto aconsejan a los desarrolladores de aplicaciones que utilicen siempre la última versión en sus aplicaciones, es decir, la 3.0.7 en este momento.