Kommentar zu Log4j: Es funktioniert wie spezifiziert
Über den Java-Slogan "Write Once, Run Everywhere" wurden schon viele Witze gemacht. Den log4j-Exploit behandeln viele nun wie einen Bug – aber das ist er nicht.
(Bild: Victor Moussa/Shutterstock.com)
- Kristian Köhntopp
Eine kritische Lücke in der Java-Bibliothek Log4j beherrscht gerade die Schlagzeilen. Die IT-Welt ruft "Warnstufe Rot" aus – weil offenbar der log4j-Code JNDI-Variablenexpansion vornehmen kann.
Doch was ist JNDI? Jindi al Dap ist der Name eines alten arabischen Philosophen und Mathematik-Pioniers, der für Sun/Oracle gearbeitet hat, um ein System von Directory Lookups in Java zu entwickeln. Dieses System lädt irgendwie Code aus dem Internet nach. Aber selbst, wenn man länger auf das Systemdiagramm starrt, erkennt man nicht unbedingt sofort, an welcher Stelle sich der Java CLASSPATH so erweitert, dass er das gesamte Internet umfasst:
Nichts ist jemals simpel
Das ist so, weil in Java nichts jemals simpel ist. Java Code ist unstrukturierter trockener Staub von Codefragmenten in Klassendateien, die inert in keiner Weise miteinander interagieren. Erst mit den passenden Factories, Delegates, Generators und ClassLoaders werden sie instanziiert und zusammengesetzt. Der entstehende Haufen an Querverweisen führt dann nur zufällig irgendwann einmal tatsächlich wirksamen Code aus.
Man könnte jetzt auf die Idee kommen, eine IDE mit integrierter syntaktischer Codesuche zu verwenden, um diesen Quelltexthaufen in Form zu bringen und zu verstehen. Aber das ist vergebens: Auch mit der gesamten Codebasis und einem Index darauf kann man nicht vorhersagen, was eine gegebene Java Codebase tun wird, wenn man sie startet. Es braucht auch noch Konfigurationsdateien. Diese sind ein weiterer Haufen, Properties-Dateien, in einem vorsintflutlichen Vorläufer von YAML geschrieben: XML.
Oder jedenfalls ist das, was wir denken sollen: Mit den Properties und der Codebasis können wir endlich versuchen zu verstehen, was Java tut. Und das wäre auch beinahe so, aber JNDI ist genau angetreten, dieses Problem zu beheben: Directory Lookups!
Statt also die Anwendung und ihre Konfiguration zu paketieren und dann die Pakete in Produktion zu installieren, können wir nun mit JNDI die Konfiguration vom Netz lesen. Das heißt, die eigentlichen Konfigurationsdateien, die uns sagen, was die Anwendung tut, sind... nicht mehr da. Fortschritt!
Das stellt sicher, dass uns niemand mehr hacken kann, weil niemand den Code mehr versteht: Wichtige, zum Verständnis der Codebasis notwendige Informationen sind versteckt in einem Verzeichnisdienst, und wir wissen nicht mal welcher. Aber wir können das noch einen Schritt weiterspielen: Der Code, der den Directory Lookup vornimmt, ist auch nicht da, nur ein Bootstrap: Event and Service Provider Packages.
Dank JDNI SPI können wir also Java Classfiles von einem LDAP-Server ausliefern lassen, die angeblich ein Printer-Object generieren, wenn wir nach einem Printer fragen – dann aber stattdessen Doom installieren. Oder einen Kryptominer oder Verschlüsselungstrojaner. So geht Enterprise Security.
Der Java-Slogan ist ja "Write Once, Run Everywhere". Wir haben da viele Witze drüber gemacht, weil Java so oft gecrashed ist – die meisten Java-Anwendungen liefern inzwischen ja die gesamte Ausführungsumgebung einschließlich der JRE mit, damit überhaupt etwas funktioniert. Jetzt funktioniert endlich mal alles – und die Leute sind wieder unglücklich.