Hintertür in „liblzma“: Ein Supply-Chain-Angriff über eine Open-Source-Bibliothek

Verschiedene einschlägige Webseiten haben sich mit dem Thema beschäftigt und auch die betroffenen Distributionen benannt. Diese Punkte sollen hier nicht noch einmal im Detail erläutert werden. Es wird lediglich kurz darauf eingegangen, was die Bibliothek macht und wie die Hintertür in die Software gelangen konnte.

Außerdem werde ich auf die Folgen solcher Angriffe eingehen, die vermutlich nicht weniger werden.

Liblzma – eine Kompressionsbibliothek

Die Software, die von der oben genannten Hintertür betroffen war, mag auf den ersten Blick unscheinbar aussehen: Es handelt sich um eine Bibliothek, die sich mit Kompression und Dekompression von Daten im sogenannten „xz“-Format beschäftigt. Viele von uns werden mit diesem Format nicht allzu viel anfangen können. Ich zum Beispiel weiß, dass es dieses Format gibt, doch über die zugehörige Bibliothek habe ich mir vor dem 30. März noch nie Gedanken gemacht.

Allerdings, wie in der Einleitung bereits erwähnt, kommt diese Bibliothek zum Beispiel indirekt in SSH-Servern zum Einsatz. Und nicht nur dort: Liblzma ist Teil einer jeden Linux-Distribution, die auf SystemD basiert. Und das sind heutzutage die meisten, insbesondere die im Unternehmensumfeld verbreiteten Distributionen von Red Hat und Suse. Und über SystemD kann die Bibliothek auf Umwegen in den SSH-Server gelangen.

Wie kam die Hintertür in die Bibliothek?

An dieser Stelle wird es perfide: Das „Einpflanzen“ der Hintertür war ein langwieriger und gut organisierter Prozess. Der Angreifer, der ab 2021 auf Github aktiv war, unterstützte das liblzma-Projekt und schaffte es, dieses Projekt sogar zu übernehmen. Hierzu hatte er Komplizen, die die (ursprünglichen) liblzma-Entwickler unter Druck gesetzt haben. Einmal erfolgreich, erstellte der Angreifer fertige Pakete mit der Hintertür und versuchte, diese bei verschiedenen Distributionen aggressiv zu bewerben.

Was bedeutet dieser Angriff?

Eines vorweg: Diese Lücke in einem Open-Source-Projekt bedeutet nicht, dass Open Source grundsätzlich unsicher ist. Hier ist die quelloffene Natur sogar im Vorteil: Die Hintertür ist aufgefallen, da es möglich war, in den Quellcode zu schauen. Kurz gesagt wurde die Hintertür wie folgt gefunden: Ein Entwickler hatte Performance-Probleme mit SSH-Verbindungen, ging auf die Suche nach den Ursachen und konnte diese sehr genau im Quellcode der Bibliothek finden. Bei einer Closed-Source-Software wäre dieser Ansatz nicht möglich gewesen, und die Hintertür hätte noch lange bestehen können, abhängig von der Herangehensweise der Entwickler.

Insgesamt ist das auch nicht der erste weitreichende Angriff auf ein weit verbreitetes Stück Software. Man denke nur an die Hintertür in Solarwinds-Produkten vor ein paar Jahren. Supply-Chain-Angriffe sind ein durchaus effektives Mittel, Systeme zu kompromittieren.

Jedoch zeigt der Vorfall (mal wieder), dass das schwächste Glied der Kette häufig der Mensch ist. Hätte der Hauptentwickler der Bibliothek dem Druck des Angreifers und seiner „Freunde“ nicht nachgegeben, hätte dieser nie die Kontrolle über das Projekt übernehmen und die Hintertür einbauen können. Das wird eventuell zu mehr Misstrauen in der Open-Source-Community führen. In großen Projekten wird es eventuell weitere Hürden geben, bis der eigene Code in das „Produkt“ einfließt. Das bedeutet mehr Bürokratie, längere Wartezeiten und mehr Frust für einzelne Entwickler, die dadurch vielleicht sogar abgeschreckt werden.

Bei kleineren Projekten ist die Situation eine andere: Hier sind häufig einzelne Entwickler für zentrale Projekte verantwortlich. Dabei impliziert „Entwickler“ nicht zwangsläufig, dass die Arbeit an dem Projekt den Lebensunterhalt sicherstellen kann. In vielen Fällen sind diese Projekte eher Hobbys. Dadurch ist der Entwickler eventuell auch dankbar für Hilfe von außen. Wenn diese aber von außen gesteuert Sicherheitslücken einbaut…

Fazit

Wieder gab es einen Supply-Chain-Angriff, diesmal auf eine wichtige Linux-Bibliothek. Heißt das, Open Source ist unsicher? Nein, im Gegenteil: Die Lücke konnte durch den quelloffenen Ansatz leichter gefunden werden. Bedeutet es, dass die zu einem Projekt Beitragenden genauer beobachtet werden sollten? Leider ja! Macht es das Leben der freiwilligen Entwickler solcher Projekte schwerer? Leider ebenfalls ja. Wird es der letzte Angriff dieser Art sein? Nein.