tejas-nagchandi/cve-2021-45046Reproduktion von CVE-2021-45046
Es wurde festgestellt, dass der Fix für CVE-2021-44228 in Apache Log4j 2.15.0 in bestimmten nicht standardmäßigen Konfigurationen unvollständig war. Dies könnte Angreifern, die Kontrolle über die Eingabedaten der Thread Context Map (MDC) haben, ermöglichen, mithilfe eines JNDI-Lookup-Musters bösartige Eingabedaten zu erzeugen, wenn die Logging-Konfiguration ein nicht standardmäßiges Pattern-Layout entweder mit einem Context-Lookup (z. B. $${ctx:loginId}) oder einem Thread-Context-Map-Muster (%X, %mdc oder %MDC) verwendet, was zu einem Denial-of-Service-Angriff (DOS) führt. Log4j 2.15.0 unternimmt standardmäßig einen Best-Effort-Versuch, JNDI-LDAP-Lookups auf localhost zu beschränken. Log4j 2.16.0 behebt dieses Problem, indem die Unterstützung für Message-Lookup-Muster entfernt und die JNDI-Funktionalität standardmäßig deaktiviert wird.
Log4j führte das Konzept des Mapped Diagnostic Context oder MDC ein.
Log4j 2 führt die Idee von MDC und NDC fort, fasst sie jedoch zu einem einzigen Thread Context zusammen. Die Thread Context Map ist das Äquivalent zum MDC und der Thread Context Stack das Äquivalent zum NDC. Obwohl diese häufig für andere Zwecke als die Diagnose von Problemen verwendet werden, werden sie in Log4j 2 weiterhin häufig als MDC und NDC bezeichnet, da diese Akronyme bereits allgemein bekannt sind.
Die meisten realen Systeme müssen gleichzeitig mit mehreren Clients umgehen. In einer typischen Multithread-Implementierung eines solchen Systems bearbeiten verschiedene Threads verschiedene Clients. Logging eignet sich besonders gut, um komplexe verteilte Anwendungen zu verfolgen und zu debuggen. Ein üblicher Ansatz, die Logging-Ausgabe eines Clients von der eines anderen zu unterscheiden, besteht darin, für jeden Client einen neuen separaten Logger zu instanziieren. Dies fördert die Verbreitung von Loggern und erhöht den Verwaltungsaufwand des Loggings.
Eine einfachere Technik besteht darin, jede Log-Anfrage, die von derselben Client-Interaktion ausgeht, eindeutig zu kennzeichnen. Neil Harrison beschrieb diese Methode in dem Buch „Patterns for Logging Diagnostic Messages“ in Pattern Languages of Program Design 3, herausgegeben von R. Martin, D. Riehle und F. Buschmann (Addison-Wesley, 1997). Genau wie ein Fisch markiert und seine Bewegungen verfolgt werden können, ermöglicht das Versehen von Log-Ereignissen mit einem gemeinsamen Tag oder einer Reihe von Datenelementen, den vollständigen Ablauf einer Transaktion oder einer Anfrage zu verfolgen. Wir nennen dies Fish Tagging.
Log4j bietet zwei Mechanismen zur Durchführung von Fish Tagging: die Thread Context Map und den Thread Context Stack. Die Thread Context Map ermöglicht es, beliebig viele Elemente hinzuzufügen und sie mithilfe von Schlüssel/Wert-Paaren zu identifizieren. Der Thread Context Stack ermöglicht es, ein oder mehrere Elemente auf den Stack zu legen und sie anschließend anhand ihrer Reihenfolge im Stack oder anhand der Daten selbst zu identifizieren. Da Schlüssel/Wert-Paare flexibler sind, wird die Thread Context Map empfohlen, wenn während der Verarbeitung der Anfrage Datenelemente hinzugefügt werden können oder wenn mehr als ein oder zwei Elemente vorhanden sind.
Um jede Anfrage mithilfe des Thread Context Stack eindeutig zu kennzeichnen, legt der Benutzer Kontextinformationen auf den Stack.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 https://logging.apache.org/log4j/2.x/manual/thread-context.html
