Beinahe ein Generalschlüssel fürs Internet: Hintertür in xz utils [German version]

Warum sich alle so aufregen und was wir aus der Beinahe-Katastrophe lernen können

Ingenieurgewimmel am Kühlturm: Wenn wir Kraftwerke so bauen würden, wie wir Software bauen

Immerhin keine Katastrophe, sondern nur eine Beinahe-Katastrophe: Eine raffiniert versteckte Hintertür in einer sehr weit verbreiteten Open-Source-Softwaresammlung (xz utils) wurde kurz vor ihrem Rollout noch gefunden.

Für den Fall, dass Sie “xz-Backdoor” zwar mittlerweile hundert Mal gelesen haben, aber immer noch nicht so genau wissen, was eigentlich dahinter steckt, hier die Fakten:

Was ist das für eine Hintertür und warum regen sich alle so auf?

• xz utils ist eine Sammlung von Unix-Softwareprogrammen, die Dateien komprimieren können. Die Sammlung ist auf den meisten Linux-Distributionen standardmäßig installiert.
• xz utils wird unter anderem von SSH verwendet, einem sehr weit verbreiteten Linux-Dienst für den sicheren, authentifizierten Remote-Zugriff auf Server.
• Die Hintertür hätte es erlaubt, die Authentifizierung zu umgehen, die bei einem Remote-Zugriff mittels SSH notwendig ist. Auf den betroffenen Servern wäre also Vollzugriff aus der Ferne, inklusive Ausführen von beliebigen Befehlen oder Schadcode (Remote Code Execution) möglich gewesen. Das reicht locker für den maximalen CVSS-Score von 10, den die Schwachstelle CVE-2024–3094 daher auch bekommen hat.
• Damit wäre unautorisierter Remote-Zugriff auf alle im öffentlichen Internet mittels SSH erreichbaren Linux-Server möglich gewesen — eine Art “Generalschlüssel für das Internet”, wie es Volker Zota und Malte Kirchner in der heiseshow ausdrücken. Übertrieben ist das nicht, denn gemäß Shodan gibt es etwa 20 Millionen SSH-Zugänge weltweit, 2 Millionen alleine in Deutschland.

Und warum nur Beinahe-Katastrophe?

• Verschiedene Linux-Distributionen laden aktualisieren Software unterschiedlich schnell herunter, je nach Interesse des Nutzerkreises. Wer unbedingt die neuesten Updates schnellstmöglich (als “rolling releases”) haben möchte (in der Regel brauchen das nur Entwickler der Linux-Betriebssysteme), kann bestimmte Entwicklerversionen (“unstable” Versionen) wählen — da sind die Updates aber manchmal noch nicht ausgereift. Auch die auf Pentests ausgelegte Distribution Kali Linux bekommt die “rolling releases”.
• Für die meisten Anwendungen werden “stable” Versionen verwendet; hier wird neue Software erst nach ausgiebigeren Tests installiert und mehr Augenmerk darauf gelegt, dass Software-Updates die Systemstabilität nicht beeinträchtigen.
• Die Version von xz utils, in der die Hintertür enthalten war, war bislang nur in einigen “unstable”-Linux-Distributionen enthalten. Aaaaber: Sie war kurz davor (genauer: 2 Wochen), auch in die weit verbreiteten stable-Versionen ausgerollt zu werden.
• Andres Freund, ein deutscher Software-Entwickler bei Microsoft in San Francisco, hat die Hintertür bei Wartungsarbeiten entdeckt. Fehlgeschlagene SSH-Logins beanspruchten plötzlich viel mehr Rechenleistung als vorher — das kam ihm seltsam vor. Am 29. März hat er seinen Fund öffentlich gemacht — nachdem er ihn im Rahmen einer “coordinated disclosure” an die Entwickler der Linux-Distributionen Debian, Red Hat gemeldet hatte.

Wie konnte die Hintertür eingeschleust werden?

• Die Softwaresammlung xz utils wurde — wie so viele Open-Source-Projekte, auf denen das gesamte Internet aufbaut — seit Jahren von einem einzelnen Entwickler als Hobby programmiert und aktualisiert.
• Diese Einzelperson litt schon einige Jahre unter Burnout und psychischen Problemen, weshalb er die Hilfe eines Unbekannten oder einer Gruppe von Unbekannten, “Jia Tan”, annahm. “Jia Tan” übernahm immer mehr Aufgaben im Projekt — und programmierte schließlich die Hintertür ein.
• Die Hintertür selbst ist sehr raffiniert eingebaut. Man kann sie nicht im Quellcode finden, sondern nur in der kompilierten, ausführbaren Version der Software.
• Außerdem ist es eine sogenannte NOBUS (nobody but us)-Hintertür. Nicht jeder kann sie nutzen, sondern man braucht einen geheimen Schlüssel dafür. Deswegen vermuten viele einen Geheimdienst hinter dem Angriff.

Was muss ich tun?

Ihre Linux-Server sind mit großer Wahrscheinlichkeit nicht betroffen, es sei denn, Sie haben eine der Entwicklerversionen installiert (Liste hier) und zwischen dem 26.03. und 28.03. ein Update gemacht. Prüfen kann man die Betroffenheit für konkrete Server mit diesem Tool.

Und was lernen wir daraus?

Die Aufregung über die xz-utils-Hintertür ist nicht nur deswegen groß, weil die Schwachstelle so weitreichend gewesen wäre — sondern auch, weil so etwas im Software-Ökosystem, das wir nun mal haben, jederzeit wieder passieren könnte: Niemand hat ein Patentrezept, um solche Katastrophen zukünftig zu verhindern.

Fluch und Segen der Skalierbarkeit von Software

Die Ursache der ganzen Misere ist eigentlich gar kein Problem, sondern eine Vorteil von Software — nämlich ihre Skalierbarkeit: Einmal geschrieben, kann Software beliebig vervielfältigt werden, und damit kann sie eigentlich jeder nutzen. Toll, denn so kann man im Gegensatz zu oft sehr materialintensiven Ingenieurdisziplinen — nehmen wir mal den Bau eines Kraftwerks als Beispiel — mit fast keinem weiteren Materialeinsatz ein Produkt beliebig vervielfältigen.
Stellen Sie sich vor, wenn einer mal einen ordentlichen Kühlturm gebaut hätte, könnten alle anderen Kraftwerke ihn nutzen. Wie praktisch!

Und hier fangen die Probleme an. Schneiden wir sie in Problemscheiben:

1. Komplexität der Software-Lieferkette: Kein Software-Entwickler schreibt jede Zeile Code selbst. Es wäre ja auch haarsträubend ineffizient, wenn jeder das Rad neu erfinden würde. Viel effizienter ist ja, einfach existierende Software zu nutzen, die dieselbe Aufgabe löst. Also ist fast jedes Stück Software ein schier unüberschaubarer Haufen von Software-Stückchen aus verschiedenen Quellen, die alle von verschiedenen Menschen aktualisiert werden — denn Software ist ja nie fertig.
   
   Stellen Sie sich vor, Sie würden so Ihr Kraftwerk bauen. Was für ein Gewimmel von Ingenieuren am Kühlturm!
2. Große Macht und Verantwortung von Einzelpersonen: Wer schreibt eigentlich all diese Software-Stückchen? Gerade bei sehr grundlegender Linux-Betriebssystemsoftware oder Internetprotokollen ist die verwendete Software oft Open Source. Das heißt: Prinzipiell kann erst einmal jeder dazu beitragen. Und oft sind es gerade kleine, unscheinbar scheinende Hobbyprojekte von Einzelpersonen, die extrem viel genutzt werden. Klar — wieso sollte man so ein Detail wie ein Kompressionstool selbst schreiben, wenn es doch schon eins gibt? Das Phänomen ist so bekannt, dass es dazu einen xkcd-Comic mit Kultstatus gibt.
   Auf den Schultern dieser einzelnen, oft unbekannten Personen lastet oft eine große Verantwortung (und damit auch große Macht): Was sie in ihre Software einbauen, nutzen Millionen. Klar, es können auch Millionen daraufschauen, denn der Quellcode ist ja offen und kann von jedem getestet, geprüft und reviewt werden (das wichtigste Argument von Open-Source-Verfechtern). Aber am Ende ist das mehr Prinzip Hoffnung als ein gelenkter Prozess. Andres Freund, der Entdecker der xz-utils-Hintertür, sagt selbst, dass eine Menge Zufall zu seiner Entdeckung beigetragen hat.
   
   Also stellen Sie sich vor, Sie bauen Ihr Kraftwerk — und laden jeden ein, daran mitzubauen, der Lust hat. Sie hoffen einfach, dass alle Mitbauenden ordentliche Arbeit machen — und wenn nicht, dass es die anderen rechtzeitig merken. Nix Vieraugenprinzip.
3. Entwickler können die Einsatzszenarien ihrer Software nicht überblicken: Die umfassende und kostenlose Wiederverwendung von Softwarebibliotheken bedeutet auch, dass kein Programmierer vorhersehen kann, wofür seine Kreationen so eingesetzt werden. Was das bedeutet, versteht man, wenn man Dr. David Clark zuhört, der am MIT in den 70ern die Architektur für das hutige Internet mitgebaut hat. In einem 2011 aufgenommenen Video erzählt er: “Als die Leute gefragt haben, ob wir uns vorstellen konnten, dass das Internet mal Systeme auf der ganzen Welt verbinden würde, haben wir gesagt — klar! Es könnte Zehntausende Systeme im Internet geben! […] Wenn Sie uns damals gefragt hätten, hätten wir wahrscheinlich gesagt, dass es eine ziemliche dumme Idee ist, Teile des Netzwerks für den Betrieb von kritischen militärische Operationen oder kritischer Infrastuktur wie dem Stromnetz an ein öffentliches Network zu hängen. Das tut man einfach nicht!”
   
   Übersetzt in unser Kraftwerksbeispiel hieße das: Sie lassen nicht nur jeden mitbauen — Sie erzählen den einzelnen Ingenieuren auch nicht, was sie da bauen. Die Ingenieure wählen Material für eine Wand aus, ohne zu wissen, ob sie einen Gartenpavillon oder einen Kühlturm bauen — und Sie selbst kümmern sich nicht darum, aus welchem Material ihr Kühlturm ist, solange er nicht zusammenbricht.

Wer kann das alles noch verantworten?

Das Problem ist nicht Open-Source. Das Problem ist nicht, dass Software wiederverwendet wird. Das Problem ist nicht, dass Einzelpersonen Software entwickeln und sie kostenlos zur Verfügung stellen. Das Problem müsste noch nicht einmal sein, dass diese Software dann zum Beispiel für kritische Infrastrukturen genutzt wird.

Das Problem beginnt, wenn niemand mehr die Verantwortung für die Software in kritischen Infrastrukturen übernehmen kann:

• Die Entwickler der Software nicht, weil sie oft sowieso nur ein Hobby betreiben und unmöglich alle Einsatzszenarien vorhersehen können — sie kennen sie ja oft noch nicht einmal.
• Die Betreiber der Infrastrukturen nicht, weil sie weder die Security dieser schieren Masse der genutzten Software kontrollieren können noch die Entwickler in die Pflicht nehmen: Wer Software kostenlos nutzt, kann eben nicht auch noch Ansprüche stellen.

Puh. Wenn das alles keiner verantworten kann — dann sollten wir es vielleicht so tatsächlich nicht machen?
Wenn wir so Kraftwerke oder auch nur Häuser bauen würden, wie wir IT-Systeme bauen….dann schliefen wir wohl alle lieber im Zelt.

Wer verantwortlich handeln will, kann eigentlich nur Software verwenden, deren Security er entweder selbst kontrollieren oder jemanden in die Pflicht nehmen kann. Und ja, das wird definitiv viel teurer als der bisherige Ansatz “kostenlose Software nutzen + Prinzip Hoffnung”.

Der Cyber Resilience Act fordert übrigens genau das: Der Inverkehrbringer eines Produkts haftet für die Security — inklusive aller verwendeten Software-Bibliotheken. Die Praxis wird wohl erst auf längere Sicht zeigen, was das für Software-Sammlungen wie xz-utils bedeutet.

Dieser Beitrag ist als Teil des monatlichen “Security-Briefing für Hard Hats” erschienen. Hier können Sie es abonnieren.