Mit starken Worten und Superlativen gilt es in Fragen der Computersicherheit immer sparsam umzugehen, nicht jede schlimm klingende Lücke stellt in der Realität auch eine Bedrohung dar. Bei dem, was nun rund um eine vielgenutzte Open-Source-Komponente bekannt wird, können die Worte aber gar nicht stark genug sein. Geht es dabei doch um den jahrelang vorbereiteten Versuch, eine Hintertür in hunderte Millionen Systeme einzuschmuggeln. Einen Versuch, der nur dank eines einzelnen besonders aufmerksamen Entwicklers gestoppt werden konnte, bevor es zu größerem Schaden kommen konnte.

Unterwanderung

In aktuellen Versionen der xz-utils ist eine Hintertür versteckt, über die Angreifer von außen Systeme übernehmen können, schrieb am Freitag zunächst der Softwareentwickler Andres Freund in einer Mail an die Open Source Security Mailing List. Kurz danach folgten die ersten Warnungen von Linux-Distributionen, die an Deutlichkeit nichts vermissen ließen: Die Nutzer von betroffenen Systemen sollten umgehend deren Nutzung einstellen und die Rechner komplett neu aufsetzen, formulierte es etwa Red Hat drastisch.

Bei den xz-utils handelt es sich um eine jener Softwarekomponenten, die eine wichtige Rolle in der weltweiten Computerinfrastruktur spielen, die der weiteren Öffentlichkeit aber wenig bekannt sind. Die darin enthaltene liblzma wird von zahlreichen anderen Softwareprojekten zum Packen und Entpacken von Daten verwendet. Unbekannten Angreifern ist es nun gelungen, in den veröffentlichten Versionen 5.6.0 und 5.6.1 der xz-utils Schadcode unterzubringen, um über diesen Weg dann die Fernwartungssoftware OpenSSH zu unterwandern.

Wer betroffen ist

Die gute Nachricht dabei: Diese Versionen sind bisher noch relativ wenig verbreitet, bei den großen Linux-Distributionen waren sie zuletzt nur in Testversionen zu finden. Von dem Problem betroffen sind etwa Fedora Rawhide, Debian Testing und Unstable sowie openSUSE Tumbleweed. Die jeweils stabilen Versionen dieser Distributionen laufen hingegen alle noch mit älteren, nicht unterwanderten Generationen der xz-utils.

Im Detail wird es dann schon komplizierter: Wer etwa gerade die aktuelle Beta von Fedora 40 testet, könnte mit etwas Pech betroffen gewesen sein, das entsprechende Update war nur kurz verfügbar. Ebenfalls einige Tage lang ausgeliefert wurde die unterwanderte Version von Kali Linux und Arch Linux.

Reaktion

Das macht auch klar, wie viel Glück die Computerwelt in diesem Fall hatte: Einige Wochen später wären die xz-utils wohl bereits in den stabilen Versionen diverser großer Linux-Distributionen gelandet. Mittlerweile haben all die erwähnten Projekte Updates ausgeliefert, mit denen die unterwanderten Versionen entfernt werden und das System auf eine ältere Version der xz-utils zurückkehrt.

Wer eine der betroffenen Linux/Unix-Distributionen einsetzt, sollte sich überlegen, diese komplett neu aufzusetzen. Zumindest ist aber ein umgehendes Update auf eine sichere Version dringend anzuraten. Ebenfalls kurzfristig wurde die unterwanderte Version der xz-utils via Homebrew unter MacOS ausgeliefert, das von Entwicklerinnen und Entwicklern viel genutzt wird. Andere User sind nach aktuellem Wissenstand nicht betroffen, für die breite Masse an Computerusern besteht also kein Handlungsbedarf, da der Angriff rasch genug gefunden wurde.

Benchmarks als Sicherheitstool

Dass nichts Schlimmeres passiert ist, ist dabei der Performance-Besessenheit des erwähnten Andres Freund zu verdanken. Dem bei Microsoft angestellten PostgreSQL-Datenbank-Entwickler waren bei aktuellen Benchmarks seltsame Ausreißer aufgefallen: Das Einloggen via SSH dauerte plötzlich mehr als doppelt so lang, zudem verbrauchte der SSH-Prozess auch nach erfolgter Authentifizierung unerwartet viel Rechenzeit.

Freund spricht davon, dass der Login "viel" langsamer war, den meisten dürfte das aber kaum aufgefallen sein, ging es hier doch um ein paar hundert Millisekunden mehr. Bei seinen weiteren Analysen stellte er fest, dass über die liblzma Schadcode nachgeladen wurde, der einen installierten OpenSSH-Server unterwandert und den Angreifern einen Fernzugriff auf das System ermöglicht.

Spurensuche

In den vergangenen Tagen hat sich die Sicherheits- und Open-Source-Welt nun auf die Spurensuche gemacht, und was man dabei zutage gefördert hat, ist ziemlich beunruhigend – scheint die Unterwanderung doch nicht nur von langer Hand geplant gewesen zu sein, die Angreifer gingen dabei auch äußerst geschickt vor, um ihre Aktivitäten zu verschleiern. Das beginnt damit, dass die Unterwanderung des xz-utils-Codes nicht über eine klassische Attacke erfolgte, vielmehr wurde das Projekt gezielt unterwandert.

Die Entwicklung der Geschichte lässt sich dabei über öffentlich verfügbare Informationen gut nachvollziehen, der Entwickler Evan Boehs fasst die Eckpunkte auf einer eigenen Webseite zusammen: So hatte der hauptsächlich für die Wartung des Projekts zuständige Entwickler Lasse Collin schon länger über Überlastung und psychische Probleme geklagt. Im April 2022 tauchen dann einige davor und danach nie wieder gesehene Konten auf der Mailingliste von xz-utils auf, die Collin unter Druck setzen, sich einen Co-Maintainer zu suchen.

Kurz davor hat ein unter dem Namen Jia Tan auftretender Entwickler einen ersten – trivialen – Patch für die xz-utils auf der Mailing-Liste gepostet. Es folgen weitere Beiträge, irgendwann macht Collin dann Jia zum Co-Maintainer des Projekts.

Sicherheitstests: Ausgehebelt

In dieser Rolle übernimmt er im Juli 2023 einen vermeintlich harmlosen Code-Beitrag, in Wirklichkeit handelt es sich dabei um erste Vorbereitungsarbeiten für die folgende Unterwanderung. Diese Änderung führt nämlich zu Problemen bei automatisierten Sicherheitstests mit Googles oss-fuzz, die die xz-utils wie viele andere Open-Source-Projekte regelmäßig durchlaufen.

Mittlerweile ist Jia zum offiziellen Kontakt zu oss-fuzz für die xz-Utils aufgestiegen. In dieser Rolle gelingt es ihm nun mit dem Verweis auf die – von ihm selbst eingeführten – Probleme, gewisse Checks für die xz-utils bei oss-fuzz deaktivieren zu lassen. Das offenbar bereits mit dem Blick auf die kommenden Monate, geht es in Wirklichkeit doch darum zu verhindern, dass die Einführung des eigentlichen Schadcodes auffliegt.

Nicht so harmlose Tests und geschickte Tarnung

Anfang 2024 folgt dann der nächste große Schritt. Jia fügt dem Projekt eine Reihe von Tests hinzu, da so etwas durchaus üblich ist, fällt das nicht auf, zumal es sich um Binärdateien handelt und solche Tests üblicherweise ohnehin nicht auf Produktivsystemen ausgeführt werden. In Wirklichkeit verbirgt sich darin bereits jener Schadcode, der später zum Einsatz kommen soll.

Die Tarnung kennt aber noch eine weitere Ebene: In den offiziellen Codeverzeichnissen findet sich nämlich keinerlei Zeile, die diesen Schadcode ausführt. Dieser "Trigger" ist lediglich in den veröffentlichten Tarballs, in denen der Source-Code zum Download angeboten wird, zu finden.

Hier machen sich die Angreifer eine Schwäche in der Open-Source-Praxis zunutze: Während Codebeiträge dank Versionskontrollsystemen wie Git gut nachvollziehbar sind, unterliegt die Erstellung dieser Tarballs den jeweiligen Projektverantwortlichen. Diese machen das auf unterschiedlichen Wegen, standardisierte oder gar reproduzierbare Tools werden üblicherweise nicht genutzt. Das erklärt auch, warum die Unterwanderung der xz-utils zunächst niemandem auffällt.

Druck aufbauen

Bemerkenswert ist aber auch, was sich in den Tagen vor dem Auffliegen der Affäre tut: Jia versucht nämlich gemeinsam mit weiteren – wieder zuvor und danach unbekannten – Accounts Druck auf mehrere Projekte auszuüben, damit diese die neue xz-utils-Generation in ihre nächsten Distributions-Releases aufnehmen.

Belegt ist das etwa bei Debian und Fedora, bei beiden wird damit argumentiert, dass die neue Version Fehler behebt. Das stimmt für die Version 5.6.1 übrigens wirklich, bereinigt diese doch einige Crashes – die allerdings mit der Hintertür in der Version 5.6.0 eingeführt wurden. Auch bei Ubuntu gab es den Versuch, die neue Version noch in die Beta für das in wenigen Wochen zur Veröffentlichung anstehende Ubuntu 24.04 unterzubringen.

Viele Fragen sind noch offen

Zum eigentlichen Schadcode laufen derzeit noch die Analysen, erste Einschätzungen sprechen aber von einer sehr ausgeklügelten Vorgehensweise. So lässt sich die Hintertür nur unter gewissen Bedingungen ausnutzen, reagiert zudem nur, wenn der Angreifer den richtigen, geheimen Schlüssel dafür hat, und tarnt sich sonst geschickt.

Zudem läuft derzeit die Untersuchung von anderen Codebeiträgen, die Jia über die Jahre beigesteuert hat. So wurde bereits eine weitere geschickt getarnte Schwächung der xz-utils-Sicherheit entdeckt. Über das Einfügen eines einzelnen Zeichens – eines Punkts – an der richtigen Stelle wurde verhindert, dass die Sandbox Landlock, und damit eine weitere Schutzmaßnahme, je aktiviert wurde. Auch in einem anderen Projekt, der libarchive, wurde mittlerweile ein "fehlerhafter" Codebeitrag von Jia rückgängig gemacht, der unter gewissen Umständen die Sicherheit geschwächt hat.

Das waren keine Hobby-Hacker

Bleibt die Frage, wer eigentlich hinter alldem steht. Konkrete Zuordnungen sind bei alldem immer schwierig, überhaupt sollte man mit so etwas in diesen Dingen vorsichtig sein, versierte Angreifer wissen gut, ihre Spuren zu verwischen. Die Komplexität der Attacke, der lange Zeitrahmen: All das legt aber nahe, dass es sich dabei um einen staatlichen Akteur handelt.

Rechnet man, auf wie vielen Systemen diese Komponenten zum Einsatz kommen, welch große Rolle gerade Linux im Serverbereich, aber auch auf vielen Client-Systemen einnimmt, lässt es sich nicht anders sagen: Die Computerwelt ist in diesem Fall mit viel Glück an einer Sicherheitskatastrophe vorbeigeschrammt. Dass es ein großer Zufall war, dass ihm all das überhaupt aufgefallen ist, betont übrigens auch der Entdecker der Hintertür, Andres Freund.

Der Vorfall zeigt strukturelle Probleme auf

Doch diese Freude dürfte von kurzer Dauer sein, wirft die Episode doch einige unerfreuliche Fragen auf. Etwa wie es im Jahr 2024 noch immer sein kann, dass auf vielen Millionen Rechnern eingesetzte Komponenten von schwer überarbeiteten Hobby-Entwicklern gewartet werden, obwohl durchaus bekannt ist, dass genau solche Projekte zu einem immer größeren Ziel für Angreifer werden.

So hat etwa Google erst vor wenigen Tagen davor gewarnt, dass solche Drittsoftware angesichts der besseren Sicherheit bei den großen Zielen immer stärker in den Fokus von Angreifern kommt. Und auch im Interview mit dem STANDARD hat Googles Red-Team-Chef und Sicherheitsexperte Daniel Fabian vor einigen Monaten auf die wachsende Gefahr von solchen Supply-Chain-Attacken hingewiesen. Insofern ist es auch nicht überraschend, dass derzeit viele Rufe laut werden, dass große Firmen mehr Verantwortung zur Unterstützung dieser Projekte übernehmen müssen.

Das Unsicherheitsgefühl

Und so erfreulich es ist, dass selbst so gut getarnte Attacken dank Micro-Benchmarks eines einzelnen Entwicklers auffliegen, bleibt doch die Realität: Wäre diese Hintertür performanter, wäre sie wohl noch länger nicht entdeckt worden. Insofern lässt sich auch der Zweifel nicht ganz verdrängen, die Frage, ob Ähnliches nicht schon bei anderen Projekten gelungen ist, ohne dass es bislang aufgeflogen ist. (Andreas Proschofsky, 31.3.2024)