Davon abgesehen denke ich aber auch, dass der "Hype" n bisschen zu groß ist.
Leider Nein.
Ich teste seit heute früh meine Programme - also die von mir geschriebenen Programme - ob die Lücke ausnutzbar ist.
Wenn man natürlich auf 5 Jahre alter Software rum turnt ... ist das was anderes.
Wenn es das wäre...
Aber hier haben wir schon das erste Problem.
Die erste Version, die den Fehler enthielt, kam geschätzt vor zehn Jahren heraus. Mein Projekt von 2012 enthielt jedenfalls schon die betroffene Version 2.1.
Die Version, die den Fehler korrigiert, ist vom 6. 12. 21, also gerade erst ein paar Tage alt.
Es dürfte sich also um eine Zero-Day-Lücke handeln, die schon ausgenutzt wird.
Mit anderen Worten: Alle Projekte, die log4j nutzen, und bei denen in den letzten zehn Jahren einmal die log4j-Bibliothek aktualisiert wurde, sind potentiell betroffen.
M.E. ist das ein Hinweis für kleine Software-Häuser. Bei grossen Software-Häusern - und da würde ich Apple auch mal zu zählen - gehe ich davon aus, dass im CI-/CD-Prozess eine Schwachstellen-Prüfung stattfindet und ein Build nicht möglich ist.
Der CI/CD-Prozess hat Apple und die anderen zehn Jahre lang nicht daran gehindert, diese Lücke im Build einzubauen. Soviel dazu.
Ist es also eher kein Enduser-Thema?
Wenigstens das stimmt. Also reiner Enduser hast du damit nichts zu tun.
Es betrifft dich dann, wenn du bei dir, bei deiner Firma oder auf deinem angemieteten Web-Server einen vom Internet aus erreichbaren Dienst zur Verfügung stellt, über den ein Java-Programm aufgerufen werden kann.
Problem zwei ist, dass die log4j-Bibliothek verdammt weit verbreitet ist.
log4j ist die mit Abstand am meisten genutzte Logging-Bibliothek in Java. Gefühlt wird es von 50% der Java-Programme genutzt. Minecraft zum Beispiel. Und wenn das Programm selbst log4j nicht nutzt, dann womöglich eine eingebundene Bibliothek.
Daher müssen eigentlich alle für Web-Dienste genutzten Java-Programme überprüft werden.
Problem drei ist, dass es sehr trivial sein kann, die Lücke auszunutzen.
Das Vorhandensein der log4j-Bibliothek alleine reicht noch nicht aus. Der Angreifer muss das System dazu bringen, ein von ihm vorgegebenen Text zu protokollieren. Das ist nicht überall möglich. Aber wenn zum Beispiel der Betreiber eines mit Java realisierten Web-Dienstes fehlerhafte Anmeldeversuche protokolliert, dann genügt es für den Angreifer, seinen vergifteten Text als Benutzernamen einzugeben. Die Anmeldung braucht nicht erfolgreich zu sein, aber sie wird (in dem Beispiel) protokolliert, und damit hat der Angreifer das System.
