A finales de octubre, Los desarrolladores de OpenSSL advirtieron que la próxima actualización de la versión 3.0.7 cerraría una vulnerabilidad crítica. Notablemente, Este sería sólo el segundo error crítico en OpenSSL desde 2016.
Ahora eso AbiertoSSL 3.0.7 ha sido lanzado oficialmente, resultó que Se publicaron correcciones para dos vulnerabilidades graves a la vez., y se revisó la calificación de error crítico, y ya no se considera como tal.
Versión 3.0.7 Se corrigieron dos vulnerabilidades a la vez. (CVE-2022-3602 y CVE-2022-3786) afectando las versiones de OpenSSL 3.0.0 y más alto (de 3.0.0 a 3.0.6).
El estado crítico debería haber sido CVE-2022-3602, que es un desbordamiento arbitrario del búfer de pila de 4 bytes que puede causar fallas o llevar a la ejecución de código arbitrario (ICE).
Por último, esta vulnerabilidad fue calificada como de alta severidad ya que según el normas, un error crítico debería afectar configuraciones generalizadas, y sólo instancias de OpenSSL 3.0 y luego son vulnerables a CVE-2022-3602.
La segunda cuestión, CVE-2022-3786, puede ser explotado por un atacante potencial a través de direcciones de correo electrónico maliciosas y es capaz de provocar una denegación de servicio mediante un desbordamiento del búfer.
A pesar de las garantías de los desarrolladores., Algunos expertos y proveedores de seguridad de la información se apresuraron a equiparar el descubrimiento de una vulnerabilidad en OpenSSL con el sensacional Log4Shell problema, descubierto en 2021 en el Log4J biblioteca.
Computadora que suena señala que tal pánico es prematuro: de acuerdo a censys, solamente acerca de 7,000 sistemas Se pueden encontrar versiones vulnerables de OpenSSL en la red. (entre más de 1,793,000 anfitriones únicos), y según Shodan, hay acerca de 16 tales casos.
empresa de seguridad en la nube Wiz.io analizado Implementaciones en los principales entornos de nube. (como AWS, PCG, Azure, OCI, y Nube de Alibaba) y también informa que sólo 1.5% de todas las instancias de OpenSSL se ven afectadas por la última vulnerabilidad.
Una página separada dedicado a CVE-2022-3602 y todos los datos relacionados fueron lanzados por un conocido experto en seguridad de la información. Marcos Hutchins. Explica que el problema ocurre al validar un certificado X.509 y puede usarse para ejecutar código usando un certificado TLS malicioso de forma remota.. Sin embargo, la explotación requiere que el certificado TLS malicioso esté firmado por una CA confiable.
El Centro Nacional de Ciberseguridad de los Países Bajos ya ha comenzado a compilar un lista de productos que están afectados o no por el último error.
Vale la pena decir que akamai Los analistas han clasificado Redhat Enterprise Linux 9, ubuntu 22.04+, CentOS Stream9, Kali 2022.3, Debian 12 y sombrero 36 distribuciones tan vulnerable. Los expertos de la empresa ya han publicado OSQuery y NIÑOS reglas que deberían ayudar a los especialistas en seguridad a detectar productos vulnerables.