En la biblioteca Log4j 2 se ha detectado otra vulnerabilidad (CVE-2021-45105), que a diferencia de los dos problemas anteriores, se clasifica como peligrosa, aunque no crítica. Este nuevo problema permite causar una denegación de servicio y se manifiesta como un bucle infinito y un cierre inesperado al procesar ciertas cadenas. La vulnerabilidad ha sido corregida en la versión de Log4j 2.17 publicada hace unas horas. La gravedad de la vulnerabilidad se mitiga por el hecho de que el problema se presenta solo en sistemas con Java 8.
Los sistemas que son susceptibles a las vulnerabilidades son aquellos que utilizan consultas contextuales (Context Lookup) al determinar el formato de salida en el log, como ${ctx:var}. En las versiones de Log4j, desde 2.0-alpha1 hasta 2.16.0, faltaba protección contra recursión no controlada, lo que permitía a un atacante, a través de manipulaciones del valor utilizado en la sustitución, provocar un bucle infinito que lleva al agotamiento del espacio en la pila y al cierre inesperado del proceso. En particular, el problema se producía al sustituir valores como «${${::-${::-$${::-j}}}}».
Adicionalmente, se puede señalar que los investigadores de Blumira han propuesto un tipo de ataque a las aplicaciones Java vulnerables que no aceptan solicitudes de red externas; por ejemplo, sistemas de desarrolladores o usuarios de aplicaciones Java pueden ser atacados de esta manera. La esencia del método es que, al tener procesos Java vulnerables en el sistema del usuario que solo aceptan conexiones desde el host local (localhost) o que procesan solicitudes RMI (Remote Method Invocation, puerto 1099), el ataque puede ser llevado a cabo por un código JavaScript ejecutado al abrir a los usuarios una página maliciosa en el navegador. Para establecer la conexión con el puerto de red de la aplicación Java durante un ataque de este tipo se utiliza la API WebSocket, que a diferencia de las solicitudes HTTP, no tiene restricciones de same-origin (WebSocket también puede ser utilizado para escanear puertos de red en el host local con el fin de identificar manejadores de red existentes).
También son de interés los resultados de la evaluación de vulnerabilidad de las bibliotecas relacionadas con Log4j publicados por Google. Según Google, el problema afecta al 8% de todos los paquetes en el repositorio de Maven Central. En particular, 35,863 paquetes de Java relacionados con Log4j son vulnerables, ya sea por dependencias directas o indirectas. Log4j se utiliza como dependencia directa de primer nivel solo en el 17% de los casos, mientras que en el 83% de los paquetes afectados, la vinculación se realiza mediante paquetes intermedios que dependen de Log4j, es decir, dependencias de segundo y más alto nivel (21% de segundo nivel, 12% de tercer nivel, 14% de cuarto nivel, 26% de quinto nivel, 6% de sexto nivel). La velocidad de corrección de la vulnerabilidad deja mucho que desear; una semana después de que se identificara la vulnerabilidad, el problema se ha resuelto solo en 4,620 de los 35,863 paquetes identificados, es decir, en un 13%.
Mientras tanto, la Agencia de Ciberseguridad y Seguridad de Infraestructura de EE. UU. ha publicado una directiva de emergencia que obliga a las agencias federales a identificar los sistemas de información vulnerables a Log4j y a implementar actualizaciones que bloqueen el problema antes del 23 de diciembre. Hasta el 28 de diciembre, se les ha ordenado a las organizaciones informar sobre el trabajo realizado. Para facilitar la identificación de los sistemas problemáticos, se ha preparado una lista de productos en los que se ha confirmado la aparición de la vulnerabilidad (la lista incluye más de 23,000 aplicaciones).
Fuente: opennet.ru
