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

 (arstechnica.com)
3 Punkte von GN⁺ 2024-04-02 | 1 Kommentare | Auf WhatsApp teilen
  • Microsofts Andres Freund entdeckte eine in xz Utils eingebaute Backdoor, als er einer ungewöhnlichen SSH-Performance auf Debian-Systemen nachging. xz Utils wird in fast allen Linux-/Unix-Umgebungen verwendet.
  • Der Schadcode steckte in xz Utils 5.6.0 und 5.6.1 und war so entworfen, dass ein Angreifer mit einem bestimmten privaten Schlüssel Code in einem SSH-Login-Zertifikat verstecken und auf einem betroffenen Gerät ausführen konnte.
  • Die Angreifer nutzten statt des GitHub-Quellcodes das Release-Tarball, Testdateien, Build-Skripte und glibc-IFUNC, um über liblzma die Authentifizierungsroutine von sshd zu hooken.
  • Die Backdoor prüfte Bedingungen wie amd64/x86_64, glibc sowie Paket-Builds für Debian- oder Red-Hat-basierte Systeme und war in Fedora Rawhide, Fedora 41, Debian testing/unstable/experimental, openSUSE Tumbleweed/MicroOS und zeitweise in Releases von Kali Linux enthalten.
  • Eine Entwicklerpersona namens Jia Tan war über Jahre an der Pflege von xz Utils beteiligt. Der Vorfall wird unter CVE-2024-3094 geführt, und es erschienen Erkennungs- und Analysewerkzeuge wie die Prüfseite von Binarly und xzbot.

Entdeckung und Ausmaß

  • Andres Freund ist Entwickler und Ingenieur bei Microsoft mit PostgreSQL-Bezug. Er untersuchte auf Debian-Systemen ein Phänomen, bei dem SSH-Logins übermäßig viel CPU verbrauchten und valgrind-Fehler auslösten, und stieß dabei auf Auffälligkeiten.
  • Die Ursache war ein Update von xz Utils. Freund veröffentlichte auf der Open Source Security List, dass dieses Update eine absichtlich in die Komprimierungssoftware eingebaute Backdoor sei.
  • xz Utils bietet auf nahezu allen Unix-artigen Betriebssystemen einschließlich Linux verlustfreie Datenkomprimierung und -dekomprimierung und unterstützt auch das ältere .lzma-Format.
  • Filippo Valsorda bewertete dies als „möglicherweise den am besten ausgeführten öffentlich beschriebenen Supply-Chain-Angriff überhaupt und als Alptraumszenario eines bösartigen, kompetenten und privilegierten Upstreams in einer weit verbreiteten Bibliothek“.

Zielverhalten der Backdoor

  • Der Schadcode wurde xz Utils 5.6.0 und 5.6.1 hinzugefügt und veränderte das Verhalten der Software.
  • Die Backdoor manipulierte sshd, die ausführbare Datei für entfernte SSH-Verbindungen.
  • Wer über einen vorab festgelegten kryptografischen Schlüssel verfügte, konnte gewünschten Code in einem SSH-Login-Zertifikat verstecken, hochladen und auf einem Gerät mit der Backdoor ausführen.
  • Der tatsächlich hochgeladene Code wurde nicht bestätigt, daher ist unbekannt, welchen Code die Angreifer ausführen wollten.
  • Theoretisch wäre nahezu jede Aktion möglich gewesen, darunter das Stehlen kryptografischer Schlüssel oder das Installieren von Malware.

Wie die Komprimierungsbibliothek SSH erreichte

  • Eine Bibliothek kann das interne Verhalten von ausführbaren Dateien beeinflussen, mit denen sie verlinkt ist.
  • Die gängige sshd-Implementierung von OpenSSH ist standardmäßig nicht mit liblzma verlinkt.
  • Debian und mehrere Linux-Distributionen ergänzten jedoch Patches, die sshd mit systemd verbinden.
    • systemd ist das Programm, das beim Booten verschiedene Dienste lädt.
    • systemd ist mit liblzma verlinkt.
    • Über diesen Verbindungspfad konnte xz Utils Einfluss auf sshd nehmen.

Hinweise auf jahrelange Vorbereitung

  • 2021 hinterließ ein Nutzer namens JiaT75 den ersten bekannten Commit in einem Open-Source-Projekt.
    • Im Projekt libarchive wurde dabei die Funktion safe_fprint durch eine seit Langem als weniger sicher bekannte Variante ersetzt, ohne dass es damals jemand bemerkte.
  • 2022 reichte JiaT75 einen Patch auf der Mailingliste von xz Utils ein.
    • Kurz darauf drängte ein neuer Teilnehmer namens Jigar Kumar darauf, dass Lasse Collin xz Utils nicht häufig oder schnell genug aktualisiere.
    • Dennis Ens und andere neue Beteiligte drängten Collin ebenfalls, zusätzliche Maintainer aufzunehmen.
  • Im Januar 2023 hinterließ JiaT75 den ersten Commit in xz Utils und brachte sich unter dem Namen Jia Tan tiefer in die Arbeit an xz Utils ein.
    • Er änderte den oss-fuzz-Kontakt für Collin auf seine eigenen Kontaktdaten.
    • Er forderte eine Änderung an, die während oss-fuzz-Tests die IFUNC-Funktion deaktivierte, sodass spätere bösartige Änderungen in xz Utils nicht erkannt würden.
  • Im Februar 2024 veröffentlichte Tan die Commits für xz Utils 5.6.0 und 5.6.1, mit denen die Backdoor umgesetzt wurde.
  • Danach forderten Tan oder andere Personen Entwickler bei Ubuntu, Red Hat und Debian auf, das Update in ihre Betriebssysteme zu übernehmen.

Betroffene Distributionen und Ausführungsbedingungen

  • Laut Tenable waren die Backdoor-Versionen oder entsprechende Updates in folgenden Releases enthalten:
    • Fedora Rawhide: die Entwicklungsdistribution von Fedora Linux
    • Fedora 41
    • Debian testing, unstable, experimental: 5.5.1alpha-0.1 bis 5.6.1-1
    • openSUSE Tumbleweed und openSUSE MicroOS: enthielten zwischen dem 7. und 28. März die Backdoor-Versionen von xz
    • Kali Linux: enthielt zwischen dem 26. und 28. März xz-utils 5.6.0-0.2
  • Laut der Analyse von Sam James prüfte das bösartige Skript, ob das Build-Ziel amd64/x86_64 ist, ob der Name linux-gnu verwendet wird und ob GCC sowie GNU ld im Einsatz sind.
  • Es prüfte außerdem, ob es sich um einen Debian-Paket-Build handelt oder ob RPM_ARCH auf x86_64 gesetzt ist.
  • Der Angriff scheint auf Build-Umgebungen für amd64-Systeme mit glibc abzuzielen, die Debian- oder Red-Hat-abgeleitete Distributionen erzeugen.
  • Ob andere Systeme verwundbar waren, war zu diesem Zeitpunkt nicht bekannt.

Implementierung und Verschleierungstechniken

  • Sam James fasste zusammen, dass die Backdoor aus mehreren Komponenten bestand.
    • Das vom Upstream verteilte Release-Tarball entsprach nicht dem Code auf GitHub.
    • build-to-host.m4 im Release-Tarball unterschied sich stark von der GitHub-Upstream-Version.
    • Im Ordner tests/ des Git-Repositories befanden sich manipulierte Testdateien.
      • tests/files/bad-3-corrupt_lzma2.xz
      • tests/files/good-large_compressed.lzma
    • Ein von build-to-host.m4 aufgerufenes Skript entpackte die bösartigen Testdaten und veränderte den Build-Prozess.
    • glibcs IFUNC wurde verwendet, um die OpenSSH-Authentifizierungsroutine zur Laufzeit zu hooken oder umzuleiten.
  • HD Moore bestätigte, dass die letzte Backdoor-Stufe nur ausgeführt wird, wenn die Bibliothek auf amd64 gebaut und ein Debian- oder RPM-Paket erzeugt wird.
  • Laut Analysen von Forschern wurde während der Prüfung eines öffentlichen SSH-Schlüssels bei passender bestimmter Fingerprint-Funktion und passendem öffentlichem Schlüssel der Schlüsselinhalt zunächst mit einem vorab geteilten Schlüssel entschlüsselt, noch bevor die eigentliche Validierung stattfand.
  • Wenn der entschlüsselte Inhalt einem bestimmten Format entsprach, wurde er direkt an system übergeben.
  • Falls der Fingerprint nicht passte oder der entschlüsselte Inhalt nicht dem Format entsprach, fiel der Ablauf auf die normale Schlüsselvalidierung zurück, sodass Benutzer den Unterschied kaum bemerken konnten.

Die von Akamai zusammengefasste Ausführungskette

  • Forscher von Akamai gehen davon aus, dass die Backdoor nur in den Source-Code-Tarball-Releases und nicht im xz-GitHub-Repository enthalten war, um der Erkennung zu entgehen.
  • Die Backdoor wurde über mehrere Commits hinweg aufgebaut.
    • Im Build-Prozess wurde IFUNC genutzt, damit die Malware die Funktion zur Symbolauflösung abfangen konnte.
    • In Testdateien wurde ein verschleiertes Shared Object versteckt.
    • Während des Bibliotheks-Builds wurde ein Skript ausgeführt, das das Shared Object extrahierte.
    • Landlocking, eine Sicherheitsfunktion zur Einschränkung von Prozessrechten, wurde deaktiviert.
  • Die Ausführungskette bestand aus mehreren Stufen.
    • build-to-host.m4 wurde während des Bibliotheks-Builds ausgeführt und dekodierte bad-3-corrupt_lzma2.xz zu einem Bash-Skript.
    • Dieses Bash-Skript dekodierte good-large_compressed.lzma auf komplexere Weise zu einem weiteren Skript.
    • Dieses Skript extrahierte das Shared Object liblzma_la-crc64-fast.o und fügte es dem Kompilierungsprozess von liblzma hinzu.
  • Dieses Shared Object wurde in liblzma einkompiliert und ersetzte den normalen Prozess der Funktionsnamensauflösung.
  • Die bösartige Bibliothek konnte den Funktionszeiger von OpenSSHs RSA_public_decrypt auf eine eigene schädliche Funktion umbiegen.
  • Laut der Analyse von Filippo Valsorda extrahierte diese bösartige Funktion Befehle aus dem Zertifikat des authentifizierenden Clients, prüfte, ob es sich um den Bedrohungsakteur handelte, und übergab sie dann an system(), wodurch Remote Code Execution vor der Authentifizierung möglich wurde.

Jia Tan und offene Fragen

  • Über Jia Tan ist nur sehr wenig bekannt.
  • Diese Entwicklerpersona war in den vergangenen Jahren auch an Dutzenden anderen Open-Source-Projekten beteiligt.
  • Ob sich hinter dem Benutzernamen Jia Tan eine reale Person verbarg oder ob es sich um eine vollständig erfundene Figur handelte, ist unbekannt.
  • Weitere technische Analysen finden sich im Bluesky-Thread von Filippo Valsorda, in Kevin Beaumonts Analyse und in Freunds Veröffentlichung vom Freitag.

CVE und Prüfwerkzeuge

  • Die Tracking-ID dieser Schwachstelle lautet CVE-2024-3094.
  • Die Seite xz.fail von Binarly erkennt die IFUNC-Implementierung und basiert auf Verhaltensanalyse.
    • Dadurch lassen sich auch unveränderliche Bedingungen automatisch erkennen, wenn ähnliche Backdoors an anderer Stelle eingebaut werden.
  • xzbot bietet Funktionen für Analyse und Experimente.
    • honeypot: ein gefälschter verwundbarer Server zur Erkennung von Exploit-Versuchen
    • ed448 patch: patcht liblzma.so, damit ein eigener ED448-Schlüssel verwendet wird
    • backdoor format: Format der Backdoor-Payload
    • backdoor demo: CLI zum Auslösen von RCE unter der Annahme, dass der private ED448-Schlüssel bekannt ist

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-02
Meinungen auf Hacker News

  • Ziel war es, das Schreiben von Tests für XZ durch ein standardisiertes Test-Framework zu erleichtern.
    Jia schrieb am 17.06.2022, dass es noch viele ungetestete Funktionen gebe und dass dies helfen werde, die Tests für die langfristige Stabilität des Projekts auszubauen.
    Es war also eine Veränderung, die schon lange vorbereitet worden war.

  • Der Linking-Mechanismus, der es der Bibliothek ermöglichte, sich in RSA_public_decrypt einzuklinken, scheint nicht viel diskutiert worden zu sein.
    Es gibt viele Diskussionen über Dinge wie Prozessisolierung, aber wenig über die Umleitung dieses Funktionsaufrufs.
    Vielleicht ließe sich ein Modell schaffen, bei dem zentrale Komponenten wie Code, der über SSH hereinkommt, mit Bibliotheken über eine hierarchische Vertrauensstruktur verlinkt werden: „An der Stelle, an der ich dich aufrufe, vertraue ich dir, aber ich erlaube dir nicht, dich selbst an anderen Aufrufpunkten einzuhängen.“
    Das könnte zwar den reflexhaften Einwand „Security by Obscurity“ auslösen, weil es Umgehungsmöglichkeiten gibt, aber dennoch kann man es als Reduzierung der Angriffsfläche sehen.

    • Ein Modell ähnlich Erlang-Aktoren, bei dem Unterkomponenten eines Programms jeweils ihren eigenen Security Context haben und einander per Message Passing aufrufen, könnte funktionieren.
      Allerdings überlagern sich im Betriebssystem mehrere Security Contexts. Im Zusammenhang mit der XZ-Backdoor geht es vor allem um capability-basierte Sicherheit auf Modulebene, aber es gibt auch Capabilities auf Programmebene, Speicherisolation auf Speicherebene (Paging), Isolation auf mikroarchitektonischer Ebene usw.
      Diese Elemente so zusammenwirken zu lassen, dass dabei auch noch gute Performance herauskommt, ist ziemlich schwierig; und dass Unix-artige Systeme auf ein solches Modell wechseln, erscheint praktisch unmöglich, weil dafür das Konzept des Prozesses selbst ersetzt werden müsste.
    • Meiner Ansicht nach liegt das Problem in der Verwendung von IFUNC in glibc.
      Das hat die XZ-Tests kaputtgemacht, woraufhin plötzlich Accounts auftauchten, die dafür lobbyierten, diese Tests zu deaktivieren, und dadurch wurde der Exploit möglich.
    • Im Kern ändert dieser Code zur Build-Zeit, also beim Ausführen von ./configure && make, heimlich eine C-Datei, patcht den ifunc resolver und lässt ihn ein mitgeliefertes bösartiges Objekt aufrufen.
      Die kompromittierte Objektdatei wird zusammen mit dem Linker-Flag now gelinkt, sodass ifunc beim Laden der Bibliothek sofort aufgelöst wird; zu diesem Zeitpunkt ist die Link-Tabelle des Prozesses noch beschreibbar, und der gepatchte Resolver wird aufgerufen.
      Genau dieser Teil ist entscheidend: Beim Laden der Bibliothek konnte so die Funktion RSA_public_decrypt im Speicher einfach abgefangen werden.
      Ein Artikel mit einer sehr guten Analyse des Backdoor-Injektionsprozesses: https://research.swtch.com/xz-script
    • systemd hat kürzlich eine Änderung gemergt, die für Kompressionsbibliotheken dlopen verwendet: https://github.com/systemd/systemd/pull/31550
      In diesem Sinne ist es eine sicherere Linking-Methode.
    • Ich frage mich, ob es ausreichen würde, wenn ltrace die aufgerufenen Symbole überwacht.

  • Ich verstehe nicht, warum man sagt, es habe „fast“ die ganze Welt infiziert.
    Mindestens drei ziemlich populäre Linux-Distributionen, Arch, Gentoo und openSUSE Tumbleweed, haben die Backdoor über Wochen verteilt, und auf Tumbleweed funktionierte sie definitiv.
    Wenn SSH mit Backdoor über Wochen ausgeliefert wurde, ist „fast“ eher untertrieben.

    • Auf diesen Distributionen wurde der Exploit tatsächlich nicht ausgeführt.
      Er funktionierte nur auf deb/rpm-Zielen, also wurde er praktisch gestoppt, bevor er die Produktion erreichte.
    • Arch und Gentoo sind als Hobby-Distributionen recht beliebt, in professionellen Betriebsumgebungen wie den SSH-Servern, auf die dieser Angriff abzielte, aber deutlich weniger verbreitet.
      Das heißt nicht, dass es harmlos wäre; wäre das lange genug unentdeckt geblieben, um in RHEL oder Debian/Ubuntu stable zu landen, hätten wir Meldungen aus Banken, Krankenhäusern und ähnlichen Einrichtungen bekommen.
      Bei Remote Code Execution vor der Authentifizierung wäre es schwer gewesen zu sagen, man sei „nicht betroffen“, außer in Umgebungen mit stark eingeschränkten Netzwerken und gutem Flow-Logging.
    • In den Binärpaketen von Arch scheint es tatsächlich nicht enthalten gewesen zu sein, weil das Backdoor-Build-System selbst keine Backdoor für Arch einbaute.
      Vergleicht man liblzma.so.5.6.1 aus xz-5.6.1-1 und xz-5.6.1-2 mit cmp -l, gibt es nur sehr kleine Unterschiede.
      Vor dem Schreiben der Sicherheitsmeldung war das offenbar nicht bekannt.
      https://github.com/QubesOS/qubes-issues/issues/9067#issuecom...
    • Die meisten Linux-Maschinen, auf denen sshd läuft, verwenden wahrscheinlich LTS-Distributionen und keine Rolling Releases.
      Allerdings weiß ich nicht, wie man an Daten kommt, die das belegen.
    • Ich hoffe, Open-Source-Maintainer und große Unternehmen haben die Botschaft verstanden. Die finanziellen Perspektiven der Open-Source-Wartung müssen sich ändern.

  • Ich wette 101 Dollar, dass innerhalb der nächsten 12 Monate etwas Ähnliches in einer realen Umgebung gefunden wird.
    Denn Maintainer werden anfangen, die früheren Commits der jeweils anderen misstrauisch zu durchforsten.

    • Ich denke, solche Angriffe haben in den letzten zehn Jahren zugenommen.
      Man muss sich nur Codebases ansehen, die wichtig, aber wenig bekannt sind und sehr wenige Maintainer haben.
    • Ich frage mich, ob man bereits ausgeführte und genutzte Fälle finden kann.
      Wenn ich so etwas gehabt hätte und es gut funktioniert hätte, hätte ich es später vermutlich mit einem anderen Account „entdeckt“ und beheben lassen.

  • Meine persönlichen Schlüsse aus dieser Sache sind mehrere:
    Erstens sind Source-Distribution-Tarballs, die anderen Code enthalten als das Source-Repository, schlecht, und wir sollten uns davon entfernen. Ein anderer großer Supply-Chain-Angriff, event-stream, nutzte einen ähnlichen Punkt aus.
    Daraus folgt, dass automatisch erzeugte Artefakte immer committet werden sollten.
    Zweitens sind automatisch erzeugte Artefakte ein Problem, die beim Code-Review alle einfach mit Page Down überspringen. Wenn solche Dateien im Repository liegen, sollte es auch automatische Tests geben, die prüfen, ob jemand sie manipuliert hat, und die zugleich verhindern, dass veraltete automatisch erzeugte Dateien liegen bleiben.
    Drittens: Als Konsequenz aus 1 und 2 ist autotools schlecht, und die autotools-Kultur ebenfalls.
    Viertens ist libsystemd ein Problem für das Ökosystem. Wenn man das sagt, wird man als systemd-Hasser abgestempelt, aber es ist groß, komplex, hat viele Abhängigkeiten, und die meisten Programme nutzen nur einen winzigen Teil davon. Alle Dienste dazu zu ermutigen, für Initialisierungsbenachrichtigungen davon abhängig zu sein, ist Wahnsinn.
    Fünftens gibt es eine Kultur, nach der Code-Wiederverwendung immer gut sei und es in Ordnung sei, wegen kleiner Funktionen von großen Bibliotheken abhängig zu werden; das stimmt aber nicht. Abhängigkeiten sind Wartungsaufwand und ein Sicherheitsrisiko und müssen gegen den Nutzen der eingebundenen Funktion abgewogen werden.
    Sechstens ist es ebenfalls ein Problem, wenn Distributions-Maintainer große Patches auf Pakete anwenden. Dadurch entstehen weit verbreitete De-facto-Forks von Bibliotheken und Anwendungen, die die eigentlichen Maintainer nicht prüfen.
    Siebtens muss OSS aus Sicht der Entwickler finanziell nachhaltig werden. Liblzma und xz-utils dürften zig Millionen Installationen haben, stützten sich aber auf einen einzigen Maintainer mit psychischen Problemen.
    Achtens, ich sage es ungern, aber heute muss man bei Code-Reviews und der Übergabe von Maintainer-Rechten auch geopolitische Überlegungen anstellen.

    • Geopolitische Überlegungen helfen nicht.
      Es gibt keinen Beleg dafür, dass Jia Tan ein echter Name ist, ja nicht einmal dafür, dass es sich um eine echte Person handelt.
      Wenn Projekte anfangen, Beiträge von Namen abzulehnen, die asiatisch klingen, nennt sich der nächste Angreifer einfach Richard Jones.
    • Bei libsystemd stimme ich vollständig zu.
      Wenn man aus der BSD-Welt kommt, ist systemd ein Schock: monströs und mit Tentakeln überall.
    • Dazu kommt noch eine persönliche Beobachtung.
      Nicht nur Verbraucher sind naiv, auch die Softwarebranche selbst ist naiv gegenüber Sicherheitsbedrohungen.
      Soziale Exploits sind Teil von Code-Exploits.
      Das FOSS-Prinzip „je mehr Augen auf den Code schauen, desto besser“ stimmt, funktioniert aber nur, wenn diese Augen geschult sind. FOSS braucht materielle Unterstützung aus der Industrie.
      Ein MSFT-Ingenieur hat diesen Exploit entdeckt, aber trotzdem landete er in den allgemein öffentlichen Versionen von Fedora 41, openSUSE und Kali.
      Entwickler-Toolchains und Testprozesse wurden nie dafür entworfen, Sicherheit zu testen. SolarWinds ist ebenfalls ein nützlicher Bezugspunkt: https://www.wired.com/story/the-untold-story-of-solarwinds-t...
    • Die Forderung, Tarball-Distributionen einzustellen, ignoriert völlig, warum es Release-Artefakte gibt.
      Release-Artefakte enthalten nicht nur autoconf-Skripte.
      Es gibt viele Gründe, binäre Blobs in Release-Archive aufzunehmen: Spielressourcen, Firmware-Images, Testfälle usw. Es war auch davon die Rede, dass mpv einige Mediendateien als Testfälle enthält, die mit proprietären Encodern erzeugt wurden; das ist nichts Schlechtes, sondern etwas Gutes.
      Das gut gepflegte sqlite wird überall verwendet und hat eine ausgezeichnete Testsuite. Für jedes Release verteilt es nicht nur einen Tarball, sondern zwei, für unterschiedliche Kompilierungsstufen. Das einzustellen wäre leicht, würde aber nur die Arbeit der Paket-Maintainer erhöhen und der Sicherheit nicht helfen.
      Debian baut aus kuratierten Tarballs, weil sie von Menschen kuratiert und mit bekannten Schlüsseln signiert werden. Natürlich könnte man auch aus git bauen, aber ob das die Lage verbessern würde, ist unklar. Nicht jedes Projekt signiert Release-Tags, und selbst wenn, ist es wahrscheinlicher, dass das automatisiert geschieht.
      Wir wollen, dass Änderungen zuerst von Upstream-Maintainern und danach von Paket-Maintainern geprüft werden, und wir bevorzugen, dass diese beiden Akteure unabhängig voneinander sind.
      Diesmal hat ein korrumpierter Upstream-Maintainer diesen Prozess angegriffen, aber das heißt nicht, dass man Upstream-Maintainer abschaffen sollte. In den letzten Jahren hat diese Struktur mehrere Backdoor-Versuche verhindert, und sie ist kein Prozess, den man ohne sorgfältige Prüfung wegwerfen sollte.
      Die Richtung für Verbesserungen bleibt, was immer gesagt wurde: stärker auf reproduzierbare Builds setzen, wo möglich die Angriffsfläche und Build-Komplexität reduzieren, Maintainer vertrauen, aber ihre Arbeit verifizieren.
    • Die systemd-Maintainer haben nie dazu ermutigt, dass alle Dienste von libsystemd abhängen.
      Im Gegenteil, sie sind an diesem Punkt selbst irritiert und ergänzen Dokumentation dazu, wie man einfache Datagramme ohne libsystemd implementiert.
      Die Installationszahlen von liblzma und xz-utils dürften weit über zig Millionen liegen. Viele Sprachen wie Python, PHP und Ruby hängen von libxml2 ab, und libxml2 verwendet liblzma. Dazu kommen viele andere Abhängigkeiten.
      Geopolitische Überlegungen sind nicht Aufgabe der Maintainer. OSS wird ohne Gewähr bereitgestellt.
      Außerdem könnte „Jia Tan“ komplett erfunden gewesen sein. Wenn man sich die Commit-Zeitstempel ansieht, wechselt die Zeitzone sogar am selben Tag von Osteuropa nach Asien. Zumindest ist klar, dass hier ein Identitätsspiel betrieben wurde.

  • Ich wusste nicht, dass die Person, die dieses Problem entdeckt hat, ein Microsoft-Ingenieur war, der bei Azure Postgres arbeitet.
    Danke, Microsoft, jetzt gefällt mir Azure besser.

    • Ich denke, die Leute müssen sich jetzt alle Valgrind-Anomalien ansehen.
      Denn genau so wurde dieses Problem entdeckt.
      Danach sollte man sich die betroffene Bibliothek ansehen und nach ähnlichen Ausreißern suchen, bei denen eine falsche Persona ein Projekt übernimmt.
      Es scheint gängige Praxis zu sein, solche Fehler zu ignorieren.
    • Das ist ein von Microsoft beschäftigter PostgreSQL-PGDG-Ingenieur.
      Diese Art von Framing ist wirklich unerträglich.

  • Es scheint, als hätte der ursprüngliche Maintainer von xz die Verantwortung an Jia Tan übergeben, ohne ihn persönlich getroffen oder zumindest mit ihm telefoniert zu haben.
    Ich frage mich, ob es üblich ist, nur per E-Mail oder GitHub zu kommunizieren.
    Nach diesem Vorfall dürften einige Maintainer von Open-Source-Projekten vorsichtiger werden.

    • Nur per E-Mail/GitHub zu kommunizieren, ist völlig üblich.
      Ich habe selbst schon Bibliotheken übernommen oder übergeben und dabei ausschließlich textbasiert kommuniziert, ohne überhaupt zu wissen, wer die reale Person ist.
      Aber die Schlussfolgerung, „Maintainer müssen vorsichtiger sein“, halte ich in diesem Fall für völlig falsch.
      Die Verantwortung dafür, was Menschen in ihr Projekt hineinziehen, liegt nicht bei den Maintainern, sondern bei den Leuten, die an diesem Projekt arbeiten.
      Entweder man vertraut dem Maintainer oder man tut es nicht; und sobald man beginnt, von einer Library abhängig zu sein, stimmt man implizit zu, fortlaufend zu aktualisieren, wem man vertraut.
    • Genau so ist die derzeitige Struktur faktisch.
      Millionen Unternehmen reiten kostenlos auf der Arbeit unbezahlter Open-Source-Entwickler mit.
      Daher ist es nicht überraschend, dass diese irgendwann gehen und Probleme entstehen.
    • Ich frage mich, welchen Unterschied ein Telefonat gemacht hätte.
      Welches zusätzliche Vertrauen in die Absichten dieser Person hätte das geschaffen?
    • Ja, Kommunikation nur per E-Mail/GitHub ist normal.
      Ich war an etwa sechs Open-Source-Projekten unterschiedlicher Größe beteiligt, von 100 bis 30.000 GitHub-Stars, und habe mit niemandem telefoniert; textbasierte Kommunikation war der Standard.
    • Wenn mehrere Leute wegen des Arbeitstempos Druck machen, ist es nicht verwunderlich, dass ein Maintainer das Gefühl bekommt, er sei das Problem, und das Projekt an die Person übergibt, die ihm damals als die beste Wahl erscheint.
      Aber jemanden persönlich zu kennen, löst das Problem nicht zwangsläufig.
      Vor langer Zeit habe ich anonym an einem Open-Source-Projekt gearbeitet, das ich hier nicht nennen möchte. Der Lead-Programmierer hatte einen Co-Maintainer, den er offenbar ziemlich gut kannte.
      Dieser Co-Maintainer hat mich und später andere Maintainer immer wieder gegaslightet, herabgewürdigt und wegen winziger Bugs beschuldigt, bis wir gegangen sind. Wenn man die Beleidigungen herausnimmt, war es auch nicht mit einem lehrreichen Linus-Torvalds-artigen Anschiss vergleichbar.
      Der Lead-Maintainer ermutigte ihn darin, weil er dem technischen Kern seiner Argumente zustimmte.
      Einige Jahre später versuchte dieser Co-Maintainer, das Projekt feindlich zu übernehmen, und es lief nicht wie erwartet. Kurz darauf wurden mehrere private Schreiben veröffentlicht, aus denen hervorging, dass er das schon immer gewollt hatte und dass das Gaslighting der anderen Maintainer Teil dieses Ziels war.
      All das passierte, obwohl die beiden sich kannten.

  • Alle gehen davon aus, dass diese Backdoor früh entdeckt wurde, aber möglicherweise hat sie ihr Ziel bereits erreicht.
    Besonders dann, wenn das Ziel Entwickler waren, die Rolling-Release-Distributionen wie Kali oder Debian nutzen.

    • Möglich ist es.
      Anfang der Woche habe ich mir etwas SSH-Traffic angesehen, mir damals aber nicht viel dabei gedacht.
      Natürlich kann das auch eine falsche Fährte sein: https://www.nubi-network.com/news.php?id=21

  • Das Mem, dass „Lasse Collin xz Utils nicht oft oder schnell genug aktualisiert hat“, war ein Fehler.

  • Ich verstehe nicht, warum SSH xz verwendet.
    Muss das so sein? Ist das wirklich so wichtig?

    • OpenSSH verwendet xz nicht.
      OpenSSH zog libsystemd herein, um Startbenachrichtigungen bereitzustellen, und libsystemd zog liblzma herein. Normalerweise landet der Code von liblzma nicht in OpenSSH.
      Da es aber als Abhängigkeit von libsystemd gebaut wird, läuft das Build-Skript in derselben Umgebung wie libsystemd und OpenSSH.
      Die Angriffs-Payload war im Testverzeichnis von liblzma als obfuskierter binärer Blob versteckt, getarnt als komprimierter Testfall.
      Wenn man lzma aus den git-Quellen kompilierte und die Build-Skripte mit autotools erzeugte, war nichts Verdächtiges zu sehen. In den Source-Tarballs, die Distributions-Paketierer verwenden, war autotools jedoch bereits ausgeführt worden, und der Angreifer hatte die automatisch generierte, schwer lesbare Skriptausgabe ausgetauscht.
      Dieses Skript prüfte, ob liblzma in derselben Umgebung wie OpenSSH kompiliert wurde und ob es für ein .deb- oder .rpm-Paket kompiliert wurde. Wenn beides zutraf, schleuste es die Angriffs-Payload in OpenSSH ein.
      Danach führte die Payload mehrere Prüfungen durch: ob OpenSSH normal über ein Init-Skript gestartet oder manuell ausgeführt wurde, ob gängige Debugging-Tools vorhanden waren und Ähnliches. Nur wenn es wie ein „natürlicher“ Boot ohne Debugging-Tools aussah, hängte sie sich an den laufenden Prozess.
      Zur Laufzeit hookte sie die Validierung privater Schlüssel; wenn mit dem richtigen privaten Schlüssel ein Login versucht wurde, rief sie den Rest des eingehenden Pakets über system auf und ermöglichte so Remote Code Execution mit Root-Rechten.
    • OpenSSH verwendet xz nicht, aber in einigen Distributionen kommt xz bei der Integration mit systemd zum Einsatz.