Ende März gab es einen für viele erschreckenden Sicherheitsvorfall bei der Open-Source Bibliothek Liblzma, die eng verbunden ist mit Linux-Distributionen, die auf systemd basieren. Dieser Vorfall hat in der IT-Welt einmal mehr die Diskussion darüber losgelöst, ob Open Source Lösungen sicher sind und welche Kontrollmechanismen notwendig sind, um sie sicher zu halten. Doch erst einmal zurück zum Anfang. Was war überhaupt passiert?
Die Geschichte hinter des jüngst bekannt gewordenen Sicherheitsfalls
In der Open Source Community gibt es viele Programmierer, die selbstständig und meist unabhängig von größeren Firmen Programme entwickeln. So auch Lasse Collins*, er entwickelte gemeinsam mit einigen anderen von 2005-2008 das .xz Datei-Format. Ähnlich wie ZIP ist das .xz Format eine Komprimierung. Diese kommt vor allem in Linux-Systemen zum Einsatz. Mittlerweile ist das Format so fest im System integriert, dass viele auf Linux basierende Server ohne nicht funktionieren würden.
Wie es in der Community üblich ist, ist der Programm-Code öffentlich einsehbar und wird teilweise auch von anderen weiterentwickelt, indem Patches und Erweiterungen vorgeschlagen werden. So auch bei den von Collins entwickelten xz-Bibliothek.
Am 29. Oktober 2021 entwickelt Jian Tan, so zumindest der Benutzername, einen Patch für Lasse Collins Projekt und fragt öffentlich an, ob dieser in den festen Code übernommen werden kann. Dies geschieht nun in unregelmäßigen Abständen wieder. Parallel dazu setzen andere User, heute geht man von Marionetten-Accounts aus, Collins unter Druck, er möge schneller neue Inhalte entwickeln und die Patches von Jian Tan im Hauptprojekt implementieren. Collins selbst gibt an nicht mehr so viel Zeit zu haben, auch aufgrund gesundheitlicher Probleme.
Durch konstante Weiterarbeit am Projekt erschleicht sich Tan nach und nach des Vertrauen des Ursprungsentwicklers. Am 29. Juni 2022 bekommt Tan schließlich Admin-Rechte und wird somit zweiter Hauptverantwortlicher für Collins Projekt. In der folgenden Zeit beginnt er weitere Patches zu entwickeln und bereitet parallel seinen eigentlichen Plan vor. Am 24. Februar 2024 veröffentlicht Tan dann die neue Version 5.6.0. Das Perfide: in dieser befindet sich bereits die erste Version einer heimlichen Backdoor. Mit dieser kann ein User von außen mittels eines bestimmten Keys auf jeden Servers mit der kompromittierten Version zugreifen, dessen Daten abgreifen und ihn wie gewünscht manipulieren.
Neben dem Debian-Projekt führen auch andere Linux-Distributoren, wie Fedora, Kali-Linux und Arch-Linux, das Update auf die korrumpierte Version durch. Entdeckt wird das ganze durch Andres Freud, dem bei einem Test auffiel, dass der Login über SSH eine halbe Sekunde länger dauerte als üblich.
Durch die Komplexität und den langen Vorlauf wird davon ausgegangen, dass hinter dem Angriff eine professionelle Organisation steckt, über die jedoch zum aktuellen Zeitpunkt nichts bekannt ist. Da ein Großteil aller weltweiten Server auf Linux basieren, ist es erschreckend zu sehen, dass ein solcher Angriff einer unbekannten Gruppe nur durch Zufall und der Aufmerksamkeit einer einzigen Person verhindert wurde. Das hätte auch anders ausgehen können.
Ist Open Source wirklich anfälliger für Sicherheitslücken?
Vielfach gibt es seitdem Diskussionen über Open Source. Viele der ursprünglichen Hobby-Projekte sind mittlerweile ein essentieller Bestandteil in unserer digitalen Landschaft geworden. Das Problem: die ursprünglichen Entwickler haben oft nicht die Kapazität ihre Projekte in der Freizeit unentgeltlich zu betreuen.
Dabei sind die Vorteile von Open Source Programmen sind zunächst offensichtlich. Die Programme kosten nichts und der Code ist öffentlich einsehbar. Dadurch lassen sich leichter Änderungen vornehmen und das Programm kann selbstständig auf Lücken überprüft werden. Während man bei Closed Source nicht weiß, ob die Entwickler beispielsweise noch Mechanismen zur Datenanalyse zu Werbezwecken in ihrer Software verbaut haben, kann man dies bei Open Source innerhalb des Codes selbst prüfen.
Auf der anderen Seite bedeutet dies jedoch auch, dass die Verantwortlichkeiten nicht klar definiert sind. Während bei einer proprietären Lösung in der Regel der Entwickler für die Sicherheit seines Produkts zuständig ist, verschiebt sich die Verantwortlichkeit bei einem Open Source Programm in die Richtung der Gemeinschaft und der Endnutzer. Bei einer aktiven Entwicklergemeinschaft, kann dies sogar von Vorteil sein, da mehr Augen Anfälligkeiten schneller erkennen und fixen können. Bei Closed Source Programmen wie beispielsweise von Microsoft muss man sich hingegen darauf verlassen, dass Sicherheitslücken durch ein festes Team gefunden und geschlossen werden und hat wenig Möglichkeiten den Code selbst zu prüfen. Allerdings wird die Sache schon schwieriger, wenn die Programme älter sind oder, wie beim Fall der xz-Bibliothek der Hauptentwickler nicht die Kapazitäten hat, sein Programm auf aktuelle Gegebenheiten anzupassen. Dann kann es passieren, dass Schadcode in den Hauptcode implementiert wird.
Dadurch, dass Open Source mittlerweile nicht nur weit verbreitet ist, sondern in vielen Bereichen auch als essentielle Grundlage dient, wäre es sinnvoll, neben einer sich selbst regulierenden Gemeinschaft, auch andere Überprüfungsmechanismen zu nutzen. Beispielsweise könnten größere Unternehmen dazu verpflichtet werden, Open Source Programme auf Schadcode zu prüfen, wenn sie diese nutzen. Dabei stellt sich jedoch die Frage nach der Kontrollierbarkeit von solchen Regularien. Andere Stimmen sprechen sich für eine staatliche Prüfung, nebst Zertifizierung aus. Da Open Source kostenfrei der gesamten Bevölkerung zu Gute kommen, wäre es denkbar diese mittels staatlicher Einrichtungen zu prüfen und dann geprüfte Versionen zu veröffentlichen. Dies untergräbt jedoch teilweise den freien Entwicklergedanken, der hinter dem öffentlich zugänglichen Code steht.
Wir denken, dass Open Source genauso viel oder wenig Potential für Sicherheitslücken bietet, wie Closed Source. Das ein oder andere zu verharmlosen und sich in falscher Sicherheit zu wiegen, kann sich als schädlich erweisen. So wie man einer proprietären Software-Lösung nicht uneingeschränkt vertrauen sollte, so ist es genauso wichtig auch bei Open Source Programmen immer einen Sicherheitsblick zu riskieren und eigenverantwortlich zu prüfen, welche Lücken potentiell vorhanden sind. Darüber hinaus ist es sinnvoll, sich in verschiedene Richtungen abzusichern und auf unterschiedliche Kontrollmechanismen zu setzen. Auf diese Weise können Programme sich gegenseitig überprüfen und Anomalien fallen schneller auf. Mit einem guten Notfallplan kann dann entsprechend schnell reagiert werden.