OpenSSL 1.1.1 pasa a la versión 1.1.1s y corrige un error relacionado con la seguridad enumerado, pero este error no tiene una clasificación de seguridad ni un número CVE oficial.
Te recomendamos encarecidamente que actualices, pero la actualización CRÍTICA que habrás visto en los medios de ciberseguridad no aplica a esta versión.
OpenSSL 3.0 va a la versión 3.0.7 y parchea no uno sino dos errores de seguridad numerados por CVE que se describen oficialmente como de ALTA gravedad.
Le recomendamos encarecidamente que actualice, con la mayor urgencia posible, pero la solución CRÍTICA de la que todos han estado hablando ahora se ha degradado a ALTA gravedad.
Esto refleja la opinión del equipo de OpenSSL:
Los anuncios previos de CVE-2022-3602 describieron este problema como CRÍTICO. Un análisis posterior basado en algunos de los factores mitigantes descritos [en las notas de la versión] ha llevado a que esto se rebaje a ALTO. Todavía se recomienda a los usuarios que actualicen a una nueva versión lo antes posible.
Irónicamente, se descubrió un segundo error similar, denominado CVE-2022-3786 , mientras se preparaba la solución para CVE-2022-3602.
El error original solo permite que un atacante corrompa cuatro bytes en la pila, lo que limita la capacidad de explotación de la falla, mientras que el segundo error permite una cantidad arbitraria de desbordamiento de la pila, pero aparentemente solo con el carácter «punto» (ASCII 46 o 0x2E ) en cada byte desbordado.
Ambas vulnerabilidades quedan expuestas durante la verificación del certificado TLS, donde un cliente o servidor con trampa explosiva se «identifica» ante el servidor o cliente en el otro extremo con un certificado TLS deliberadamente malformado.
Aunque este tipo de desbordamiento de pila (uno de tamaño limitado y el otro de valores de datos limitados) suena como si fueran difíciles de explotar para la ejecución de código, especialmente en software de 64 bits, donde cuatro bytes son solo la mitad de una dirección de memoria…
… es casi seguro que se puedan explotar fácilmente para ataques de denegación de servicio (DoS), en los que el remitente de un certificado falso podría bloquear al destinatario de ese certificado a voluntad.
Afortunadamente, la mayoría de los intercambios TLS implican que los clientes verifiquen los certificados del servidor, y no al revés.
La mayoría de los servidores web, por ejemplo, no requieren que los visitantes se identifiquen con un certificado antes de permitirles leer el sitio, por lo que es probable que el «vector de bloqueo» de cualquier explotación funcional sea un servidor no autorizado que colapsa a los visitantes desafortunados, lo que generalmente se considera mucho menos grave que los servidores que se cuelgan cada vez que son visitados por un solo visitante deshonesto.
Sin embargo, cualquier técnica mediante la cual un servidor web o de correo electrónico pirateado pueda bloquear gratuitamente un navegador visitante o una aplicación de correo electrónico debe considerarse peligrosa, sobre todo porque cualquier intento del software del cliente de volver a intentar la conexión provocará que la aplicación se bloquee una y otra vez. otra vez.
Por lo tanto, definitivamente desea parchear esto tan pronto como pueda.
¿Qué hacer?
Como se mencionó anteriormente, necesita OpenSSL 1.1.1s o OpenSSL 3.0.7 para reemplazar cualquier versión que tenga en este momento.
OpenSSL 1.1.1s obtiene un parche de seguridad descrito como la corrección de «una regresión [un error antiguo que reapareció] introducido en OpenSSL 1.1.1r que no actualiza los datos del certificado para firmar antes de firmar el certificado» .
Este error en 1.1.1 no tiene asignada una gravedad o un CVE…
…pero no dejes que eso te desanime de actualizar tan pronto como puedas.
Sin embargo, OpenSSL 3.0.7 obtiene correcciones para las dos correcciones de ALTA gravedad numeradas con CVE enumeradas anteriormente, y aunque no suenan tan aterradoras ahora como lo hicieron en el festival de noticias que condujo a esta actualización, debe asumir que:
- Muchos atacantes descubrirán rápidamente cómo explotar estos agujeros para propósitos de DoS. Eso podría causar una interrupción del flujo de trabajo en el mejor de los casos y problemas de ciberseguridad en el peor, especialmente si se puede abusar del error para ralentizar o romper procesos automatizados importantes en su ecosistema de TI.
- Algunos atacantes pueden resolver estos errores para la ejecución remota de código. Esto daría a los delincuentes una buena oportunidad de usar servidores web con trampas explosivas para subvertir el software del cliente utilizado para transacciones seguras en su propio negocio.
- Si se encuentra una prueba de concepto (PoC), atraerá un gran interés. Como recordará de Log4Shell , tan pronto como se publicaron las PoC, miles de autoproclamados «investigadores» se subieron al carro de escanear Internet y atacar sobre la marcha con el pretexto de «ayudar» a las personas a encontrar problemas en sus redes.
OpenSSL 1.0.2, por el momento, sigue siendo compatible y actualizado, pero solo de forma privada, para los clientes que tienen contratos de pago con el equipo de OpenSSL.
Es por eso que no tenemos ninguna información para divulgar aquí sobre 1.0.2, aparte de confirmar que los errores numerados de CVE en OpenSSL 3.0 no están presentes en el código de OpenSSL 1.0.2.
Puede leer más y obtener sus actualizaciones de OpenSSL en el sitio web de OpenSSL .
Tenga en cuenta también que la biblioteca BoringSSL de Google, los servicios de seguridad de red (NSS) de Firefox y LibreSSL de OpenBSD , todos los cuales brindan una funcionalidad similar a OpenSSL (y en el caso de LibreSSL, es muy compatible con él) no se ven afectados por estos errores.
Ah, y si los PoC comienzan a aparecer en línea, por favor no sea un zueco inteligente y comience a «probar» esos PoC en las computadoras de otras personas con la impresión de que está «ayudando» con algún tipo de «investigación».
Fuente: naked security by Sophos
