Die Beinahe-Kernschmelze: Wie ein Hacker beinahe das Internet aushebelte und warum Open Source trotzdem siegte

Es war eine Latenz von einer halben Sekunde, die den beinahe Zusammenbruch der digitalen Welt verhinderte. Ende März 2024 fiel dem PostgreSQL-Entwickler Andres Freund bei einer Routineüberprüfung auf, dass sich sein SSH-Login auf einem Testsystem um etwa 500 Millisekunden verzögerte . Ein scheinbar triviales Problem, dem die meisten von uns keine Beachtung geschenkt hätten. Doch Freund, ein Principal Software Engineer bei Microsoft, wurde misstrauisch. Dieser Moment der Neugierde führte zur Entdeckung einer der ausgeklügeltsten und gefährlichsten Supply-Chain-Attacken in der Geschichte des Internets – einer Hintertür, die einem unbekannten Angreifer den „Generalschlüssel“ für Millionen von Servern weltweit hätte liefern können. Der Vorfall um die XZ Utils Backdoor (CVE-2024-3094) ist nicht nur eine Geschichte von beinahe apokalyptischen Ausmaßen, sondern auch ein tiefgreifendes Lehrstück über die Zerbrechlichkeit und die Stärke des Open-Source-Ökosystems .

Die Wurzeln der Verwundbarkeit: Eine Idee und ihre Feinde

Die Geschichte beginnt nicht im Jahr 2024, sondern in den 1980er Jahren, in einem stickigen Computerraum voller Papierstau. Es ist die Ursprungslegende der Freie-Software-Bewegung, die den Nährboden für das spätere Desaster bereitete. Richard Stallman, damals Forscher am MIT, verzweifelte an einem Laserdrucker von Xerox, der ständig stockte, ohne die Benutzer zu benachrichtigen. Er wollte den Quellcode des Druckertreibers modifizieren, um eine Benachrichtigungsfunktion einzubauen – doch Xerox verweigerte ihm den Zugang. Diese Begegnung mit proprietärer Software und der von ihr erzwungenen Geheimhaltung radikalisierte Stallman. Er erkannte darin nicht die Marotte eines einzelnen Unternehmens, sondern ein „gesellschaftliches Phänomen“, das Kreativität und Zusammenarbeit erstickte.

Aus dieser Wut heraus gründete Stallman 1985 die Free Software Foundation und entwickelte die General Public License (GPL). Seine Vision waren vier grundlegende Freiheiten: Die Freiheit, Software für jeden Zweck auszuführen, sie zu studieren und zu verändern, Kopien zu verbreiten und verbesserte Versionen öffentlich herauszugeben. Das Betriebssystem GNU („GNU is Not Unix“) sollte diese Ideale verkörpern. Jahrelang fehlte ihm jedoch das Herzstück: der Kernel. Diesen lieferte 1991 ein finnischer Student namens Linus Torvalds, der sein ursprünglich privates Projekt „Linux“ nach Stallmans Vortrag unter die GPL stellte. Aus GNU und Linux wurde das Betriebssystem, das heute die Welt antreibt.

Linux ist allgegenwärtig. Es läuft auf den 500 leistungsstärksten Supercomputern, in Atom-U-Booten, Börsensystemen, Krankenhäusern und der überwältigenden Mehrheit der Webserver. Jedes Android-Smartphone basiert auf seinem Kernel. Der Erfolg dieses anarchischen Entwicklungsmodells, bei dem tausende Augen über den Code schauen, nährte lange Zeit das „Linus’sches Gesetz“: „Bei genügend vielen Beta-Testern und Mitentwicklern ist jedes Problem schnell identifizierbar und die Lösung jemandem offensichtlich.“ Doch dieses Gesetz hat eine Achillesferse. Es übersieht die unzähligen kleinen, unscheinbaren Rädchen im Getriebe, die oft von einer einzigen, unbezahlten Person am Laufen gehalten werden.

Der trojanische Kompressor: Die XZ Utils Backdoor im Detail

Ein solches Rädchen war XZ Utils, eine Sammlung von Datenkomprimierungsprogrammen, die auf dem hoch effizienten LZMA-Algorithmus basiert. Entwickelt und über zwei Jahrzehnte fast im Alleingang gepflegt wurde es von Lasse Collin, einem Finnen, für den das Projekt ein unbezahltes Hobby war. Aufgrund seiner hervorragenden Komprimierungsrate verbreitete sich XZ still und leise im gesamten Linux-Ökosystem. Es wurde zu einer versteckten, aber kritischen Abhängigkeit – unter anderem von OpenSSH, dem Werkzeug, das sichere Remote-Logins im Internet ermöglicht und oft als das „Rückgrat der Internet-Wartung“ bezeichnet wird .

Genau hier setzte der Angreifer an, der sich hinter dem Pseudonym Jia Tan verbarg.

Phase 1: Social Engineering und die Übernahme des Projekts (ca. 2021–2023)

Der Angriff war ein Meisterwerk der Geduld und des Social Engineerings. Ab Ende 2021 tauchte Jia Tan in der Entwickler-Mailingliste von XZ auf und reichte zunächst harmlose, aber sinnvolle Patches ein. Diese erste Phase diente dem Vertrauensaufbau .

Dann, im Frühjahr 2022, betraten neue Accounts die Bühne: Jigar Kumar und Dennis Ens. Diese zuvor völlig unbekannten Nutzer begannen, auf der Mailingliste massiv Druck auf Lasse Collin auszuüben. Sie beklagten sich über die schleppende Entwicklung, ignorierten Patches und stellten Collins‘ Hingabe zum Projekt infrage. „Kein Wunder, Fortschritt wird es erst geben, wenn es einen neuen Maintainer gibt“, war der Tenor. Dieser koordinierte Druck, eine klassische Social-Engineering-Taktik mit Hilfe von „Sockenpuppen“, zeigte Wirkung .

Lasse Collin, der offen über seine psychischen Probleme und seine Überlastung sprach, willigte schließlich ein. Im Sommer 2022 wurde Jia Tan Co-Maintainer und übernahm ab 2023 zunehmend die Kontrolle über das Projekt. Er änderte die Kontaktdaten für Sicherheitsmeldungen auf seine eigene E-Mail-Adresse und bereitete so den Boden für die nächste Phase .

Phase 2: Die technische Meisterleistung – Die Hintertür im Verborgenen (2024)

Nach der Machtübernahme konnte Jia Tan seinen Plan umsetzen: eine Hintertür in die Komprimierungsbibliothek liblzma (Teil von XZ Utils) einzuschleusen, die dann von OpenSSH genutzt werden würde. Die Raffinesse lag in der Verschleierung. Der schädliche Code fand sich nicht im öffentlichen Git-Repository, sondern nur in den Tarballs der Release-Versionen 5.6.0 und 5.6.1 .

Die Infektionskette war mehrstufig:

1. Das trojanische Pferd: Ein Skript (build-to-host.m4) im Build-Prozess wurde so manipuliert, dass es eine scheinbar kaputte Testdatei (bad-3-corrupt_lzma2.xz) extrahierte.
2. Die Entschlüsselung: Diese extrahierte Datei war in Wirklichkeit ein weiteres, verschleiertes Skript, das eine zweite Testdatei (good-large_compressed.lzma) decodierte.
3. Die Nutzlast: Aus dieser zweiten Datei wurde schließlich ein binäres Objekt (liblzma_la-crc64-fast.o) extrahiert und direkt in den Kompilierungsprozess von liblzma eingefügt. Diese Binärdatei enthielt die eigentliche Hintertür und war im Quellcode unsichtbar .

Die Hintertür selbst war ein hochkomplexes Stück Code. Sie nutzte eine wenig bekannte Funktion des dynamischen Linkers (IFUNC-Resolver und Audit Hooks), um einen bestimmten Moment im Programmstart von OpenSSH abzupassen – die „Goldlöckchen-Zone“. In diesem winzigen Zeitfenster gelang es ihr, die Adresse der legitimen Authentifizierungsfunktion (RSA_public_decrypt) in der Global Offset Table (GOT) zu überschreiben und durch ihre eigene, schadhafte Version zu ersetzen . Diese Version lauschte auf eine speziell präparierte, mit einem privaten Schlüssel signierte Verbindung. Erkannte sie diesen „Generalschlüssel“, gewährte sie dem Angreifer nicht nur Zugang, sondern erlaubte ihm auch die sofortige Ausführung beliebiger Befehle auf dem Server – und das vor der eigentlichen Authentifizierung . Zusätzlich verfügte die Backdoor über einen „Kill Switch“, eine Umgebungsvariable, die, falls gesetzt, die Hintertür deaktivierte und so eine einfache Überprüfung durch Sicherheitstools verhindern sollte .

Bis Ende März 2024 war die manipulierte XZ-Version bereits in die Vorabversionen mehrerer wichtiger Distributionen eingeflossen, darunter Fedora Rawhide, Debian Testing und Kali Linux . Die Veröffentlichung von Red Hat Enterprise Linux 10 (RHEL 10) stand kurz bevor. Die Welt stand am Abgrund.

Die Rettung in letzter Sekunde: Der Zufallsheld

Dann geschah das, was man nur als digitales Wunder bezeichnen kann. Andres Freund bemerkte die winzige Verzögerung und ließ nicht locker. Er grub tiefer, stieß auf die Valgrind-Warnungen, die Wochen zuvor von anderen als harmlose Fehler abgetan worden waren, und analysierte die verdächtigen Testdateien. Am 28. März 2024 verstand er, was er vor sich hatte: eine hochgradig raffinierte Hintertür. Anstatt den offiziellen Meldeweg über den kompromittierten Jia Tan zu gehen, schrieb er eine E-Mail an die Debian-Sicherheitsliste und veröffentlichte einen detaillierten Bericht auf der öffentlichen Mailingliste oss-security .

Die Nachricht verbreitete sich wie ein Lauffeuer. Ein hektisches Osterwochenende folgte. Die betroffenen Distributionen zogen die verseuchten Pakete sofort zurück, das XZ-Repository auf GitHub wurde offline genommen, und Sicherheitsforscher auf der ganzen Welt begannen mit der Analyse. Freunds Hartnäckigkeit und sein Gespür für das Ungewöhnliche hatten die Katastrophe verhindert.

Die Erleichterung wich schnell unbequemen Fragen. Wer steckte hinter Jia Tan? Die Analyse der Zeitstempel in den Code-Commits ergab ein widersprüchliches Bild. Viele Änderungen wurden in der Zeitzone UTC+8 (Peking) eingespielt, andere wiederum in UTC+2 (Osteuropa). Die Angreifer arbeiteten an chinesischen Feiertagen, aber nicht an Weihnachten. Die Spuren führten in alle und keine Richtung. Die allgemeine Einschätzung von Experten ist, dass es sich aufgrund der Komplexität, der Geduld und der finanziellen Mittel mit hoher Wahrscheinlichkeit um einen staatlich geförderten Akteur handelt – möglicherweise aus Russland (APT29, „Cozy Bear“) oder einer anderen Nation mit hochentwickelten Cyberkapazitäten. Eine definitive Zuordnung wird es wohl nie geben .

Das System am Abgrund: Kontroversen und Zukünftige Implikationen

Der XZ-Vorfall ist mehr als ein einmaliger Hack; er ist ein Weckruf, der tiefgreifende systemische Probleme offenlegt.

1. Die Krise der Maintainer: Burnout als Sicherheitsrisiko

Lasse Collin ist kein Einzelfall. Er ist der Prototyp des unbezahlten, allein kämpfenden Maintainers, auf dessen Schultern die digitale Infrastruktur ruht. Eine Umfrage von Tidelift aus dem Jahr 2024 zeigt, dass 60% der Open-Source-Maintainer unbezahlt arbeiten und 61% ihre Projekte im Alleingang betreuen . Gleichzeitig geben 60% der Befragten an, schon einmal erwogen zu haben, ihre Arbeit ganz aufzugeben. Der Druck durch die Community, die oft ungeduldig und fordernd auftritt, und die zunehmenden Sicherheitsanforderungen führen zu einem gefährlichen Burnout. Jia Tans Sockenpuppen haben genau dieses Muster ausgenutzt. Der XZ-Vorfall hat schmerzhaft vor Augen geführt, dass das Narrativ vom „kostenlosen Bier“ („free as in beer“) in die Irre führt. Open Source ist kostenlos wie ein Welpe, nicht wie ein Freibier . Man muss sich um ihn kümmern, ihn füttern und ihn gesund erhalten – und das kostet Geld und Aufmerksamkeit.

2. Die Grenzen des „Linus’schen Gesetzes“

Der Fall XZ zeigt, dass „genügend Augen“ allein nicht ausreichen. Die Hintertür war so raffiniert versteckt, dass sie einer oberflächlichen Code-Überprüfung standhielt. Der bösartige Code lag nicht im offensichtlichen Quellcode, sondern in binären Testdateien und wurde erst durch einen komplexen Build-Prozess aktiviert. Die Community hat versagt, weil sie nicht dort hingesehen hat, wo der Angreifer sie versteckt hatte. Es brauchte einen zufälligen Umstand (die Latenz) und einen extrem misstrauischen und hartnäckigen Entwickler, um sie zu finden.

3. Die Verantwortung der Industrie

Jahrelang haben Unternehmen aller Größen von Open-Source-Software profitiert, ohne in deren Wartung zu investieren. Der XZ-Zwischenfall hat dieses Modell als unhaltbar entlarvt. Initiativen wie das EU Cyber Resilience Act zwingen Unternehmen nun, die Sicherheit ihrer Software-Lieferketten zu garantieren – auch für die darin enthaltenen Open-Source-Komponenten . Dies könnte endlich zu einem Umdenken und einer nachhaltigen Finanzierung kritischer Infrastrukturprojekte führen. Es entstehen bereits Geschäftsmodelle, die „kommerzielle Betreuung“ („Stewardship as a Service“) für Open-Source-Projekte anbieten, um die Wartung zu professionalisieren und zu zentralisieren .

4. Der Wert von Offenheit

Paradoxerweise wurde die Gefahr durch ein offenes System erst entdeckt. Wäre XZ proprietäre Software gewesen, hätte ein Angreifer eine ähnliche Hintertür einbauen können, ohne dass jemand wie Andres Freund die Möglichkeit gehabt hätte, den Code zu untersuchen. Ein Gerichtsbeschluss oder eine stillschweigende Vereinbarung mit einem Unternehmen hätte genügt, um eine Hintertür für eine Behörde zu schaffen. Die Transparenz und die Möglichkeit zur unabhängigen Prüfung, die Open Source bietet, erweisen sich letztlich als seine größte Stärke – auch wenn sie in diesem Fall erst in letzter Sekunde griff .

Fazit: Mehr als ein Weckruf

Die XZ-Backdoor war ein beinahe apokalyptisches Ereignis. Nur das zufällige Zusammentreffen eines neugierigen Entwicklers mit einer halbsekündigen Verzögerung verhinderte eine Sicherheitskatastrophe ungekannten Ausmaßes. Wir kamen mit einem blauen Auge davon.

Doch die Lehren sind eindeutig. Wir können uns nicht länger auf die selbstlose Aufopferung Einzelner verlassen. Das Open-Source-Ökosystem, das Rückgrat unserer digitalen Zivilisation, ist zu wichtig, um es dem Zufall und dem Burnout seiner Hüter zu überlassen. Es braucht ein neues Gesellschaftsmodell, bei dem diejenigen, die von der Infrastruktur profitieren – Regierungen und Konzerne –, auch in ihre nachhaltige Pflege und Sicherheit investieren. Die Geschichte von XZ ist eine Warnung, aber auch ein Beleg für die Widerstandsfähigkeit des offenen Modells. Die Frage ist nicht, ob ein ähnlicher Angriff wieder passieren wird, sondern wann. Und ob wir dann das nächste Mal einen Andres Freund haben, der uns rettet.

Kategorisierung

• im-rueckspiegel/techarchaeologie: Der Artikel untersucht einen aktuellen Vorfall, bettet ihn aber tief in die historische Entwicklung der Open-Source-Bewegung und ihre Gründungsmythen ein.
• im-kopf/denkwerkzeuge: Er analysiert die Denkweise und die sozialen Manipulationstechniken des Angreifers sowie die kognitiven Prozesse des Entdeckers, was den Vorfall zu einem Paradebeispiel für die Grenzen und Möglichkeiten menschlicher Problemlösung im digitalen Raum macht.

Quellen

1. Akamai. (2024). Alles, was Sie über die XZ Utils Backdoor wissen müssen. [online] Verfügbar unter: https://www.akamai.com/de/blog/security-research/critical-linux-backdoor-xz-utils-discovered-what-to-know [Zugriff am 6. März 2026].
2. Pösch, T. et al. (2025). Wolves in the Repository: A Software Engineering Analysis of the XZ Utils Supply Chain Attack. arXiv:2504.17473.
3. HiSolutions Research. (2024). xz-Backdoor – eine Aufarbeitung. [online] Verfügbar unter: https://research.hisolutions.com/2024/04/xz-backdoor-eine-aufarbeitung/ [Zugriff am 6. März 2026].
4. CNCF TAG Security. (2024). Malicious maintainer introduces sophisticated backdoor in xz. [online] Verfügbar unter: https://tag-security.cncf.io/community/catalog/compromises/2024/xz/ [Zugriff am 6. März 2026].
5. theCUBE Research. (2026). Open Source at Scale Requires Stewardship, Not Assumptions. [online] Verfügbar unter: https://thecuberesearch.com/open-source-at-scale-requires-stewardship-not-assumptions/ [Zugriff am 6. März 2026].
6. CERT-EU. (2024). *Critical Vulnerability in XZ Utils (2024-032)*. [online] Verfügbar unter: https://cert.europa.eu/publications/security-advisories/2024-032/markdown [Zugriff am 6. März 2026].
7. Mallia, M. (2025). *GitHub – mrk336/CVE-2024-3094*. [online] Verfügbar unter: https://github.com/mrk336/CVE-2024-3094 [Zugriff am 6. März 2026].
8. ProHoster. (2024). Retrospective ng backdoor promotion sa xz package. [online] Verfügbar unter: https://prohoster.info/tl/blog/novosti-interneta/retrospektiva-prodvizheniya-bekdora-v-paket-xz [Zugriff am 6. März 2026].
9. Securelist (Kaspersky). (2024). IT threat evolution Q2 2024. [online] Verfügbar unter: https://securelist.com/it-threat-evolution-q2-2024/113669/ [Zugriff am 6. März 2026].
10. Socket.dev. (2024). The Unpaid Backbone of Open Source: Solo Maintainers Face Increasing Security Demands. [online] Verfügbar unter: https://socket.dev/blog/the-unpaid-backbone-of-open-source [Zugriff am 6. März 2026].

Schlagworte

XZ-Backdoor, CVE-2024-3094, Open Source, Supply-Chain-Angriff, Linux-Sicherheit, Jia Tan, Maintainer-Burnout