Mitte Dezember war ein unscheinbares Softwarepaket plötzlich in aller Munde. Wenn es ein Java-Logging-Framework selbst auf die Titelseiten der Mainstream-Medien schafft, dann muss etwas Großes passiert sein. Ist es auch. Der Log4Shell-Bug ist tatsächlich eine äußerst ernstzunehmende Sicherheitslücke, die weltweit unzählige Softwaresysteme betrifft, und deren Ausmaß wohl erst in ein paar Monaten bekannt sein wird.
Wie so oft in dieser Zeit ergoss sich insbesondere in sozialen Medien schnell Spott und Häme über dieses weitverbreitete Logging-Framework und deren Entwickler, die „fern jeglicher Qualitätskontrollen Software entwickeln“. Wir bei Cloudflight halten solche Aussagen für gänzlich unangebracht und stellen klar: Ohne Open Source Software würden zahlreiche Unternehmen, insbesondere in der IT-Branche, nicht existieren können – auch Cloudflight nicht. Open-Source Komponenten wie das Spring Framework, Micronaut oder diverse Projekte aus der Apache Software Foundation – ja selbst das OpenJDK selbst – sind zentraler Bestandteil zahlreicher Softwareentwicklungsprojekte.
Laut Snyk nutzen 6 von 10 Entwickler im Java-Umfeld für ihre Hauptapplikationen das Open-Source Spring Framework.
Sehr oft werden diese Libraries von engagierten Entwicklern gewartet und weiterentwickelt, die dafür sehr viel Zeit opfern und nicht bezahlt werden. Die restliche Welt (und auch wir) können diese Pakete kostenfrei verwenden, in Ihre Kundenprojekte integrieren, und damit schlussendlich Geld verdienen. Auch wenn Unternehmen wie Pivotal rund um ihre Frameworks eigene Geschäftsmodelle entwickelt haben – das ganze Spring Ökosystem ist und bleibt für jedermann frei verwendbar.
Dafür darf und soll man – gerade auch in der Weihnachtszeit – einmal “Danke” sagen.
Trotzdem sollte man sich dessen bewusst sein, dass auch vielfach eingesetzte Open Source Software nicht fehlerfrei ist und nicht vor groben Schwachstellen geschützt ist. Der Log4Shell-Bug ist eine ganz grobe Schwachstelle, die man nicht kleinreden darf. Von außen betrachtet ist die Entstehung eines solchen Fehlers oft nicht nachvollziehbar, wenn man jedoch selbst schon seit 15 Jahren in der Softwareentwicklung tätig ist, weiß man, wie schnell so etwas passieren kann.
Gerade das Faktum, dass es sich hier um quelloffene Software handelt, hat hier aber dazu geführt, dass die Schwachstelle überhaupt entdeckt und publiziert wurde, und dass hierfür sehr schnell ein Fix zur Verfügung stand. Auch dafür gebührt den Entwicklern von Log4J Dank.
Nun mussten also sämtliche Verwender von Log4J diese Bibliothek aktualisieren, die Cybersecurity & Infrastructure Security Agency (CISA) hat dafür auch einen Leitfaden zur Verfügung gestellt. Viele Verwender von Software stellt dies jedoch vor eine große Herausforderung, da insbesondere bei Fremdprodukten oft gar nicht so leicht herauszufinden ist, ob die betroffene Bibliothek enthalten ist. Die CISA argumentiert daher für die Etablierung einer „Software Bill of Materials“ (SBOM), einer Stückliste, mit der bei jeder ausgelieferten Software ähnlich wie in der Elektronik alle mitgelieferten Teile aufgelistet werden.
Bei Cloudflight haben wir genau das schon seit einigen Jahren. Jede Softwarekomponente, die in unserer Managed Build Pipeline entwickelt wird, landet inklusive aller Abhängigkeiten in einer gemeinsamen Datenbank, dem DependencyTracker. Diese selbst entwickelte Software hat es uns erlaubt, noch am Morgen des 10. Dezembers, also kurz nach Bekanntwerden der Sicherheitslücke, auf Knopfdruck alle Kundenprojekte zu ermitteln, die die betroffene Komponente verwenden, und die Liste war zum Glück leer, da wir in der Regel bei unseren Java-Anwendungen auf Spring Boot setzen, und hier als Default-Logging-Implementierung Logback zum Einsatz kommt. Nur wenige Minuten nach Bekanntwerden der Schwachstelle konnten wir somit einen Angriffsvektor in mehr als 100 Kundenprojekten ausschließen und Entwarnung geben. Das war Glück, und wäre z.B. Logback auch betroffen gewesen, hätten wir anders reagieren müssen, wir hätten aber auch in dem Fall vollständige Transparenz gehabt. Übrig blieben noch eingesetzte Fremdprodukte wie z.B. ElasticSearch, bei denen zwar die Möglichkeit eines Angriffs vergleichsweise niedrig war, wir aber trotzdem schnell Updates eingespielt haben. Log-Einträge aus mehreren Produktionssystemen haben auch gezeigt, dass sehr schnell versucht wurde, diese Schwachstelle auszunutzen. Wir – und somit auch die von uns betreute Kundenprojekte waren jedoch geschützt.
Laut CPR stieg die Zahl der erfassten Angriffsvektoren innerhalb von 3 Tagen auf über 800 000.
Wir nutzen den DependencyTracker übrigens nicht nur dazu, Fremdpakete mit Sicherheitslücken aufzuspüren, sondern auch um sicherzustellen, dass die Lizenzen aller verwendeten Bibliotheken eine Verwendung in kommerziellen Projekten erlauben.
Die OpenSource-Community hat uns sehr viel gegeben, und daher haben wir als Cloudflight schon im Herbst beschlossen, dass auch wir der Community etwas zurückgeben wollen, und dazu wird es im neuen Jahr hier an dieser Stelle Updates geben, wer es bis dahin nicht mehr erwarten kann, kann schon mal auf unserem Github-Account schmökern.
Bis dahin wünschen wir euch allen frohe Weihnachten und insbesondere an alle jene da draußen, die mit ihrem Einsatz die OpenSource-Welt verbessern, ein paar geruhsame Tage und noch einmal ein großes Danke!