Kein Aprilscherz: XZ-utils gezielt kompromittiert

Als diese Meldung heute morgen über die Kanäle ging, musste ich mehrmals nachschauen, ob wir nicht den 1. April haben. Durch eine mutmaßlich bösartige Übernahme der Entwicklung wurde xz-utils gezielt kompromittiert. Betroffen sind die aktuellen Versionen 5.6.0 und 5.6.1 und wichtige Distributionen wie Debian, Fedora oder openSUSE.

Das Paket XZ-utils (früher als LZMA-Utils bekannt) ist eines dieser zentralen Hintergrundtools der freien Softwarewelt. Wer seine Paketverwaltung nicht genau im Blick hat, bemerkt diese kleinen zentralen Bausteine, auf denen die Distributionen fußen gar nicht mehr. Es handelt sich um einen Datenkompressionsalgorithmus (vergleichbar zu gzip). Diese Werkzeuge sind wichtig, aber chronisch wenig beachtet und damit ein ideales Einfallstor.

Die gute Nachricht vorweg: Da das Problem sehr schnell bekannt wurde, sind nur sehr aktuelle Distributionen betroffen, d.h. primär Rolling-Release-Distributionen und aktuelle Entwicklungszweige wie Fedora 40. In Ubuntu 24.04 konnte das Paket nicht erfolgreich platziert werden. Die gängigen Enterprise-Distributionen sind aufgrund der deutlich längeren Entwicklungszeit nicht betroffen. Hier erweisen sich stabile Distributionen mit langen Supportzeiträumen mal wieder als überlegen, weil neue Versionsstände dort erst nach mehreren Jahren Einzug halten. Das schützt nicht hundertprozentig vor solchen Fehlern, lässt aber mehr Zeit für die Entdeckung dieser Probleme. So wie das aktuell der Fall ist. Der Code ist gegenwärtig nicht öffentlich einsehbar, da das Quellcode-Repo auf GitHub nach Bekanntwerden des Problems durch Microsoft gesperrt wurde.

Die Schadsoftware öffnet eine Backdoor und lässt potenziell einen unbefugten Fernzugriff via SSH zu. Die Lücke ist kein Versehen, sondern wurde bewusst eingebaut und verschleiert. Der verantwortliche Entwickler hat offensiv versucht, die schadhafte Version in zentrale Distributionen zu bringen. Das zeigt der entsprechende Launchpad-Eintrag für Ubuntu. Um die Lücke auszunutzen ist eine Kette an Voraussetzen notwendig, wie z.B. eine x86-64 Architektur, die Verwendung von glibc und das Paketformat DEB oder RPM. Die Funktionsweise hat Viktor Garske in seinem Blog sehr anschaulich erklärt. Alles nicht besonders exotisch. Der aktuellen Informationsstand kann bei GitHub nachgelesen werden. Einige Fragen sind noch offen und müssen geklärt werden. Es ist gut möglich, dass noch andere Angriffsvektoren bekannt werden. Klar ist aber schon, dass das Bedrohungspotenzial immens ist.

Das Ziel der Angreifer war es vermutlich, unbemerkt einen zentralen Baustein der Linux-Distributionen anzugreifen. Die Fokussierung auf RPM- und DEB-basierte Distributionen legt den Schluss nahe, dass verbreitete Server-Distributionen das Ziel waren. Das ist keineswegs abwegig, denn wäre die Lücke nicht durch Performanceprobleme bei aktuellen Entwicklungsversionen aufgefallen, dann wäre sie mittelfristig in die Enterprise-Systeme eingeflossen. In wenigen Jahren wären diese Systeme dann angreifbar gewesen.

Der Angriff trifft die Open-Source-Entwicklung an einigen ihrer wunden Punkte. Viele Projekte werden von kleinen Teams oder sogar nur durch einzelne Entwickler gepflegt. Das liegt an der chronischen Unterfinanzierung der zentralen Projekte, an der mangelnden Attraktivität, sich in diesen Hintergrundprojekten zu engagieren und manchmal auch an den rauhbeinigen Maintainern, die nicht gerade zur Mitarbeit einladen. Hier scheint sich ein neuer Akteur über Jahre eine Reputation aufgebaut zu haben, den bis dahin zuständigen Maintainer mittels Druck an die Seite geschoben und erst dann den komplexen Schadcode eingebaut zu haben. Eine Überprüfung durch mehrere Augen scheint nicht stattgefunden zu haben. Der frühere Hauptentwickler ist derzeit nicht erreichbar, was aber wohl schon öfter vorgekommen ist. Ein weiteres Problem ist der Unterschied zwischen dem Code auf GitHub und den Release-Tarballs. Das passiert häufiger als man denkt. Der offen sichtbare Code hat dann keine Schwachstelle, der Code im Tarball aber schon. Reproduzierbarkeit ist deshalb seit vielen Jahren ein wichtiges Thema in der Linux-Gemeinschaft.

Das Problem darf nicht verharmlost werden und muss weiter aufgearbeitet werden. Die große Katastrophe blieb aus, weil der Schadcode nicht in die Enterprise-Versionen gelangte und schnell erkannt wurde. Der Vorfall legt aber einmal mehr den Finger in die offenen Wunden der Open-Source-Entwicklung. Prinzipiell lassen sich mit einem solchen Vorgehen viele Projekte mit recht hoher Erfolgswahrscheinlichkeit infiltrieren. Kleine Teams, wenig Kontrolle, unterschiedliche Code-Stände im Repostitorium und Release – alles bekannte Probleme. Durch seine große Bedeutung für die Infrastruktur ist Linux ein Hochwertziel, das solchen Aufwand für die Angreifer vermutlich rechtfertigt.