Sicherheitswarnung Log4j CVE-2021-44228
13.12.2021
Das Bundesministerium für Sicherheit in der Informationstechnologie (BSI) hat am 11.12.2021 eine Warnung herausgegeben, dass die Java-Bibliothek Log4j durch eine Remote Execute Lücke bedroht ist.
Folgende Hinweise und Handlungsempfehlungen
MuM MapEdit
Wir nutzen Log4j in Verbindung mit Apache Tomcat und unseren Produkten MuM MapEdit TileServer und MuM MapEdit Mobile (bis zur Version 20.x).
Laut den derzeit uns vorliegenden Informationen z.B. Infos von Cloudflare ist die dabei von uns genutzte Log4j Version 1.2.17 nicht betroffen, da es dort die angegriffene Funktionalität noch nicht gibt (sondern erst Versionen ab 2.0). Zudem sind wir nicht betroffen sind, weil wir nicht die Konfiguration mit dem JMSAppender (wie beim BSI verlinkt) nutzen.
siehe Seite 3 unten, Update 2 in dieser PDF:
Aktualisierung vom 14.12.2021 aufgrund des Update 4 in der oben verlinkten PDF des BSI.
Dort schreibt das BSI, dass durch "schadhaften Programmkonfiguration" mit Log4j 1.2.x es auch die Möglichkeit bestehen kann diese Sicherheitslücke auszunutzen. Was das BSI allerdings genau unter "schadhaften Programmkonfiguration" versteht, lässt sich nur vermuten.
Eine schadhafte Konfiguration wäre beispielsweise, falls ein Angreifer Schreibrechte auf den Tomcat zum Ändern der Konfiguration erhalten sollte, könnte er auch einfach eigene Class-Files deployen und damit weiterarbeiten – dazu braucht es allerdings kein log4j mehr.
Im Tomcat (nur da wird log4j benutzt) setzen wir die Konfiguration von log4j komplett selbst auf. Dort konfigurieren wir nur den DailyRollingFileAppender in unserer Konfiguration, um in täglich wechselnde Dateien zu schreiben. Diese Lücke ist daher in unserem Falle rein theoretischer Natur.
Grundsätzlich ist die Version 1.2.x älter und hat demnach natürlich auch nicht andere, nicht diesen Fall betreffende, ggf. sicherheitsrelevanten Updates einer log4j2.
Ebenso will das BSI vermutlich damit ausdrücken, das man grundsätzlich immer ein Update auf eine aktuellste Version machen sollte. Was auch richtig ist, aber dann auch alle anderen Software/IT Systeme (angefangen bei älteren Server Betriebssystemen) betrifft.
Sie werden sicherlich verstehen, dass wir zu Systemen die nicht zu 100% durch uns gemanaged werden, kein Garantie, oder konkrete Aussage zur Risiko/Schadens-Wahrscheinlichkeit treffen können.
Wir sehen eine sofortige Dringlichkeit bei uns derzeit nicht, zumal wir seit einem Jahr neben Tomcat auch den Wildfly unterstützen und diesen bei Kunden erfolgreich im Einsatz haben.
Wir haben Log4j in Verbindung mit unseren Produkten nicht auf 2.x aktualisiert, da dies größere Änderungen bei der Konfiguration/API mitgebracht hätte und wir mittlerweile komplett auf SLF4J setzen, dass der WildFly und andere Java Enterprise Server mitbringen. Dies werden wir demnächst im Rahmen der Softwarepflege auch für die noch bestehenden Tomcat Installationen trotzdem jetzt angehen und auf Log4j2 aktualisieren.
In Verbindung mit Wildfly wird Log4j von MapEdit TileServer, MapEdit Mobile und MapEdit Portal gar nicht genutzt, sondern die interne Protokollierung verwendet. Damit tritt diese Sicherheitslücke bei unseren Produkten in Verbindung mit dem Applikationsserver Wildfly nicht auf.
Noch eine wichtige Ergänzung und Unterscheidung bei der Analyse dazu bei Wildfly Installationen:
- Der WildFly stellt die log4j-api-2.14.1.jar bereit, um Anwendungen die gegen log4j programmiert wurden, die Nutzung des integrierten Loggings über diese API zu erlauben.
- Problematisch in Zusammenhang mit diesem Sicherheitsproblem wäre die log4j-core-2.14.1.jar, welche die eigentliche Implementierung des Loggings zur Verfügung stellt und die ursächliche Klasse JndiLookup bereitstellt. Diese wird allerdings beim WildFly nicht mit ausgeliefert, da er ein eigenes Logging-Modul von IBM verwendet.
Hier geht es wirklich nur darum, die abstrakte API bereitzustellen und dann intern auf das eigene Logging umzuleiten. In der module.xml im selben Verzeichnis sieht man das auch, da dort auf das interne Modul org.jboss.logmanager.log4j2 verwiesen wird.
Bei Apache Tomcat verwenden wir in Verbindung mit unseren MapEdit Produkten die ältere, nicht betroffene Log4j Version 1.2.x. Werden demnächst im Rahmen der Softwarepflege trotzdem eine Aktualisierung auf eine Log4j2 durchführen.
Sollten Sie im Internet z.B. MuM MapEdit Mobile in einer älteren Version (Release 20.x oder älter) betreiben, empfehlen wir bei Sicherheitsfragen wie bisher auch, immer ein Update auf die aktuellsten Versionen des Betriebssystems, sowie aller dort installierten Komponenten. Bei z.B. MuM MapEdit Mobile eben ein Update auf das aktuellste MapEdit Release und damit die Umstellung von Tomcat auf Wildfly.
Oracle Datenbanken
Auch Oracle hat reagiert und entsprechende Warnung publiziert.
Bitte beachten Sie dass die Datenbank Server nur über die Applikationen erreicht werden können und somit die Kommunikation mit der Datenbank komplett selber steuern und auch nur für angemeldete Benutzer freigegeben haben. Dh. die Wahrscheinlichkeit einen Angriffspunkt hier zu bieten ist wesentlich geringer, als die in Verbindung mit einem Web/Applikationsserver.
Wichtig für uns ist hier, dass die Oracle Datenbank Produkte nicht betroffen sind.
Oracle products not requiring patches
The following products were previously listed as "Under Investigation". Oracle has completed its review and, at this point in time, believe that the following products are not affected by vulnerability CVE-2021-44228:
....
Oracle Database [Product ID 5]
....
Allerdings steht auch in der Liste:
Oracle products with patches pending
Oracle has determined that the following Oracle products are vulnerable and do not currently have patches available for CVE-2021-44228:
....
Oracle Spatial and Graph [Product ID 619]
....
Bedeutet, es gibt aktuell keinen Patch von Oracle für die Spatial and Graph Erweiterung. Wir vermuten dass diese Möglichkeit an dem dort mit im Produkt enthaltenen Kartenserver und weniger an den Spatial Erweiterungen der Datenbank liegen könnte.
Sobald es hier neuere Informationen oder Patches gibt, werden wir diese hier veröffentlichen bzw. aktualisieren.
Überprüfung des Systems
Falls Sie ein Skript zur Prüfung Ihrer Server einsetzen wollen, können wir Ihnen dieses hier empfehlen:
https://github.com/mergebase/log4j-detector
Bitte beachten Sie, dass wir, auch wenn wir diese externen Programme empfehlen, hierfür keine Gewähr, oder Support übernehmen können. Es gelten die Bedingungen des entsprechenden Herstellers.