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 selber 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]
….
Erweiterung für Spatial und Graph:
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]
….
Ergänzung vom 15.12.2021 des Oracle Support zu Spatial and Graph:
Oracle Support Statement: Database Vulnerability CVE-2021-44228 With Oracle Spatial and Graph (Doc ID 2828303.1)
There are questions about Oracle Spatial and Graph with against the vulnerability CVE-2021-44228.
Note 2827611.1 lists Oracle Spatial and Graph as a product with Patches due to the presence of some log4j jar files in /md/…. paths.
What are the concerns of this vulnerability with Oracle Spatial and Graph?
Solution
The vulnerability concerns only versions 12.2, 18.x, and 21.x.
12.1 and 19.x are not affected.On the affected versions, there is no vulnerability in the Spatial use case. By default, DB install does not use the log4j jars in Spatial code. The log4j file is only used by the Network Data Model feature of Spatial and it is only used if the customer uses the RDSolver.jar and TSPSolver.jar in a client side application; so there is no server side functionality that uses the log4j jar. These log4j files can be removed without affect to the DB features and without shutting down the DB. These files are not loaded into the DB Java VM.
Versions 21, 18, and 12.2 are the only affected releases and there will be a one off patch for the October DBRU for each of these releases (October DBRU for all three releases) marked as bug 33661960. When the patch is available, it can be applied to an October 2021 release.
Also, some installations may have Property Graph jar files such as the following: /md/property_graph/lib/log4j-api-2.11.0.jar /property_graph/lib/log4j-core-2.11.0.jar The property_graph path files are not part of any functionality in the DB. They are used only for the property functionality by the PGX client. The entire ORACLE_HOME/md/property_graph directory has been removed as part of the OCT 2020 DBRU in Oracle 19.
Bedeutet, es gibt aktuell keinen sofortigen Handlungsbedarf in Zusammenhang mit unseren Support Produkten (MuM MapEdit oder AutoCAD Map3D) und eingesetzten Oracle Datenbanken. Die nicht genutzten, sofern vorhandenen bzw. installierten log4j Dateien können bei Bedarf wenn gewünscht gelöscht werden.
Sobald es hier neuere Informationen oder Patches gibt, werden wir diese hier veröffentlichen bzw. aktualisieren.
Oracle SQL Developer
Neuerung vom 15.12.2021
Es gibt für den beliebten SQL Developer eine gepatched Version zum Download.
https://www.oracle.com/tools/downloads/sqldev-downloads.html
https://www.oracle.com/tools/sqldev/sqldev-relnotes-21.4.html
Ü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.