Die xz-Backdoor, entdeckt durch NixOS und reproduzierbare Builds

• Im März 2024 wurde eine Backdoor in der Software xz entdeckt, die in Linux-Distributionen zum Entpacken von Source-Tarballs verwendet wird.
• Diese Backdoor wurde über drei Jahre hinweg heimlich von dem böswilligen Maintainer Jia Tan eingeschleust.
• Der Vorfall hatte große Auswirkungen, da er Remote Code Execution ermöglichte und äußerst schwer zu entdecken war.
• Zufällig wurde sie von Andres Freund, einem Postgres-Entwickler bei Microsoft, entdeckt, als er Performance-Einbußen untersuchte, wodurch eine große Katastrophe verhindert werden konnte.

Wie der Angriff funktioniert

• Die Backdoor kapert das ssh-Programm und ermöglicht dadurch Remote Code Execution.
• Durch die Modifikation der Funktion RSA_public_decrypt kann der Angreifer beim Login mit einem bestimmten RSA-Schlüssel beliebige Befehle ausführen.
• Sie besteht aus zwei Hauptkomponenten:
  1. Ein Skript, das im Rahmen des xz-Build-Prozesses eine bösartige Objektdatei installiert.
  2. Ein Verfahren zum Hooking der Funktion RSA_public_decrypt.

1. Skript zur Installation der bösartigen Objektdatei

• Die bösartige Objektdatei ist in Testdateien des xz-Git-Repositorys versteckt.
• Die Backdoor wird nur in den vom Maintainer bereitgestellten Release-Tarballs aktiviert.

2. Verfahren zum Hooking der Funktion RSA_public_decrypt

• Es nutzt die ifunc-Funktion von glibc, um die Ausführung von Code zu erzwingen, der zur dynamischen Ladezeit läuft.
• Wenn ssh ausgeführt wird, werden libsystemd und liblzma geladen, und dabei führt die Backdoor beliebigen Code aus.

Wie sich die xz-Katastrophe hätte vermeiden lassen

• Um die Vertrauenswürdigkeit von Open-Source-Software zu erhöhen, müssen sowohl soziale als auch technische Probleme angegangen werden.
• Die Sicherheitsprozesse der Software-Lieferkette müssen verbessert werden.

Software aus vertrauenswürdigen Quellen bauen

• Der Angriff war wirksam, weil viele Distributionen xz anhand der vom Maintainer bereitgestellten Tarballs gebaut haben.
• Wenn möglich, sollte Software aus der vertrauenswürdigsten verfügbaren Quelle gebaut werden.

Wenn es die Umstände erlauben...

• NixOS ist eine Distribution auf Basis eines funktionalen Paketverwaltungsmodells, bei dem jedes Paket in der funktionalen Programmiersprache Nix beschrieben wird.
• In NixOS gibt es die Praxis, automatisch auf GitHub erzeugte Source-Archive zu verwenden.

Vertrauen in nicht vertrauenswürdige Release-Tarballs aufbauen

• NixOS musste in der Bootstrap-Phase die vom Maintainer bereitgestellten Tarballs verwenden.
• Um die Sicherheit der Software-Lieferkette zu stärken, müssen bestimmte Schutzmaßnahmen eingeführt werden.

1. Quellen vergleichen

• Es ist wichtig zu prüfen, ob der in der Distribution verwendete Source-Tarball mit dem von GitHub identisch ist.
• Allerdings unterscheiden sich Release-Tarballs oft vom Quellcode, und das ist nicht unbedingt ein Problem.

2. Bitgenaue Reproduzierbarkeit nutzen

• Reproduzierbare Builds sind eine Eigenschaft von Softwareprojekten, bei der unter denselben Bedingungen bei zwei Builds identische Artefakte erzeugt werden.
• Mit bitgenauer Reproduzierbarkeit lässt sich Vertrauen in nicht vertrauenswürdige, vom Maintainer bereitgestellte Tarballs aufbauen.

Fazit

• Der Vorfall mit der xz-Backdoor macht deutlich, wie wichtig Sicherheit in der Open-Source-Software-Lieferkette ist.
• Systeme wie NixOS können ihre Sicherheit durch reproduzierbare Builds verbessern.

[GN⁺]

Hacker-News-Kommentare

• NixOS und reproduzierbare Builds haben die xz-Backdoor nicht erkannt. NixOS hat den bösartigen xz-Build ausgeliefert, aber da er nicht auf NixOS abzielte, gab es kein Problem

  • Ein NixOS-Entwickler war überrascht, als die Backdoor bekannt wurde und er sah, dass die bösartige xz-Version an Nutzer ausgeliefert worden war
  • Theorie und Realität unterscheiden sich, und der Grund, warum xz möglich war, lag nicht in einer technischen Schwachstelle, sondern in einem Problem der "realen Welt". Es fällt schwer anzuerkennen, dass man die reale Welt nicht mit Software patchen kann

• Der Autor scheint sich nur auf diesen Vorfall zu konzentrieren. Der Fall Jiatan ist ein Einzelfall, und auch in anderen Szenarien können Abwehrmechanismen versagen

  • Als NixOS-Nutzer denke ich, dass NixOS das sehr wahrscheinlich nicht hätte erkennen können. Ohne Belege NixOS zu vertrauen, wäre töricht

• NixOS ist hier nicht relevant, weil die xz-Backdoor auf RedHat und Debian abzielte. Ironischerweise wurde die Backdoor von einem Microsoft-Mitarbeiter entdeckt

• Im Artikel wird erwähnt, dass Distributionen den Source Code direkt aus einem VCS (z. B. Github) beziehen sollten statt aus traditionellen Installations-Tarballs

  • Ein bösartiger Maintainer könnte jedoch Binär-Blobs direkt in das Source-Code-Repository einfügen
  • Der Autor legt nahe, dass Github vertrauenswürdig sei, als würde es den Code verifizieren, aber tatsächlich verifiziert Github keinen Code

• Wenn man sich auf Vorfälle konzentrieren will, die NixOS hätte verhindern können, sollte man sich auf den CrowdStrike-Vorfall konzentrieren. Wenn man mit der Konfiguration von gestern hätte booten können, hätte man die meisten Probleme abmildern können

• NixOS kompiliert alles aus den Quellen, prüft kryptografisch, dass die verwendeten Quellen nicht manipuliert wurden, und hat Versionsabhängigkeiten zwischen Paketen. Debian hat ebenfalls reproduzierbare Builds

  • Das Problem war, dass das Build-System vorkompilierte Objektdateien nicht entfernt hat, bevor es aus den Quellen gebaut hat. Wenn niemand den Source Code überprüft, kann eine Backdoor eingefügt werden, und weder NixOS noch andere Distributionen können das verhindern

• "Hätte können" bedeutet, dass nichts bewiesen wurde, und tatsächlich haben sie es ausgeliefert

• Ausgezeichnete erläuternde Analyse. Falscher, irreführender Titel, vielleicht "technisch korrekt", aber höchstens im Sinn von "mit Backdoor versehen"

  • Das unterstreicht die Notwendigkeit und den Nutzen von Build-Manager-Tools; man sollte explizit einen kausalen Trace-Graphen erstellen, wie Dateien im Build-Prozess andere Dateien beeinflussen, und Wege schaffen, diesen Graphen durchzusetzen oder Abweichungen vom vorherigen Trace-Graphen zu melden

• Wenn Jia Tans PR genehmigt worden wäre, hätten bösartige Artefakte genauso leicht über Github-Releases verbreitet werden können wie über Tarballs. Es ist schwer nachzuvollziehen, inwiefern Github-Releases eine Sicherheitsmaßnahme sein sollen

• Dass Release-Tarballs sich von den Quellen unterscheiden

  • Wenn ein vom Maintainer bereitgestellter Tarball ehrlich aus dem ursprünglichen Source Code erzeugt wurde, ist schwer nachzuvollziehen, warum unterschiedliche Versionen usw. ein Problem sein sollten
  • Der erzeugte Tarball sollte aus dem Source Code selbst erzeugbar sein, ohne irgendetwas auszuschließen, und dann per git add & commit festgehalten werden. Selbst dann müsste man die Commit-Historie prüfen, und da es visuell harmlos aussah, ist fraglich, wie man das verifizieren soll
  • Problematisch wird es, wenn ein gepflegter Tarball aus dem Source Code des Eigentümers erzeugt wird und nicht auf Github vorhanden ist

• Es gab mehr Probleme als nur das Pushen vergifteter Testdateien, aber es ist schwer zu verstehen, wie Nix das hätte verhindern können

  • Wenn ein bekanntes Projekt seine Führung wechselt, sollte man die Commits genau ansehen und prüfen, wer die Leitung übernommen hat

• Ich frage mich, ob ich den Artikel falsch verstanden habe oder etwas übersehen habe