Hinweis: Das ist ein Meinungsartikel.
Ihr habt es gelesen: Eine kritische Schwachstelle in der weit verbreiteten Java-Bibliothek Log4j führt nach Einschätzung des Bundesamts für Sicherheit in der Informationstechnik (BSI) zu einer extrem kritischen Bedrohungslage. Das BSI hat daher seine bestehende Cyber-Sicherheitswarnung auf die Warnstufe Rot hochgestuft. Ursächlich für diese Einschätzung ist die sehr weite Verbreitung des betroffenen Produkts und die damit verbundenen Auswirkungen auf unzählige weitere Produkte. Die Schwachstelle ist zudem trivial ausnutzbar, ein Proof-of-Concept ist öffentlich verfügbar. Eine erfolgreiche Ausnutzung der Schwachstelle ermöglicht eine vollständige Übernahme des betroffenen Systems. Dem BSI sind welt- und deutschlandweite Massen-Scans sowie versuchte Kompromittierungen bekannt. Auch erste erfolgreiche Kompromittierungen werden öffentlich gemeldet.
Die Schwachstelle wurde mindestens seit dem 1. Dezember 2021 aktiv ausgenutzt. Am 6. Dezember wurde die Lücke mit Version 2.15.0 von Log4j geschlossen. Wie lange es dauern wird, bis alle Diensteanbieter ihre Systeme aktualisiert haben, ist nicht bekannt. Die Liste der betroffenen Diensteanbieter ist lang, sehr lang.
Die eigentliche Schwachstelle besteht meiner Meinung nach nicht in der Reaktion des Projektteams, sondern in der Tatsache, dass es viele systemkritische Open-Source-Programme gibt, deren Projekte nicht darauf ausgelegt sind, schnell und umfassend auf Bedrohungen zu reagieren. Oft handelt es sich um einige wenige Mitarbeitende, die eine wichtige Komponente in ihrer Freizeit unentgeltlich pflegen.
Bildquelle: xkcd
Open-Source-Software wie Log4j oder GnuPG und viele weitere werden von kleinen Programmierer-Teams entworfen und gepflegt, die dafür meist nicht bezahlt werden. Solche Komponenten werden gerne als kostengünstige Lösung von grossen Unternehmen, Organisationen und Behörden übernommen, nicht zuletzt, weil sie als de-facto Standard gelten.
Für solche kritischen, aber unzureichend ausgestatteten Projekte wird ein Sovereign Tech Fund benötigt, der mehrere Aufgaben erfüllen könnte:
- Identifikation der systemkritischen FLOSS-Komponenten
- Einzug von Unterstützungsleistungen von Unternehmen, Organisationen und Behörden
- Sicherstellen der professionellen Weiterentwicklung und Wartung dieser Komponenten
Quellen:
https://logging.apache.org/log4j/2.x/changes-report.html#a2.15.0
https://github.com/apache/logging-log4j2
https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
Hallo, ich stehe Frameworks, die deutlich mehr machen als als sie sollten, grundsätzlich misstrauisch gegenüber. Warum muss ein Logging-Framework etwas anderes tun als zu loggen, z.B. mit LDAP reden können? Der Großteil der Entwickler besucht vermutlich nur einen Bruchteil der Funktionen die log4j bietet. Wann immer möglich versuche ich eine schlankere alternative zu finden. Hier z.B. Tinylog, wobei ich natürlich auch nicht bewerten kann ob es sicherer ist. Grundsätzlich biete eine Software mit großem Funktionsumfang vermutlich auch eine größere Angriffsfläche. Ein weiteres Beispiel wäre das Spring-Framework. Es ist zwar anfangs komfortabel zu nutzen, bringt aber viele Abhängigkeiten zu Bibliotheken deren Funktionsumfang auch wieder groß ist...
Die Liste welche sich hinter dem Link "sehr lang" befindet: https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592 enthält Aussagen zu den Produkten, manchmal steht da auch, dass die Produkte eben nicht verwundbar oder betroffen sind.