Auf dieser Seite informiert das RUS-CERT über kritische Schwachstellen in Log4j und über Gegenmaßnahmen.
Diese Seite wird nicht mehr aktualisiert. Die Inhalte auf dieser Seite können veraltet sein.
Aktuelle Informationen zu neu auftretenden Schwachstellen (z. B. CVE-2021-44832) sowie zu Sicherheitsupdates von Log4j (z. B. Versionen 2.3.2, 2.12.4 und 2.17.1) sind auf der Webseite der Log4j-Autoren unter https://logging.apache.org/log4j/2.x/security.html zu finden.
Log4j ist eine häufig eingesetzte Bibliothek für Java-Anwendungen, die zur Aggregation von Protokolldaten der Anwendung dient.
Verschiedene Versionen von Log4j sind von mehreren Schwachstellen betroffen.
Die Updates auf Version 2.16.0 oder 2.15.0 sowie der Workaround mit der Java-System-Property log4j2.formatMsgNoLookups bzw. der Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS waren nicht vollständig.
Die Version 2.16.0 von Log4j ist von einer neu entdeckten Schwachstelle betroffen. Nur ein Update auf Log4j 2.17.0 behebt alle bisher gefundenen Schwachstellen.
Eine genaue Beschreibung der Schwachstellen findet sich im folgenden Abschnitt.
Die Versionen 1.x.x von Log4j sind entgegen der ursprünglich anderslautenden Annahme verwundbar: CVE-2021-4104 erlaubt die Ausführung von beliebigem Code (Remote Code Execution, RCE). Laut BSI ist die Ausnutzung nur in Verbindung mit einer schadhaften Programmkonfiguration möglich.
Die Versionen 2.0 bis 2.12.1 und 2.13.0 bis 2.14.1 von Log4j sind von der kritischen Schwachstelle CVE-2021-44228 betroffen. Mithilfe einer entsprechenden Anfrage an das System kann beliebiger Code auf dem System ausgeführt werden (Remote Code Execution, RCE). Die Schwachstelle kann in der Standardkonfiguration ausgenutzt werden.
Die Versionen 2.0 bis 2.12.1 und 2.13.0 bis 2.15.0 von Log4j sind von der kritischen Schwachstelle CVE-2021-45046 betroffen, welche die Ausführung von beliebigem Code (Remote Code Execution, RCE) erlaubt. Laut dem Advisory der Log4j-Autoren ist die Ausnutzung nur in Verbindung mit einer schadhaften Programmkonfiguration möglich.
Die Versionen 2.0 bis 2.16.0 von Log4j sind von der Schwachstelle CVE-2021-45105 betroffen, welche zu einem Programmabsturz (Denial of Service, DoS) führen kann. Laut dem Advisory der Log4j-Autoren ist die Ausnutzung nur in Verbindung mit einer spezifischen Programmkonfiguration möglich.
Die Schwachstellen sind vor allem für Anwendungen auf Servern relevant. Arbeitsplatzsysteme (Clients) sind typischerweise nicht von den Schwachstellen betroffen.
Übersichtslisten, welche Produkte von der Schwachstelle (nicht) betroffen sind, finden Sie unter
Diese Listen werden fortlaufend aktualisiert; aufgrund der großen Verbreitung von Log4j gibt es aktuell keine vollständige Übersicht betroffener Systeme.
In der Liste der betroffenen Produkte wird u.a. Cisco Webex geführt. Die Webex-Server waren prinzipiell über die Schwachstelle angreifbar, wurden allerdings zwischenzeitlich von Cisco gepatcht. Webex-Clients auf Arbeitsplatzrechnern sind nicht betroffen.
Bitte bedenken Sie, dass auch von Ihnen genutzte Dienste, die von Fremdfirmen gehostet und betreut werden, von der Log4j-Schwachstelle betroffen sein könnten. Klären Sie diese Betroffenheit ggf. mit den jeweiligen Anbietern ab.
Die Schwachstelle CVE-2021-44228 wird mit dem maximal möglichen CVSS-Score von 10.0 bewertet, die Schwachstelle CVE-2021-45046 mit dem ähnlich hohen Wert 9.0. Auschlaggebend hierfür ist, dass die Schwachstellen aus der Ferne ausnutzbar sind und bereits Exploit-Code für verschiedene betroffene Produkte zur Verfügung steht.
Es werden weltweit großflächige Scans nach verwundbaren Systemen beobachtet. Eine zeitnahe großflächige Ausnutzung der Schwachstelle ist zu erwarten.
Prüfen Sie umgehend, welche Systeme in Ihrem Zuständigkeitsbereich von der Schwachstelle betroffen sind. Dabei können die oben angegebenen Links hilfreich sein. Die Kollegen des KIT haben auch einige Hinweise zum Auffinden von betroffenen Systemen zusammengestellt: https://www.cert.kit.edu/p/cve-2021-44228
Falls Systeme betroffen sind und dafür Updates existieren, sollten diese umgehend installiert werden.
In einigen Fällen sind Workarounds möglich (s.u.).
Bei allen Systemen, bei denen eine Betroffenheit nicht abschließend geklärt werden kann oder bei denen trotz Anfälligkeit für die Schwachstelle kein Patch bereitsteht, empfehlen wir den Zugang auf die Systeme zumindest auf das Uninetz zu beschränken (Freischaltungen an der Perimeter-Firewall entfernen lassen) oder wenn möglich die Systeme vorübergehend außer Betrieb zu nehmen, bis ein Patch bereitsteht oder die Betroffenheit geklärt werden kann.
Die im Folgenden aufgeführten Workarounds schützen gegen die Schwachstellen, welche die Ausführung von beliebigem Code erlauben. Sie schützen nicht gegen die Schwachstelle CVE-2021-45105, welche zu einem Programmabsturz führen kann. Workarounds für CVE-2021-45105 sind im Advisory der Log4j-Autoren zu finden.
Es muss jedoch weiterhin bzw. zusätzlich ein Workaround für die Schwachstellen CVE-2021-45046 und CVE-2021-44228 angewandt werden, sofern die verwendete Version von Log4j davon betroffen ist.
Im Anwendungsarchiv (JAR) der betroffenen Anwendung bzw. der Log4j-Bibliothek kann die betroffene Klasse JndiLookup gelöscht werden.
Sofern Sie die JAR-Datei der Anwendung, in der Log4j inkludiert ist, verändern können, kann dieser Workaround angewandt werden. Die Autoren von Log4j geben hierfür das folgende Beispielkommando an: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Achtung: Der Workaround kann zu Funktionseinschränkungen führen.
Von Amazon Web Services wurde Programmcode für einen Java Agent veröffentlicht, welcher ohne Veränderung von JAR-Dateien die Schwachstelle mitigieren kann. Eine Anwendung kann im laufenden Betrieb (nur Java-Versionen 8 und 11) oder mit Veränderung der Kommandozeile und Neustart (Java-Versionen 8, 11 und 17) gepatcht werden.
Der Code ist unter https://github.com/corretto/hotpatch-for-apache-log4j2 abrufbar.
Achtung: Das Patchen im laufenden Betrieb ist nicht persistent und betrifft nur die aktuelle Ausführung des Programms. Nach einem Neustart muss diese Art des Patches wieder angewandt werden.
Eine alternative Implementierung eines Java Agents wurde von der NCC Group veröffentlicht, welche alle Java-Versionen ab Java 6 unterstützt, jedoch kein Patchen im laufenden Betrieb.
Diese alternative Implementierung ist unter https://github.com/nccgroup/log4j-jndi-be-gone abrufbar.
In früheren Versionen dieser Seite wurde ein Workaround beschrieben, bei dem eine JVM-Option oder Umgebungsvariable gesetzt wird. Gegen CVE-2021-45046 bietet dieser Workaround jedoch keinen Schutz.
Daher reicht es nicht mehr aus, das Kommandozeilenargument -Dlog4j2.formatMsgNoLookups=True hinzuzufügen oder die Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS auf true zu setzen.
Wir empfehlen das Update auf Log4j2-Version 2.12.2 (plus Workaround für CVE-2021-45105) oder 2.17.0 oder die Anwendung von anderen Workarounds.
Es existieren Werkzeuge, welche lokal in einem angegebenen Verzeichnis nach verwundbaren Programmen suchen. Dies ist vor allem dann hilfreich, wenn nicht klar ist, ob eine Java-Anwendung betroffen ist.
Zwei solcher Datei-Scanner finden Sie unter:
Für den Versionsnummern-basierten Scanner https://github.com/logpresso/CVE-2021-44228-Scanner steht eine neue Version zur Verfügung, welche alle betroffenen Versionen von Log4j (bis 2.16.0) detektiert.
Für den Hashsummen-basierten Scanner steht noch kein Update zur Verfügung, welches CVE-2021-4104 oder CVE-2021-45105 detektiert.
Wir blockieren an der Borderfirewall die IPs von bösartigen LDAP-Servern, die zur Ausnutzung der Schwachstelle verwendet werden. Dabei wird die Liste von abuse.ch genutzt.