Die XZ-Backdoor CVE-2024-3094

Am 29. März 2024 setzte ein Angreifer eine aufwendige, langfristig angelegte Kampagne um, um eine Backdoor in der Linux-Softwarebibliothek liblzma zu platzieren und über Linux-Distributionen Zugriff auf mehrere Betriebssysteme zu erlangen – und war damit vermutlich erfolgreich, bis ein aufmerksamer Engineer einen Fehler bemerkte.

Derzeit bekannte betroffene Upstream-Software und vorgeschlagene Abhilfemaßnahmen:

Was ist XZ?

XZ, auch als XZ Utils bekannt, bietet eine Befehlszeilenschnittstelle für Komprimierungs- und Dekomprimierungsfunktionen und ist häufig bereits in Linux-Distributionen wie Debian, Ubuntu und vielen anderen enthalten.

// Example usage of XZ for context:
$ xz llm_rag_context.json

// Results in a new compressed file on disk:
$ ls -al llm_tag_context.json.xz
.rw-r--r--   81k lirantal 31 Mar 10:29   -N  llm_tag_context.json.xz

Was ist Liblzma?

Liblzma ist die Softwarebibliothek, die den LZMA-Komprimierungs- und Dekomprimierungsalgorithmus implementiert und Sprachbindungen für andere Programmiersprachen bereitstellt, die damit arbeiten, beispielsweise für das xz-CLI-Programm.

Was ist CVE-2024-3094?

Die Schwachstellenkennung CVE-2024-3094 wurde am 29. März 2024 veröffentlicht, um den kritischen Schweregrad von 10,0 für das Paket liblzma abzubilden.

Laut CVE-Bericht geht das Sicherheitsrisiko auf bösartigen Code zurück, der in der Softwarebibliothek liblzma entdeckt wurde. Dieser ermöglichte Änderungen an Daten bei der Interaktion mit dem Code der Bibliothek, wodurch die Integrität verloren ging und schwerwiegendere Folgen drohten.

Welche Auswirkungen hat die XZ-Backdoor?

Das SSH-Protokoll und die zugehörigen Tools ermöglichen unter Linux den Fernzugriff zwischen Hosts. Da die XZ-Backdoor das Abfangen und Verändern von Daten ermöglicht und einige Linux-Distributionen liblzma für das SSH-Programm verfügbar machen, können wir zunächst davon ausgehen, dass eine mögliche Auswirkung von CVE-2024-3094 die Umgehung der Authentifizierung im Programm sshd ist.

Einfach ausgedrückt könnte eine Person mit einem RSA-Schlüssel sich remote bei jedem offenen SSH-Server mit Backdoor authentifizieren.

Inzwischen wird vermutet, dass die XZ-Backdoor die Remotecodeausführung ermöglichen könnte. Die laufenden Untersuchungen analysieren den in liblzma platzierten Backdoor-Code und verfolgen sämtliche Beiträge zurück, die mit dem beteiligten Angreifer in Verbindung stehen.

Der zeitliche Ablauf im Überblick:

• Die bösartige Build-Datei wurde am 24. Februar 2024 zu Debian xz-utils hinzugefügt.

• Die Version 5.6.0 des xz-utils-Tarballs wurde am 24. Februar veröffentlicht, Version 5.6.1 am 9. März 2024.

• Version 5.6.0 wurde am 27. Februar 2024 zu Fedora hinzugefügt.

Die Geschichte der XZ-Backdoor

Am 29. März 2024 wurde eine schwerwiegende Sicherheitsverletzung gemeldet: Andres Freund, ein Beitragender zur oss-security-Mailingliste von Openwall, gab eine mögliche Kompromittierung der Bibliothek liblzma bekannt, die Teil des weitverbreiteten XZ-utils-Pakets ist.

Freund war darauf aufmerksam geworden, weil der Prozess sshd ungewöhnlich viel CPU-Leistung beanspruchte. Das veranlasste ihn zu einer genaueren Untersuchung.

Im Zentrum des Problems stehen bösartig präparierte komprimierte Testdateien, die in den liblzma-Versionen 5.6.0 und 5.6.1 eingebettet waren. Sie sollten über Änderungen am Konfigurationsskript der Tar-Dateien eine Backdoor einrichten. Der Exploit bleibt unter normalen Bedingungen inaktiv, wird jedoch auf Systemen mit einem bestimmten Patch für den SSH-Server aktiviert. Dadurch lässt sich die Authentifizierung von sshd umgehen und unbefugter Fernzugriff auf das System erlangen.

Der folgende Screenshot stammt aus Andres' XZ-Malware-Analyse, die an die Openwall-OSS-Security-Mailingliste gesendet wurde:

Dieser ausgefeilte Exploit nutzt den glibc-Mechanismus der GNU C Library, allgemein als IFUNC bekannt, um einen Resolver für die Methode crc64_resolve hinzuzufügen. Dieser installiert einen Audit-Hook, der die Funktion RSA_public_decrypt in OpenSSH durch eine kompromittierte Variante ersetzt. OpenSSH benötigt normalerweise kein liblzma. Der Exploit nutzt jedoch eine Situation mit verketteten Bibliotheken aus: Ein Patch eines Drittanbieters veranlasst das Laden von libsystemd, wodurch anschließend die betroffene Softwarebibliothek liblzma geladen wird. Zum Zeitpunkt der Erstellung dieses Artikels betrifft die Backdoor sshd nur in einer Teilmenge der Linux-Distributionen, die diesen Patch anwenden, um systemd-Benachrichtigungen zu aktivieren.

Besonders heimtückisch an diesem Angriff war die Einführung einer geänderten Datei build-to-host.m4 in der auf GitHub gehosteten Tar-Veröffentlichung. Sie fehlte im Git-Repository und ließ sich daher nicht auf ihren Ursprung in der Versionsverwaltung zurückführen.

Diese M4-Build-Datei extrahiert und injiziert den bösartigen Code während des Build-Prozesses auf bestimmten Systemen: x86-64 Linux-Plattformen mit glibc und GCC, erstellt mit dpkg oder rpm – beliebten Paket-Build-Tools für Debian- und Red-Hat-Linux-Distributionen.

Infolge dieses Angriffs archivierte GitHub das Repository mit XZ utils wegen eines Verstoßes gegen die Nutzungsbedingungen. Die Untersuchung der Ursprünge der Backdoor deutet auf Jia Tan hin, einen Maintainer des xz-Projekts. Es ist jedoch unklar, ob die Tat beabsichtigt war oder das Konto des Maintainers kompromittiert wurde. Die tatsächliche Identität hinter diesem Maintainer-Konto muss noch festgestellt werden.

Dieser Supply-Chain-Angriff betraf mehrere Linux-Distributionen, darunter Debian 13 und unstable, Fedora Rawhide, Fedora 40, Kali Linux und OpenSUSE Tumbleweed. Arch Linux forderte seine Nutzer auf, umgehend Updates zu installieren. Die meisten Distributionen mit einem stabilen Update-Zyklus blieben verschont, da sie ältere, nicht betroffene XZ-Versionen verwendeten. Auch FreeBSD ist nicht betroffen, da dort XZ-Versionen aus der Zeit vor dem Vorfall enthalten sind und der Angriff auf Linux-Distributionen mit glibc abzielte. Wenn Sie hingegen beispielsweise die Bereitstellung Ihrer Container-Images automatisiert und dabei die neuesten verfügbaren Updates von Fedora oder Debian verwendet haben, würden Sie das anfällige XZ-Programm ausliefern.

Der Vorfall wird unter CVE-2024-3094 geführt und hat mit einem CVSS-Score von 10 die höchstmögliche Bewertung. Er unterstreicht die entscheidende Bedeutung der Supply-Chain-Sicherheit und die Komplexität, Vertrauen in Open-Source-Beiträge aufzubauen und diese zu verifizieren.

Schäden beheben: Die Bereinigungsaktion für XZ

Als sich die Ereignisse entfalteten, beeilte sich Lasse Collin, der ursprüngliche Maintainer der XZ-Utils-Bibliothek, einen Fix für den Build-Konfigurationscode der Softwarebibliothek einzureichen. Dieser Code-Diff zeigt, wie raffiniert und aufwendig der Angreifer bei seiner Backdoor-Kampagne vorging. Das Punktzeichen (.) verursachte einen Fehler im Build-Tool, wodurch dieses eine Sicherheits-Sandbox deaktivierte und Sicherheitskontrollen umging.

XZ-Schwachstelle mit Snyk erkennen

Mit Snyk gibt es verschiedene Möglichkeiten, die XZ-Schwachstelle kostenlos zu erkennen. Mit der Snyk CLI können Sie Ihre Projekte lokal testen:

• Führen Sie für Anwendungen in der Snyk CLI den Befehl snyk test --unmanaged aus, um nicht verwaltete Abhängigkeiten in Ihrem Repository zu prüfen und einzelne Pakete sowie deren Schwachstellen zu erkennen.

• Führen Sie für Container snyk container test aus, um unterstützte Betriebssystempakete zu erkennen, die von anfälligen XZ-Versionen abhängen.

Sie können auch einen Scan aller Projekte in Ihren Git-Repositories durchführen lassen. So erhalten Sie einen Bericht über alle direkten und transitiven Abhängigkeiten, die Sie verwenden. 

In diesem Bericht sehen Sie, ob Sie von XZ abhängig sind und über wie viele Pfade in Ihrem Abhängigkeitsgraphen es verwendet wird. Sie können auch alle Projekte schnell nach „CVE-2024-3094“ durchsuchen. 

Die Schnittstelle von Supply-Chain-Sicherheit und Open Source

Die XZ-Backdoor hat in der Open-Source- und Cybersicherheits-Community für Aufsehen gesorgt und Debatten sowie Bedenken hinsichtlich der Integrität von Open-Source-Software und der allgegenwärtigen Risiken von Supply-Chain-Angriffen ausgelöst. Der Vorfall erinnert eindringlich an den SolarWinds-Angriff und die zahlreichen bösartigen Pakete, die in Software-Registries wie npm und PyPI entdeckt wurden. Er verdeutlicht ein Muster von Supply-Chain-Schwachstellen mit weitreichenden Folgen für die globale Cybersicherheit.

Jia Tan, bekannt unter dem GitHub-Handle JiaT75, und zugehörige Identitäten wie Jigar Kumar und Dennis Ens stehen für eine ausgefeilte, mehrjährige Kampagne, mit der bösartiger Code in XZ Utils eingeschleust wurde – ein unverzichtbares Software-Tool, das in zahlreichen Linux-Distributionen zum Einsatz kommt. Die Taktiken reichten von zunächst harmlos wirkenden Beiträgen bis hin zu direktem Druck auf Projekt-Maintainer, um Commit-Zugriff zu erhalten. Dabei kamen sowohl technische Methoden als auch Social Engineering zum Einsatz, um das Vertrauen und den kollaborativen Charakter der Open-Source-Community auszunutzen.

Die Vorgeschichte von Jia Tans Beteiligung an XZ Utils, die mit verdächtigen Aktivitäten in anderen Projekten wie libarchive begann, zeichnet ein komplexes Bild vorsätzlicher Handlungen, die der Entdeckung von CVE-2024-3094 vorausgingen. Dazu gehören der Aufbau einer Testinfrastruktur und gezielte Versuche, die bösartige Absicht durch den missbräuchlichen Einsatz von ifunc-Implementierungen zu verschleiern. Diese Vorgehensweise zeugt von erschreckender Weitsicht und Manipulation.

Dieser Vorfall wirft grundlegende Fragen zur Nachhaltigkeit von Vertrauen und Sicherheit in Open-Source-Software auf. Die Offenheit von Open Source und die Abhängigkeit von Beiträgen aus der Community werden zur Achillesferse, wenn Angreifer mit Schädigungsabsicht eindringen. Der Vorfall macht auch auf den erheblichen Stress und die psychischen Belastungen von Maintainerinnen und Maintainer aufmerksam, die ihre Zeit und ihr Fachwissen oft ehrenamtlich und unter großem Druck einsetzen, um Projekte sicher und aktuell zu halten.

Die Parallelen zu früheren Vorfällen – etwa dem weitreichenden SolarWinds-Angriff oder der anhaltenden Flut vergifteter Pakete in öffentlichen Software-Repositories – sind unübersehbar. Allen gemeinsam ist die Ausnutzung von Vertrauen und die Komplexität moderner Software-Supply-Chains. Sie führen uns eindrücklich vor Augen, wie ausgefeilt Cybergegner vorgehen und welche Schwachstellen in den digitalen Infrastrukturen stecken, auf die wir zunehmend angewiesen sind.

Angesichts von CVE-2024-3094 und früheren vergleichbaren Vorfällen müssen die Open-Source-Community und die gesamte Technologiebranche ihre Sicherheitspraktiken bei der Softwareentwicklung und -verteilung neu bewerten und verstärken. Dazu gehören eine genauere Prüfung von Beiträgen, robustere Verifizierungsprozesse für Maintainer und eine stärkere Zusammenarbeit bei bewährten Sicherheitspraktiken. Außerdem braucht es dringend nachhaltige Finanzierungsmodelle für Open-Source-Projekte, damit Maintainer über die Ressourcen und Tools verfügen, die sie benötigen, um ihre Software wirksam abzusichern.

Während wir die Folgen dieses und ähnlicher Vorfälle bewältigen, müssen wir offen und kritisch darüber diskutieren, wie sich das Open-Source-Ethos mit den notwendigen Sicherheitsanforderungen vereinbaren lässt. Die Widerstandsfähigkeit von Open-Source-Software und des gesamten digitalen Ökosystems hängt davon ab, ob wir gemeinsam unsere Abwehrmaßnahmen anpassen und stärken können, um uns gegen diejenigen zu schützen, die es untergraben wollen.

Wer ist Jia Tan? Handelt es sich um eine Einzelperson oder einen von einem Nationalstaat unterstützten Angreifer? Welche anderen Projekte wurden möglicherweise kompromittiert und mit Backdoors versehen? Sicherheitsforscher und Entwickler verfolgen aktiv die Spuren von Jia Tans Git-Commits, deren Ursprung, Zeitzone und alle weiteren Informationen, die sie zusammentragen können, um die Puzzleteile zusammenzusetzen.

Wie SBOMs helfen können, CVE-2024-3094 einzudämmen

• Eine Software Bill of Materials schafft Transparenz über Softwarekomponenten und Versionen, auch bei transitiven Abhängigkeiten.

• SBOMs helfen dabei, den Fortschritt von Abhilfemaßnahmen nachzuverfolgen und sicherzustellen, dass alle betroffenen Projekte korrigiert werden.

• Nach der Aktualisierung können SBOMs dazu dienen, nachzuweisen, dass die erforderlichen Patches oder Fehlerbehebungen erfolgreich angewendet wurden.

Wie geht es weiter?

• Folgen Sie den Empfehlungen in diesem Bericht der Cybersecurity & Infrastructure Security Agency (CISA) zu Updates für CVE-2024-3094

• Prüfen Sie Ihre SBOM mit dem SBOM Checker von Snyk

• Lesen Sie dieses Update von Dark Reading