Was wir über die xz-Utils-Backdoor wissen, die beinahe die ganze Welt infiziert hätte

Der xz-Utils-Backdoor-Vorfall: Was wir über den Fall wissen, der beinahe die ganze Welt infiziert hätte

• xz Utils ist ein Datenkomprimierungsprogramm, das auf Linux sowie auf fast allen Unix-ähnlichen Betriebssystemen installiert ist.
• In diese Software wäre beinahe durch ein bösartiges Update eine Backdoor eingeschleust worden.
• Ein Microsoft-Entwickler entdeckte diese Backdoor und machte sie öffentlich, wodurch eine Krise kurz vor der Aufnahme in wichtige Linux-Distributionen wie Debian und Red Hat verhindert wurde.

Wie funktioniert die Backdoor?

• Der bösartige Code, der in den Versionen 5.6.0 und 5.6.1 hinzugefügt wurde, manipuliert sshd, also die ausführbare Datei für SSH-Verbindungen.
• Eine Person mit einem bestimmten kryptografischen Schlüssel kann Code in einem SSH-Login-Zertifikat verstecken, hochladen und auf einem Gerät mit installierter Backdoor ausführen.
• Welche Art von Code tatsächlich hochgeladen wurde, ist nicht bekannt, theoretisch wären jedoch verschiedene Aktionen wie das Stehlen von Schlüsseln oder die Installation von Malware möglich.

Wie die Backdoor eingeschleust wurde

• Die Backdoor scheint über mehrere Jahre hinweg vorbereitet worden zu sein.
• 2021 trug ein Nutzer namens JiaT75 erstmals zu einem Open-Source-Projekt bei.
• Im Januar 2023 leistete JiaT75 den ersten Beitrag zu xz Utils und übernahm später unter dem Namen Jia Tan schrittweise immer mehr Aufgaben.
• Tan ersetzte im oss-fuzz-Projekt die Kontaktinformationen von Collins durch die eigenen und bat darum, die ifunc-Funktion bei Tests zu deaktivieren.
• Diese Änderungen erschwerten die Erkennung bösartiger Änderungen, die Tan an xz Utils vornahm.

Betroffene Distributionen

• Fedora Rawhide, Fedora 41, Debian Testing/Unstable/Experimental, openSUSE Tumbleweed und MicroOS sowie Kali Linux enthielten xz-Versionen mit der Backdoor.

Meinung von GN⁺

• Dieser Vorfall legt Sicherheitslücken im Open-Source-Ökosystem offen und dient als Weckruf für die Entwickler-Community.
• Da die kompromittierte Software weit verbreitet ist, erinnert der Vorfall Linux-Nutzer und -Administratoren an die Bedeutung schneller Updates und von Sicherheitsprüfungen.
• Ein ähnlicher Fall war der SolarWinds-Hack, der ebenfalls die Risiken von Supply-Chain-Angriffen zeigte.
• Es ist notwendig, die Identität von Entwicklern, die zu Open-Source-Projekten beitragen, zu verifizieren und die Code-Review-Prozesse zu stärken.
• Es ist zu erwarten, dass dieser Vorfall die Bedeutung von Sicherheitsaudits und Tools zur Erkennung von Schwachstellen noch stärker hervorheben wird.

[GN⁺]

Hacker-News-Kommentare

• OpenSSH ist die populärste sshd-Implementierung und ist nicht mit der Bibliothek liblzma verknüpft, aber Debian und viele andere Linux-Distributionen fügen Patches hinzu, die sshd an systemd anbinden. systemd ist mit liblzma verknüpft, wodurch xz Utils sshd beeinflussen konnte.

• XZ ist ein Open-Source-Komprimierungsprogramm und eine Bibliothek, die dabei hilft, eigene Programme zum Umgang mit komprimierten Daten zu schreiben. Es wird von vielen anderen Programmen verwendet, darunter OpenSSH.

• Auch GNU binutils ist mit liblzma verknüpft und wird noch breiter eingesetzt als OpenSSH. In den meisten Fällen wird binutils zum Kompilieren von OpenSSH, des Betriebssystems, auf dem sshd läuft, und Ähnlichem verwendet. Das deutet darauf hin, dass sich böswillige Akteure ein gutes Projekt ausgesucht haben, um tief in Open-Source-Software einzudringen.

• Das Ziel ist, ein standardisiertes Test-Framework zu verwenden, das dabei hilft, mehr Tests zu schreiben, um die Stabilität des XZ-Projekts langfristig zu unterstützen. Viele Funktionen sind noch nicht getestet, daher wären solche Tests nützlich.

• Es gab nicht viele Diskussionen über den Linking-Mechanismus, der sich an die Funktion RSA_public_decrypt hängen konnte. Es gab viele Diskussionen darüber, was sich durch Prozessisolation und Ähnliches erreichen ließe, aber wenig über diese Umleitung des Funktionsaufrufs. Es wird die Frage aufgeworfen, ob sich eine Möglichkeit schaffen lässt, wichtige Komponenten in einer Trust-Tier-Struktur zu verknüpfen.

• Es heißt, die Welt sei "fast" infiziert worden, aber tatsächlich haben populäre Linux-Distributionen wie Arch, Gentoo und openSUSE Tumbleweed die Backdoor wochenlang ausgeliefert, und auf Tumbleweed funktionierte sie definitiv. Die Formulierung "fast" ist unpassend.

• Die Prognose lautet, dass innerhalb der nächsten 12 Monate ein ähnlicher Fall entdeckt wird. Es werde damit beginnen, dass Maintainer anfangen, die früheren Commits der jeweils anderen zu misstrauen.

• Persönliche Lehren aus diesem Vorfall:

  • Source-Repositorys und Source-Distributions-Tarballs, die unterschiedlichen Code enthalten, sind schlecht. Von dieser Praxis sollte man wegkommen.
  • Automatisch erzeugte Artefakte sollten immer committet werden.
  • Automatisch erzeugte Artefakte, die bei Code-Reviews von allen überflogen werden, können problematisch sein. Wenn Dateien dieser Art im Repository liegen, sollte es automatische Tests geben, die prüfen, ob sie manipuliert wurden.
  • autotools und die autotools-Kultur sind schlecht.
  • libsystemd verursacht Probleme im Ökosystem. Menschen, die systemd kritisieren, werden oft abgetan, aber systemd ist groß, komplex und hat viele Abhängigkeiten, und die meisten Programme verwenden nur einen kleinen Teil davon.
  • Die Kultur, dass Code-Reuse immer gut sei und dass es gut sei, für kleine Funktionen von großen Bibliotheken abzuhängen, ist falsch. Abhängigkeiten bringen Wartungsaufwand und Sicherheitsrisiken mit sich, daher muss das gegen Funktionalität abgewogen werden.
  • Es kann problematisch sein, wenn Distributions-Maintainer umfangreiche Patches auf Pakete anwenden. Dadurch entstehen de facto weit verbreitete Forks, die in Wirklichkeit niemand betreut.
  • Entwickler müssen finanziell in die Lage versetzt werden, an OSS zu arbeiten. liblzma und xz-utils laufen auf zig Millionen Installationen, werden aber von einem einzelnen Maintainer mit psychischen Problemen betreut.
  • Code-Reviews und der Austausch von Maintainern müssen heute geopolitische Überlegungen berücksichtigen.

• Es wird Dank dafür ausgedrückt, dass die Person, die das Problem entdeckt hat, ein Microsoft-Ingenieur war, der an Azure Postgres arbeitet. Dadurch gefällt einem Azure jetzt.

• Der ursprüngliche xz-Maintainer hat die Verantwortung an Jia Tan übergeben, ihn aber möglicherweise nie persönlich getroffen oder mit ihm telefoniert. Es wird infrage gestellt, ob es üblich ist, ausschließlich über E-Mail/GitHub zu kommunizieren. Nach dieser Geschichte wird erwartet, dass Maintainer von Open-Source-Projekten vorsichtiger werden.

• Während manche denken, diese Backdoor sei früh entdeckt worden, könnte sie ihr Ziel bereits erreicht haben. Das gilt umso mehr, wenn Entwickler, die Rolling-Release-Distributionen wie Kali und Debian verwenden, das Ziel waren.

• Es wird angedeutet, dass die Behauptung, der langjährige xz-Utils-Maintainer Lasse Collin habe die Software nicht häufig genug oder nicht schnell genug aktualisiert, ein Irrtum war.