La nueva versión Log4j 2.17.1 corrige la ejecución remota de código CVE-2021-44832 (pero no es tan grave como parece)

Como se había previsto, aproximadamente a las 7:35 p. m. GMT del 28 de diciembre de 2021 se publicó otra vulnerabilidad de seguridad que afecta a la biblioteca de registro Log4j: CVE-2021-44832.

Esta nueva vulnerabilidad de seguridad CVE-2021-44832 afecta a las versiones hasta la 2.17.0, que se creía que ya estaba corregida. Esta vulnerabilidad es similar a CVE-2021-4104, que afectó a la rama 1.x de Log4j.

El impacto de CVE-2021-44832

Si puedes actualizar rápidamente a la última versión corregida de Log4j, te recomendamos hacerlo. Dicho esto, queremos señalar que a esta vulnerabilidad específica CVE-2021-44832 se le asignó una puntuación CVSS media de 6.6 y que requiere condiciones previas considerablemente elevadas para que un atacante pueda explotarla con éxito.

CVE-2021-44832 considera que Log4j 2.17.0 (y las versiones anteriores) es vulnerable a la ejecución de código si un atacante puede controlar y modificar el contenido del archivo de configuración de registro para que apunte a una fuente de datos URI remota y cargue código Java arbitrario.

La corrección de la versión 2.17.1, que también se incorporó a versiones anteriores de la biblioteca compatibles con JVM, mitigó esta vulnerabilidad al restringir la fuente de datos JNDI del archivo de configuración para permitir únicamente el protocolo Java y prohibir las llamadas a redes remotas.

Pasos inmediatos para corregir CVE-2021-44832

El equipo de Log4j publicó correcciones para esta vulnerabilidad de seguridad:

• Si usas Java 8 o una versión posterior, actualiza a Log4j 2.17.1

• Si usas la rama 2.12.x para Java 7, actualiza a Log4j 2.12.4

• Si usas la rama 2.3.x para Java 6, actualiza a Log4j 2.3.2

Una avalancha de vulnerabilidades de Log4j filtradas prematuramente

La divulgación de esta vulnerabilidad sigue una tendencia cada vez más preocupante de divulgaciones irresponsables relacionadas con Log4j. Investigadores de seguridad han filtrado detalles de las vulnerabilidades que descubrieron antes de que los responsables de mantenimiento tuvieran tiempo de corregirlas adecuadamente y publicar nuevas versiones.

Este fenómeno problemático comenzó con la RCE original de Log4j, cuando investigadores filtraron detalles e incluso una prueba de concepto de la vulnerabilidad en Twitter y GitHub, horas antes de la divulgación oficial (consulta nuestra cronología). Una vez más, la existencia de esta vulnerabilidad se filtró en Twitter varias horas antes del lanzamiento oficial, por parte de un investigador de seguridad que se atribuyó el hallazgo.

Al parecer, en ambos casos, la filtración de información, aunque probablemente no haya sido malintencionada, provocó que Apache se apresurara a publicar una versión (lo que podría dejar la puerta abierta a vulnerabilidades y errores adicionales en la nueva versión). Además, en este caso específico, podemos suponer que, de haber podido elegir, Apache no habría optado por apresurar el lanzamiento en una época del año en la que muchas organizaciones tienen feriados prolongados y, por lo tanto, tendrían menos capacidad para evaluar rápidamente la gravedad y corregir el problema, si fuera necesario.

La seguridad del código abierto es cada vez más importante para el mundo entero y las prácticas de divulgación responsable son fundamentales para la seguridad continua de nuestra comunidad. Esperamos que las futuras divulgaciones relacionadas con Log4j u otros paquetes de código abierto puedan manejarse de forma más segura.

Como siempre, en Snyk mantenemos nuestro compromiso con nuestro programa de divulgación responsable, sin dejar de estar atentos a posibles amenazas emergentes y de brindar información rápida y útil a nuestros usuarios y a toda la comunidad de código abierto.