In der Nacht auf den 10.12.2021 wurde die gravierende Sicherheitslücke CVE-2021-44228 in der sehr weit verbreiteten Java-Bibliothek Log4j2 bekannt.

Beschreibungen der Sicherheitslücke finden Sie an verschiedenen Stellen im Netz:

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
• https://www.randori.com/blog/cve-2021-44228/
• https://www.lunasec.io/docs/blog/log4j-zero-day/
• https://github.com/advisories/GHSA-jfh8-c2jp-5v3q

Im Folgenden haben wir Ihnen die wichtigsten Informationen über die Sicherheitslücke zusammengestellt. Informationen zu unseren jeweiligen Produkten finden Sie weiter unten.

Nach CVEs

CVE-2021-44832 Log4j 2 Remote Code Execution (03.01.2022)

CVE-2021-45105 Log4j 2 DoS (18.12.2021)

CVE-2021-42550 Logback Remote Code Execution (15.12.2021)

CVE-2021-45046 Log4j 2 Remote Code Execution (14.12.2021)

CVE-2021-44228 Log4j 2 Remote Code Execution (09.12.2021)

CVE-2019-17571 Log4j 1 Remote Code Execution (20.12.2019)

Wie kann ich erkennen, ob ich potenziell betroffen bin?

Betroffen ist jeder Anwendungscode, der folgende Bedingungen erfüllt:

• verwendet die Bibliothek Log4j2 ab Version 2.0 bis einschließlich 2.14.x 2.16.0
• externe Eingaben werden auf irgend einem Weg als Teil der Logausgabe geloggt (dies dürfte in den allermeisten Fällen gegeben sein)

Was kann gegenwärtig zur Beseitigung der Bedrohung getan werden?

• Die Version 2.16.0 von Log4j2 behebt das Problem, indem die das Problem verursachenden Lookups explizit aktiviert werden müssen, statt standardmäßig aktiv zu sein. Die betreffende Version ist über Maven Central verfügbar.
• Aktuelle Versionen von Log4j2 ab Version 2.10.0 unterstützen die System-Property log4j2.formatMsgNoLookups=true, die, wenn sie aktiviert ist, den Angriffsvektor beseitigt.
• Ältere Versionen von Log4j2 bieten die Möglichkeit, die Logging-Patterns so zu ändern, dass der Angriff nicht möglich ist. Dazu müssen alle Verwendungen des Logging-Patterns %m auf das Pattern %m{nolookups} geändert werden.

Somit ergeben sich drei mögliche Optionen:

1. Aktualisierung der verwendeten Log4j2-Version auf die Version 2.17.0 (oder neuere, sobald sie zur Verfügung stehen)
2. Verwendung von mindestens
   1. Log4j2 Version 2.10.0 und
   2. Setzen der Property log4j2.formatMsgNoLookups=true beim Start, also z.B. durch Aufruf der JVM mit dem Parameter -Dlog4j2.formatMsgNoLookups=true
3. Sofern eine ältere Version von Log4j2 eingesetzt wird und eine Aktualisierung nicht möglich ist, muss die Konfiguration der Logging-Patterns geprüft und alle Verwendungen des Logging-Patterns %m auf das Pattern %m{nolookups} geändert werden.

Welche weiteren Maßnahmen sollten ergriffen werden?

Solange nicht sichergestellt ist, dass die fraglichen Anwendungen nicht betroffen sind, sollte davon ausgegangen werden, dass diese angreifbar waren und ein Angriff stattgefunden haben könnte. Dies gilt insbesondere für Fälle, in denen eine Anwendung von Außen erreichbar ist.

Die Protokolle der Anwendungen und Systeme sollten gründlich auf Spuren von versuchten oder erfolgreichen Angriffen geprüft werden.

Was bedeutet das für die einzelnen jadice- und neverpile-Produkte?

jadice web toolkit

Zusätzlich zu den oben beschriebenen Maßnahmen gelten für das jadice web toolkit folgende spezifische Aussagen.

Das jadice web toolkit hat keine direkte Abhängigkeit auf log4j.  Wenn jedoch com.google.gwt:gwt-dev zum Entwickeln der Integration verwendet wird, ist log4j wahrscheinlich in Ihrem Projekt integriert. GWT-Dev verwendet eine alte Version von Jetty, welches wiederum eine Abhängigkeit auf log4j (in Version 2.8.2, welche durch die jwt Version 5.7.0.0 eingeführt wurde) mit sich bringt. GWT-Dev wird zwar in Produktion nicht verwendet, wenn Sie jedoch log4j als Logging-Framework verwenden, ist es wahrscheinlich, dass die Integration durch GWT-Dev die veraltete Version von log4j referenziert..

Integrationen, die auf Spring Boot basieren, nutzen typischerweise Logback als Log-Framework. Wir empfehlen, die logback-Konfiguration und -Nutzung gemäß  https://jira.qos.ch/browse/LOGBACK-1591 zu prüfen und ggf. die logback-Version in den Integrationen explizit auf 1.2.8 anzuheben.

Bitte prüfen Sie explizit die bei Ihnen referenzierte Version von log4j und logback und führen Sie ggf. die oben beschriebenen Maßnahmen durch. 

jadice server

Mit Version 5.9.0.0 wurde das Logging-Framework auf Log4J2 Version 2.14.1 umgestellt, damit sind von dieser Sicherheitslücke alle Versionen ab der 5.9.0.0 an bis zur Releaseversion 5.12.0.0 vom 03.12.2021 betroffen. Die Version 5.12.2.0 mit der Fehlerbehebung steht seit dem 10.12.2021 bereit.

Das Setzen der formatMsgNoLookups=true Property wie im Abschnitt "Was kann gegenwärtig zur Beseitigung der Bedrohung getan werden" beschrieben, kann beim Server in der wrapper.conf als zusätzliches JVM Argument via wrapper.java.additional.<nächste-freie-nummer>=-Dlog4j2.formatMsgNoLookups=true also zum Beispiel wrapper.java.additional.2=-Dlog4j2.formatMsgNoLookups=true eingepflegt werden.

Sollten Sie zusätzlich noch das Logging-Pattern von %m auf %m{nolookups} abändern wollen, so können Sie dies im PatternLayout in der Log4J2-Konfiguration im Ordner server-config vornehmen.

Wenn bei Ihnen, der bereits auf deprecated gesetzte, MVM-Modus zum Einsatz kommen sollte, so sollten Sie zusätzlich für die MVM-Instanzen die JVM-Argumente in den instanceJVMOptions in der Datei multi-vm-manager.xml eintragen.

Für Versionen kleiner 5.9.0.0 empfiehlt es sich, auch wenn eine Ausnutzung der Sicherheitslücke in Kombination mit dem JMSAppender unwahrscheinlich ist, den JMSAppender aus der Konfiguration auszubauen. Dafür gehen Sie wie folgt vor:

In der Konfigurationsdatei server-config/logging/log4j-configuration.xml kommentieren Sie die Zeilen für die Deklaration der Bean des JMSAppenders aus. Stellen Sie bitte zudem sicher, dass in den log4j-appenders-Konfigurationen jeweils die Bean-Definitionen der JMSAppender ebenfalls auskommentiert sind, bzw. entfernen Sie die Einträge.

Für Log4j 1 existiert zudem bereits seit 2019 die CVE-2019-17571. Allerdings ist diese Schwachstelle nur dann relevant, wenn die SocketServer-Komponente verwendet wird. Wir gehen davon aus, dass dies in den meisten Integrationen nicht der Fall ist. Eine Behebung für diese Sicherheitslücke wird nicht erfolgen, da log4j 1 das End-of-Life erreicht hat und nicht weiter gepflegt wird.

Wenn Sie bezüglich CVE-2019-17571 sicher gehen wollen, dann können Sie wie auf http://slf4j.org/log4shell.html beschrieben auch die Klasse JMSAppender via zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class aus der Bibliothek im Ordnern server-lib entfernen.

jadice document platform und jadice Swing-viewer

Integrationen der jadice document platform sind in sehr unterschiedlichen Konstellationen im Einsatz. Die jadice-utils unterstützen seit geraumer Zeit auch die Verwendung von Log4j2 wodurch die Möglichkeit gegeben ist, von dem Problem betroffen zu sein. Mögliche Maßnahmen sind oben beschrieben.

Desktop-Anwendungen auf Basis des Swing-Viewers kommen grundsätzlich ebenfalls für eine Angreifbarkeit infrage, allerdings hängt dies im Einzelfall ebenfalls von den Details der Integration ab.

jadice document platform 5.4

Die jadice document platform 5.4 bringt mehrere Module mit, die optional für das Logging eingesetzt werden können (siehe Referenzhandbuch). Unter jadice document platform 5.4 ist die Version von log4j nicht integrationsseitig zu setzen sondern diese kommt durch das Produkt mit. Das Modul logging-log4j setzt dabei jedoch auf log4j in Version 1.2.17. Diese Version ist nicht von CVE-2021-44228 betroffen, da hier kein JNDI-Lookup-Mechanismus vorhanden ist. Für Log4j 1 existiert jedoch bereits seit 2019 die CVE-2019-17571. Allerdings ist diese Schwachstelle nur dann relevant, wenn die SocketServer-Komponente verwendet wird. Wir gehen davon aus, dass dies in den meisten Integrationen nicht der Fall ist. Eine Behebung für diese Sicherheitslücke wird nicht erfolgen, da log4j 1 das End-of-Life erreicht hat und nicht weiter gepflegt wird.

Für Kunden, die noch jadice document platform 5.4 einsetzen gibt es daher die folgenden Möglichkeiten:

• Entfernen von logging-log4j, was das Logging auf java.util.Logging bewirkt
• Einbinden von logging-slf4j statt logging-log4j und Verwendung der SLF4j-Bridge auf Log4J2 Version 2.16.0
• Einbinden von logging-slf4j statt logging-log4j und Verwendung einer beliebigen anderen Bridge, z.B. java.util.Logging

neverpile

Alle Standardintegrationen der Neverpile-Familie setzen auf Spring-Boot in Standardkonfiguration in Verbindung mit dem Logging-Framework Logback auf, das nach aktuellem Kenntnisstand nicht betroffen ist. Sofern eine Integration auf dieser Standardkonfiguration aufsetzt, ist diese demnach nicht betroffen. Sollte jedoch abweichend von der Standardkonfiguration Log4j2 eingesetzt worden sein, ist davon auszugehen, dass die Integration von der Sicherheitslücke betroffen ist.

Darüber hinaus können Installationen, bei denen Neverpile auf Application-Servern betrieben wird, indirekt betroffen sein, wenn der Application-Server selbst Log4j2 einsetzt.