Oracle hat am Wochenende seinen Kunden eine E-Mail mit dem Hinweis auf die Schwachstelle in log4j verschickt: Oracle Security Alert for CVE-2021-44228 . Bisher ist jedoch kein Sicherheitspatch veröffentlicht und es mangelt an detaillierten Informationen zu dem Fehler in der Funktionsbibliothek bzw. im Überfluss an Informationen fehlt es an den relevanten Punkten. Aus diesem Anlass stellen wir eine vorläufige Zusammenfassung der Erkenntnisse im Bezug auf die von uns unterstützten Produkte bereit. Wir können jedoch keine Garantie für die Aussagen übernehmen, da die Grundlagen unserer Recherche ebenfalls einem Wandel unterliegen.
Was ist log4j und wie bedrohlich ist die Lage tatsächlich?
log4j ist eine sehr beliebte Funktionsbibliothek für die Programmiersprache Java und dient – wie der Name schon hinweist – dem Sammeln von Log-Einträgen über eine einheitliche und sehr flexible Schnittstelle (API). Deshalb hielt log4j in zahlreiche kommerzielle und Open Source-Projekte Einzug. Es kann in jeder Art von Software – egal ob Server oder Client – eingesetzt werden.
Der Fehler liegt in der Verarbeitung der übergebenen Log-Einträge, die so manipuliert werden können, dass sie als Befehl auf dem Betriebssystem ausgeführt werden. Solange die zu loggenden Daten nicht auf die Benutzereingaben beruhen, kann man einige Tage ruhig schlafen, bis der Hersteller nachgebessert hat. Loggt lo4j jedoch die übergebenen Benutzernamen, Anfragen etc., besteht dringend Handlungsbedarf. Wir wissen auch nicht, wie lange diese Schwachstelle schon bekannt ist und ob sie schon ausgenutzt wurde, so dass der Server bereits kompromittiert wurde, ohne dass man die Auswirkungen bereits bemerkt hat.
Das BSI hat deshalb eine Warnung der Stufe rot herausgegeben und liefert viele zusätzliche Informationen. Die wichtigste unter ihnen ist, dass nur die Version 2. Ab Minor-Version 2.15.0 ist das Verhalten der Software per Voreinstellung anders, so dass es nicht mehr möglich ist, die Schwachstelle auszunutzen. Ab Version 2.10 ist es möglich, das Verhalten händisch zu beeinflussen, indem man die Java-Property (entweder im Aufruf per -D oder per ini bzw. .property-Datei in Servlets) namens log4j2.formatMsgNoLookups auf wahr oder die Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS für den Start der Anwendung auf „true“ setzt. Verantwortliche von Kritischen Infrastrukturen sind ohnehin verpflichtet, BSI zu konsultieren und auf die Ratschläge und die Weisungen des Amtes entsprechend zu reagieren.
Besonders aufmerksam sollte der Administrator dort werden, wo log4j 2 im Einsatz ist und viele Benutzereingaben verarbeitet werden. Das kann die Java-basierte Desktop Anwendung sein, die eine präparierte Datei öffnet und gefundene Fehler in dieser Datei zu protokollieren versucht aber auch eine weltweit zugängliche Webanwendung (Servlet) im Tomcat oder JBOSS.
Wie sieht es bei Oracle aus?
Die Pakete der Betriebssysteme Oracle Linux und Red Hat weisen kein Paket von log4j in der betroffenen Version 2 auf. Oracle sichtet eigene Produkte und muss feststellen, ob und wo die Version inkludiert wurde. Das wird wohl etwas dauern, da es neben GRID und Datenbanken viele weitere Programme des Herstellers gibt.
Red Hat hat es bereits getan: https://access.redhat.com/security/vulnerabilities/RHSB-2021-009
Die kumulierten Sicherheitspatches werden laut Oracle-Patch-Plan am 18. Januar ausgeliefert. Bis dahin bleibt den Oracle-Kunden nur die Möglichkeit einen von Oracle bereit gestellten Hotfix einzuspielen, was wir nur in Absprache mit unseren Wartungskunden tun können, denn die betroffene Software muss neu gestartet werden.
Wir nehmen gerne Hinweise und Anfragen an und werden sie priorisiert abarbeiten.
Was ist mit PostgreSQL?
Die PostgreSQL-Anwender können entspannt sein. Entwarnung können wir für Kunden mit PostgreSQL-Appliances geben. In diesen unseren Produkten kommt die betroffene Software nicht zum Einsatz. Dennoch sollte man die Softwarekomponenten wie Middleware und Clients auf log4j „abklopfen“.
Update: 14. Dezember 2021, 9:00
Im Dokument Doc ID 2827611.1 listet Oracle betroffene, nicht betroffene und noch zu untersuchende Software aus seinem Haus. Entwarnung gilt für Oracle Datenbanken, denn sie verwenden ein anderes Logging-System. Auch APEX ist nach unseren Untersuchungen nicht betroffen, denn log4j taucht in der war-Datei nicht auf. Oracle Client gilt laut Hersteller als nicht betroffen.
Betroffen ist aktuell Oracle SQL Developer und Oracle SQL Developer Data Modeler (in allen Versionen) – die jedoch kaum unter Linux verwendet werden und vom Benutzer selbst geupdated werden müssen.Vgl. Doc ID 2828123.1
Eine Softwarekomponente gilt als gefährdet und wir nehmen Kontakt mit unseren Kunden auf.
Update 14. Dezember 2021, 16:00
Die von Oracle erwähnte „Engineered Systems Utilities (Trace File Analyzer) [Product ID 10655]“ scheint nach unseren ersten Untersuchungen kaum für einen Angriff geeignet. Diese Zusatzsoftware, die für die Erstellung von Support-Calls bei Oracle genutzt wird, ist nicht direkt erreichbar. Die vorgeschaltete Authentifizierung per Zertifikat verhindert einen Frontalangriff. (Analog gilt es für AHF)
Update 15. Dezember 2021, 17:00
Die Datenbank-Komponente für Spatial-Daten gilt unter Umständen als anfällig. Dazu muss ein bestimmtes Feature in der Instanz aktiviert werden, das wir bisher bei keinem Kunden im Einsatz gesehen haben.
Java Virtual Machine in der Datenbank ist ein mächtiges Werkzeug in den Händen eines Java-Programmierers. Sie bietet einige Freiheiten und könnte ein Türöffner für die log4j-Lücke sein. Darüber, wie die JVM in der DB verwendet wird (wenn sie nicht nur als Basis für andere Features vom DB-Administrator aktiviert wurde), kann nur der Softwarehersteller Auskunft geben.
Die Version 1 der Funktionsbibliothek log4j ist in Oracle-Installationen nicht angreifbar, sofern die richtige Voreinstellung für JNDI (Java Naming and Directory Interface) nicht verändert wurde.
Update 16.12.2021, 11:00
APEX wird von Oracle als nicht betroffen eingestuft. vgl. Oracle Application Express [Product ID 1348]
Die interessanteste Information versteckt sich hinter „Oracle Database (not exploitable) [Product ID 5]“ im Abschnitt „5.0 Oracle products not requiring patches“ unter der ID 2796575.1 und sagt über alle Datenbanken sinngemäß: Alle Versionen (12.1-21) und Typen (XE, SE, EE) enthalten die potenziell anfälligen Funktionsbibliotheken, sie jedoch für den Angriff nicht einsetzbar sind.
Update 17.12.2021, 9:30
Unsere Database Live Monitor (DBLM) verwendet kein Java und ist deshalb nicht betroffen. Die DBLM-Appliance auf Docker-Basis kommt ohne den als anfällig bekannten Docker-Desktop aus.
Im Netz wird gerne auf Tomcat als Gefahrenquelle hingewiesen. Das ist nur bedingt der Fall. Tomcat selbst nutzt log4j nicht. Es sind die Servlets (als .war-Datei und nach der Installation entpackt im Tomcat-Ordner), die die Anfällige Software enthalten können. Ob sie auch genutzt wird (oder nur z.B. für die Fehlersuche optional zugeschaltet wird) kann nur der Softwarehersteller beantworten.