Hinweis: Dieser Artikel ist älter als 3 Jahre
Inhalte, Quelltexte oder Links können zwischenzeitlich überholt sein.
Hinweis: Dieser Artikel ist älter als 3 Jahre
Inhalte, Quelltexte oder Links können zwischenzeitlich überholt sein.
Hinter der unscheinbaren Bezeichnung CVE-2021-442281 versteckt sich eine schwerwiegende Schwachstelle in der Java-Komponente Log4J2. Der Fehler besteht darin, dass diese Logdaten nicht nur liest oder schreibt sondern auch interpretiert und Anweisungen zum Nachladen von Programmcode ausführt. So wird aus einer Logzeile ein Programm, das im Kontext der jeweiligen Software, des Dienstes oder Anwenders ausgeführt wird. Pauschal kann davon ausgegangen werden, dass in JAVA programmierte Software und alles mit einem Tomcat-Webserver von der Log4J-Schwachstelle betroffen ist. Die Liste der Softwareprodukte ist lang und beinhaltet das Who-is-Who der IT-Branche3. Das BSI ruft gleich Alarmstufe rot aus4 und sogar der Spiegel schreibt von “Scheiße”, die lichterloh brennen würde5.
Und damit sind wir genau bei meinem Schlüsselwort. Aber anders als viele meinen. Nicht die besagte Komponente ist das Problem, die nebenbei erwähnt von einigen Wenigen ehrenamtlich gepflegt wird und von der Welt und vor allem von BigTech nur wenig Wertschätzung erfährt. Es ist die Art und Weise, wie unbedarft Software entwickelt und mit Komponenten und Dependencies umgegangen wird. Das XKCD-Comic Nr. 23476 bringt es prägnant auf den Punkt:
Auch wenn die Zeiten lange vorbei sind, wo ich von JAVA zu sagen pflegte, dass es überall gleich langsam läuft und Swing7 auf allen Plattformen “alien” aussieht, meide ich seit Jahrzehnten instinktiv alles, wo JAVA drin ist und drauf steht. Es ist für mich ein Zombie aus den 90ern, vergleichbar mit Macromedia Flash: Träge, fett und langsam. Ungeeignet zum Rapid Application Developing (RAD)8 weil es alles gleich zur Wissenschaft macht.
Und das bringt uns zu einigen finalen Fragestellungen, wo ich mich jedesmal an den Kopf packe: Warum in der Welt muß eine produktive Software Log- oder Telemetriedaten sammeln und verarbeiten? Dafür gibt es üblicherweise Applikationsserver oder Datenbanken. Warum haben ganz offensichtlich zentrale Dienstprogramme - zum Beispiel die Unify-, Omada- oder vmware-vSphere Infrastrukturtools freien Zugriff zum Internet, von wo aus Zeugs nachgeladen werden kann? Warum packen alle Ihr internes LDAP/AD auf exposed Internet-Hosts? Warum wird immer wieder miserabel programmierte Software mit einer unübersichtlichen Anzahl an Abhängigkeiten und Technologien beschafft und installiert? Komplexität kostet und Best-Practise sieht anders aus.
Lücken in Software und Software-Komponenten können passieren und zählen zum Tagesgeschäft. Die Wucht von Log4J ist selbstgemacht und kommt vom sorglosen Umgang mit Komponenten und Abhängigkeiten. Mein Mitleid hält sich bei sowas in ganz engen Grenzen. Der eigene IT-Technologiestack ist selbstverständlich nicht betroffen.
In diesem Sinne,
Euer Tomas Jakobs
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228 ↩︎
https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592 ↩︎
https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2021/211211_log4Shell_WarnstufeRot.html ↩︎
https://www.spiegel.de/netzwelt/web/log4-j-schwachstelle-ja-leute-die-scheisse-brennt-lichterloh-a-760bd03d-42d2-409c-a8d2-d5b13a9150fd ↩︎
https://xkcd.com/2347/ (CC-BY-SA 2.5 https://creativecommons.org/licenses/by-nc/2.5/) ↩︎
https://de.wikipedia.org/wiki/Rapid_Application_Development ↩︎