tejas-nagchandi/cve-2021-45046Replicando CVE-2021-45046
Se descubrió que la corrección para abordar CVE-2021-44228 en Apache Log4j 2.15.0 era incompleta en ciertas configuraciones no predeterminadas. Esto podría permitir a atacantes con control sobre los datos de entrada del Thread Context Map (MDC) cuando la configuración de registro utiliza un Pattern Layout no predeterminado con una Context Lookup (por ejemplo, $${ctx:loginId}) o un patrón de Thread Context Map (%X, %mdc o %MDC) para manipular datos de entrada maliciosos utilizando un patrón JNDI Lookup, resultando en un ataque de denegación de servicio (DOS). Log4j 2.15.0 realiza un esfuerzo para restringir las búsquedas JNDI LDAP al localhost de forma predeterminada. Log4j 2.16.0 soluciona este problema eliminando la compatibilidad con patrones de búsqueda de mensajes y deshabilitando la funcionalidad JNDI de forma predeterminada.
Log4j introdujo el concepto de Mapped Diagnostic Context o MDC.
Log4j 2 continúa con la idea de MDC y NDC pero los fusiona en un solo Thread Context. El Thread Context Map es el equivalente de MDC y el Thread Context Stack es el equivalente de NDC. Aunque se usan con frecuencia para fines distintos al diagnóstico de problemas, todavía se les conoce comúnmente como MDC y NDC en Log4j 2, ya que son bien conocidos por esos acrónimos.
La mayoría de los sistemas del mundo real deben manejar múltiples clientes simultáneamente. En una implementación típica multihilo de dicho sistema, diferentes hilos manejarán diferentes clientes. El registro (logging) es especialmente adecuado para rastrear y depurar aplicaciones distribuidas complejas. Un enfoque común para diferenciar la salida de registro de un cliente de otro es instanciar un nuevo registrador separado para cada cliente. Esto promueve la proliferación de registradores y aumenta la sobrecarga de gestión del registro.
Una técnica más ligera es marcar de forma única cada solicitud de registro iniciada desde la misma interacción del cliente. Neil Harrison describió este método en el libro "Patterns for Logging Diagnostic Messages", en Pattern Languages of Program Design 3, editado por R. Martin, D. Riehle y F. Buschmann (Addison-Wesley, 1997). Así como un pez puede ser etiquetado y rastreado su movimiento, marcar eventos de registro con una etiqueta común o un conjunto de elementos de datos permite rastrear el flujo completo de una transacción o solicitud. A esto lo llamamos Fish Tagging.
Log4j proporciona dos mecanismos para realizar Fish Tagging: el Thread Context Map y el Thread Context Stack. El Thread Context Map permite agregar cualquier número de elementos que se identifican mediante pares clave/valor. El Thread Context Stack permite insertar uno o más elementos en la pila y luego identificarlos por su orden en la pila o por los datos mismos. Dado que los pares clave/valor son más flexibles, se recomienda el Thread Context Map cuando se puedan añadir elementos de datos durante el procesamiento de la solicitud o cuando haya más de uno o dos elementos.
Para marcar de forma única cada solicitud usando el Thread Context Stack, el usuario introduce información contextual en la pila.
