Kompromittierung von SSH-Servern durch eine Backdoor im Upstream-Stream von xz/liblzma

• Bei Debian-sid-Installationen wurden einige ungewöhnliche Symptome im Zusammenhang mit liblzma (Teil des xz-Pakets) beobachtet, darunter erhöhte CPU-Auslastung bei SSH-Logins und valgrind-Fehler.
• Als Ursache des Problems wurde festgestellt, dass das Upstream-Repository und die Tarballs von xz mit einer Backdoor infiziert waren. Ein Teil der Backdoor ist nur in den veröffentlichten Tarballs vorhanden.
• Das im Tarball enthaltene Skript wird am Ende von configure ausgeführt und modifiziert unter bestimmten Bedingungen $builddir/src/liblzma/Makefile, um bösartigen Code einzuschleusen.

Backdoor im Repository

• Der Hauptteil der Backdoor liegt im Verzeichnis tests/files des Repositorys in verschlüsselter Form vor.
• Diese Dateien wurden in den Tests der Version 5.6.0 nicht verwendet; in Version 5.6.1 gab es offenbar einen Versuch, durch die Backdoor verursachte valgrind-Fehler und Abstürze zu beheben.

Betroffene Systeme

• Das Backdoor-Skript wird erstmals nach configure aufgerufen und verändert den Build-Prozess nur unter bestimmten Bedingungen (z. B. x86-64-Linux-Systeme, Verwendung von gcc und GNU-Linker, Build von Debian- oder RPM-Paketen).

Auswirkungen auf den openssh-Server

• Wenn eine mit der Backdoor versehene liblzma verwendet wird, werden Logins über SSH langsamer.
• openssh verwendet liblzma nicht direkt, aber einige Distributionen einschließlich Debian patchen openssh zur Unterstützung von systemd-Benachrichtigungen, und libsystemd hängt von lzma ab.

Analyse des eingeschleusten Codes

• Die Analyse erfolgt aus der Perspektive eines Beobachters, der weder Sicherheitsforscher noch Reverse-Engineering-Experte ist.
• Die Backdoor kapert die Ausführung über einen ifunc resolver und löst während der Initialisierung von sshd Symbole auf, um das Symbol RSA_public_decrypt auf ihren eigenen Code umzubiegen.

Auswirkungen auf sshd

• RSA_public_decrypt@....plt wird so verändert, dass es auf den Backdoor-Code zeigt, wodurch der Backdoor-Code bei Public-Key-Logins aufgerufen wird.
• Dadurch wird vermutlich eine Umgehung der Authentifizierung oder Remote Code Execution ermöglicht.

Bug-Report

• Es wurde kein Bug-Report eingereicht, da eine Beteiligung des Upstream-Repositorys vermutet wurde.
• Red Hat hat diesem Problem die Kennung CVE-2024-3094 zugewiesen.

Erkennung verwundbarer Installationen

• Es wird ein Skript bereitgestellt, mit dem erkannt werden kann, ob die ssh-Binärdatei eines Systems verwundbar ist.

[depth221]

Alles, was ich über die xz-Backdoor weiß
Dies ist ein Beitrag von Andres Freund, der diese Backdoor entdeckt hat.

[edunga1]

Es ist erstaunlich, wie planvoll dabei vorgegangen wurde;; der Ablauf wirkt wie ein Drama.

[carnoxen]

Selbst eine grausame Hinrichtung wäre noch zu milde.

[roxie]

Warum?

[keepworking]

Weil hier absichtlich eine Backdoor in Open Source eingebaut wurde ... und in diesem Prozess wurden auch noch heimlich Versuche unternommen, die öffentliche Meinung zu beeinflussen.
Früher gab es auch schon Fälle, in denen böswillig Schwachstellen in den Linux-Kernel eingebracht wurden, das ist wirklich bitter.

[roxie]

Ah, ich glaube, ich verstehe jetzt die Nuance. Danke.

[GN⁺]

Hacker-News-Kommentare

• Verwandte Links:

  • Xz: Disable ifunc to fix Issue 60259
  • FAQ zum xz-utils-Backdoor
  • Everything I Know About the XZ Backdoor

• Zusammenfassung:

  • Der Autor des Backdoors kommunizierte über mehrere Wochen hinweg, um xz 5.6.x in Fedora 40 und 41 aufzunehmen. Er arbeitete auch an der Behebung der durch dieses Backdoor verursachten valgrind-Probleme mit, doch am Ende stellte sich heraus, dass das Backdoor selbst die Ursache war. Nachdem die Sperrfrist versehentlich gebrochen wurde, musste das Problem dringend behoben werden.
  • Einer der Backdoor-Autoren deaktivierte in oss-fuzz eigenhändig Funktionen, die vom Backdoor abhingen, um eine zufällige Entdeckung zu verhindern.
  • Der Backdoor-Autor fügte dem Projekt xz-java eine Datei SECURITY.md hinzu. Darin steht die Anweisung, Sicherheitslücken nicht öffentlich zu machen, sondern vertraulich zu melden. Aus einer anderen Perspektive lässt sich das so deuten, dass der Autor Zeit gewinnen wollte, um seinen Exploit anzupassen und Ziele auszunutzen.
  • OpenSSH verwendet liblzma nicht direkt, aber Debian und mehrere Distributionen patchen OpenSSH für die Unterstützung von systemd-Benachrichtigungen. Dadurch hängt libsystemd von liblzma ab, was zusätzlichen Abhängigkeiten für sicherheitskritische Daemons wie OpenSSH schafft und das Risiko von Supply-Chain-Angriffen erhöht.
  • Wichtige Prüfpunkte für Menschen im Panikmodus:
    • Ob eine aktuelle Version von liblzma5 (5.6.0 oder 5.6.1) verwendet wird. Diese wurde erst im letzten Monat oder so hinzugefügt.
    • Ob eine Debian- oder RPM-basierte Linux-Distribution verwendet wird. Das wirkt wie ein Versuch, Reverse Engineering zu erschweren.
    • Ob OpenSSH sshd unter systemd läuft. Das in manchen Distributionen gepatchte OpenSSH verwendet für Logging libsystemd, wodurch das verwundbare liblzma5 hineingezogen wird.
    • Debian testing hat bereits eine Version mit der Bezeichnung 5.6.1+really5.4.5-1, die in Wirklichkeit die ältere Version 5.4 ist, nur neu verpackt und als neuere Version ausgegeben.
  • Wenn man in GNU autoconf etwas Verdächtiges verstecken wollte, würde man es dort verstecken und nicht in einem "curl | sh"-Skript. Der Verteiler in diesem Vorfall war auch früher schon für Releases zuständig und begann 2022 mit Commits. Es gibt Commits mit vielen echten Änderungen, und auch Commits in verwandten Projekten wie libarchive. Das Einschleusen des Backdoors erforderte viel Aufwand.
  • Vor einigen Jahren schrieb ich eine Go-Bibliothek, die den xz-C-Code kapselt, damit man xz-Kompression aus Go heraus nutzen kann. Vor etwa einer Woche bekam ich den ersten PR für ein Upgrade dieses Repositories auf 5.6.1. Dieser kam von einem anderen GitHub-Konto als dem des Upstreams.
  • Ich schätze es, wenn Mitwirkende, die keine Sicherheitsforscher oder Reverse Engineers sind, technische Texte schreiben. Sein Bericht, der seine Entdeckung zusammenfasst, gilt als hervorragende Vorlage für Mitwirkende außerhalb der etablierten Debugging-Welt, die ihr Wissen nur ungern teilen.
  • Wenn man sich einen geschickteren Backdoor-Versuch für xz(1) vorstellt, wäre er wohl nicht so schnell entdeckt worden. xz wird fast überall verwendet. Man könnte ein xz bauen, das selektiv nur kleine Teile von Dateien verändert, etwa bei .tar.xz-Software-Tarballs, die als Grundlage bestimmter Build-Prozesse dienen. Ziel wären dabei keine Source-Code-Tarballs, sondern Tarballs, die vorkompilierte Binärdateien verteilen.