Am Wochenende ist eine gravierende Security Lücke im der weit verbreiteten Log4Shell entdeckt worden, die sehr einfach auszunutzen ist. Das ganze Wochenende über haben sich die Informationen dazu überschlagen. Hier eine Zusammenfassung was aktuell bekannt ist:

Security Alert

Am Freitag dem 09.12.2021 wurde eine Zero-Day-Lücke in der Java-Bibliothek Log4j bekannt (siehe beispielsweise Heise),  die mittlerweile mit einem CVSS Base Score von 10---also dem höchstmöglichen Wert---bewertet wurde.

Diese Bibliothek ist, weil in sehr vielen anderen Softwareprodukten integriert, sehr weit verbreitet und noch nicht von allen Softwareherstellern gepatched. Es handelt sich um eine Java Bibliothek, die für das Logging verwendet wird. Die Lücke befindet sich in der JNDI (Java Naming and Directory Interface) Lookup Funktion. Aktuell geht man davon aus, dass log4j in den Versionen 2.0 bis 2.14.1 betroffen ist (das kann sich noch ändern, Analysen älterer Versionen laufen noch).

Hier finden Sie auch eine ausführliche Beschreibung und weiterführende Informationen zu dieser Schwachstelle auf www.borncity.com.

Dazu finden sich auch behördliche Einschätzungen, z.B. aus Deutschland und den USA hier:

• Deutschland, BSI
• USA, NIST

Wir empfehlen unbedingt auf Updates der verwendeten Software zu achten und diese umgehend zu installieren.

Einfacher Test, ob ein Linux/Unix Server betroffen ist

Auf huntress.com gibt es einen einfachen Test zum Verifizieren ob ein Unix/Linux Server betroffen ist. Man muss einen einzeiligen Aufruf machen und kann dann verifizieren ob der Server betroffen ist. Solche Server sollten SOFORT vom Internet getrennt werden!

Man kann aber auch direkt als root am Server nachsehen:

find / -name "*.jar" | grep log4j

Bzw. schauen ob log4j installiert wurde:

rpm -qa | grep log4j

Einige Patches existieren bereits:

• Von Apache
• Seit Di, 14. Dez Mittagszeit steht die Version Log4j 2.16.0 mit einem besseren Schutz vor der Log4Shell Lücke zur Verfügung, wie Heise berichtet. Es gibt aber auch Abhängigkeiten von der genutzten Java Version und ob Mitigations greifen oder nicht.
• Mit Mo, 20. Dez steht die Version Log4j 2.17.0 zur Verfügung, die eine weitere Sicherheitslücke CVE-2021-45105 behebt. Diese sollte umgehend eingespielt werden.

Möglichkeiten zur Entschärfung der Auswirkungen:

• Logout4Shell um über den Exploit selbst, die Schwachstelle zu deaktivieren
• bei Log4j >=2.10      JNDILookup Class aus dem CLASSPATH entfernen
• bei Log4j >=2.10      Systemeinstellung log4j2.formatMsgNoLookups auf true setzen
• Wenn der Server Java RunTime >=8u121 sollen die beiden Einstellungen false (ist der Default) sein:
  • com.sun.jndi.rmi.object.trustURLCodebase
  • com.sun.jndi.cosnaming.object.trustURLCodebase

Erkennen von verdächtigen Aktivitäten:

• LDAP und RMI Traffic überwachen
• nicht erforderlichen Traffic nach außen (vor allem LDAP und RMI) unterbinden

Oracle Stellungnahme (aktueller Status, Mi, 15. Dez 17:00):

Oracle hat in den letzten Stunden in der MOS Note Apache Log4j Security Alert CVE-2021-44228 Products and Versions (Doc ID 2827611.1) Informationen zu vielen Oracle Produkten gesammelt zur Verfügung gestellt. In dem Dokument gibt es mehrere Bereiche für

• Patches or Mitigation available … aktuell sind hier ca. 60 Produkte gelistet
• Patches Pending … aktuell sind hier ca. 70 Produkte gelistet
• Products under investigation … aktuell sind hier ca. 50 Produkte gelistet
• Products with impacted underlying Oracle Components … aktuell keine Produkt
• Products not requiring patches … ca. 90 Produkte

Da diese Listen aktuell sehr schnell geändert werden, wird es in den nächsten Stunden sicher entsprechende Anpassungen geben.

Stand Mi, 15. Dez 17:00 ist, dass die Oracle Datenbanken und Oracle Datenbank Client in der Kategorie “Products not requiring patches" zu finden sind. Allerdings gibt's auch problematische Produkte rund um die Datenbank, für die Patches nötig sein werden. Sofern ein Patch verfügbar ist, steht die entsprechende MOS Note dabei.

• Oracle Enterprise Manager Ops Center - MOS note 2828286.1
• Oracle Enterprise Manager - MOS note 2828296.1
• Oracle Data Integrator (ODI) - MOS note 2827929.1
• Oracle JDeveloper - MOS note 2827793.1
• Oracle Spatial and Graph - MOS Note 2828303.1 bzw MOS note 2796575.1
• SQL Developer und SQL Developer Data Modeler - MOS note 2796575.1
• Oracle Reports Developer - MOS note 2827793.1
• Identity Manager und Identity Manager Connector
• Oracle GoldenGate (diverse Komponenten) aber nicht GoldenGate selbst - MOS note 2828058.1

Die MOS Notes enthalten in der Regel manuelle Befehle um einen Mitigation durchzuführen, es handelt sich aus unserer Sicht nicht um echte Patches - diese würden ja eine Version von log4j einspielen, wo das Problem nicht mehr existiert. Aus diesem Grund gehen wir davon aus, dass Oracle - vermutlich in einigen Wochen, mit dem nächsten Critical Patch Update (Mitte Jänner) neue Versionen von log4j ausliefern werden.

Da einige dieser betroffenen Produkte seitens Oracle aber automatisch mit der Datenbank ausgeliefert werden - Beispielsweise SQL Developer, Spatial and Graph - sind somit auf den Oracle Datenbank Servern log4j Versionen (sogar mehrfach und in verschiedenen Versionen) installiert. Aus diesem Grund kann man auch für die Oracle Datenbank Installation keine 100% Entwarnung geben. Zumindest ist die Datenbank selbst nicht betroffen.

Update vom Fr, 17. Dezember 14:00

Oracle beginnt das log4j Thema in die Dokumentation des Critical Patch Updates vom Okt 2021 zu integrieren. Damit man sieht, wo log4j berücksichtigt ist, muss man in der Note einfach nach CVE-2021-44228 suchen. Gleichzeitig hat Oracle heute im Laufe des Tages einige Mitigation-Beschreibungen zuerst offline genommen und dann aktualisiert neu zur Verfügung gestellt - beispielsweise Oracle Enterprise Manager. Die Beschreibungen sind dadurch in der Regel deutlich umfangreicher geworden.

Es gibt inzwischen auch Patches für Datenbank Oracle Homes um dort die log4j zu patchen, die die mit der Datenbank ausgelieferten Produkte (SQL Developer, Spatial and Graph,….) behebt. Die Entwicklung der Patches dürfte gerade im Laufen sein, für Oracle 12.2, 18.16 und 21.4 sind diese verfügbar, für Oracle 19c leider noch nicht.

Update vom Do, 23. Dezember 2021 10:00

• Seit dem 20. Dezember gibt es eine eigene Support Note zum Thema log4j in Oracle Datenbank Installationen - die Datenbank selbst ist ja nicht betroffen. Siehe: Oracle Database and Apache log4j vulnerability CVE-2021-44228 and CVE-2021-45046 (Doc ID 2828877.1). Die verfügbaren Patches sind als aktualisierte/erweiterte Patches des Critical Patch Updates vom Oktober 2021 erschienen. Für Oracle 19c Installationen benötigt man Version 19.11 oder neuer, da Oracle mit den aktuellen CPUs schon länger alle unnötigen Produkte am Server entfernt.
• Oracle hat am 22. Dezember auch Patches für die neue Sicherheitslücke CVE-2021-45105 für WebLogic Server bereit gestellt - siehe Security Alert CVE-2021-44228 And CVE-2021-45105 Patch Availability Document for Oracle WebLogic Server For Oracle Cloud Infrastructure (Doc ID 2828556.1).
• Inzwischen (beginnend mit 22. Dez) gibt es für viele Oracle Produkte auch schon Patches und nicht nur Mitigation Anleitungen. Diese integrieren in vielen Fällen auch schon CVE-2021-45105.
• Lediglich beim Einsatz vom Oracle Enterprise Manager 13c muss man aufpassen. Für dieses gibt es Patches für 13.5, 13.4, 13.3.2 sowie für einige Agent Plugins. Diese gehören umgehend eingespielt!

Somit sollte man beginnen das Patching aller Oracle Produkte kurzfristig einzuplanen.

Analysen von DB Masters zu Oracle nahen Produkten (update Di, 14. Dez 18:00)

• NetApp SnapCenter (zum Sichern der Oracle Datenbanken mittels Snapshot auf NetApp Storages) nutzt ebenfalls log4j-2.x.

Sobald Oracle Patches zur Verfügung stellt, informieren wir sie darüber.