Gestern wurde in der Bibliothek liblzma, die mit dem Paket xz-utils ausgeliefert wird, eine kritische Lücke in Form einer Supply-Chain-Attack entdeckt (CVE-2024-3094). XZ-Utils enthält eine Reihe von Komprimierungsprogrammen für das XZ-Format, die in zahlreichen Linux-Distributionen vorhanden sind. Betroffen sind Rolling-Release-Distributionen, die DEB oder RPM als Paketformat nutzen. Dazu zählen Debian Testing und Unstable, Fedora 40 und Rawhide und openSUSE Tumbleweed sowie openSUSE MicroOS. Arch Linux ist ebenfalls betroffen. Eine weitere Voraussetzung scheint die Verwendung der glibc zu sein.
Entdeckt wurde die Backdoor vom bei Microsoft angestellten PostgreSQL-Entwickler Andres Freund, der sie auch als Erster beschrieb. Am Ende der Seite lässt sich das kleine Script detect.sh herunterladen, das eine vage Aussage trifft, ob ein System vermutlich verwundbar ist oder nicht. Das Script muss zunächst ausführbar gemacht werden.
Betroffene Versionen
Betroffen sind die vor einem Monat respektive drei Wochen erschienenen Versionen 5.6.0 und 5.6.1 von xz-utils. Der bösartige Code findet sich in den Tarballs und ist nicht in den öffentlichen Git-Repositories enthalten. Mittlerweile gibt es reparierte Pakete ohne die schadhafte Payload. Bei Debian etwa die Version 5.6.1+really5.4.5-1, bei Arch 5.6.1-2. Fedora nutzt v5.4.6-3 für das Paket ohne Backdoor, während openSUSE die Versionierung 5.6.1.revertto5.4 nutzt. Wer eine der betroffenen Versionen installiert hat, sollte zunächst sofort auf die neue Version aktualisieren. Wird SSH derzeit nicht benötigt, sollte man den Dienst vermutlich besser abschalten.
Was bisher bekannt ist
Durch eine Reihe komplexer Verschleierungen extrahiert der liblzma-Build-Prozess eine vorgefertigte Objektdatei aus einer getarnten Testdatei im Quellcode, die dann dazu verwendet wird, bestimmte Funktionen im liblzma-Code zu ändern. Das Ergebnis ist eine modifizierte liblzma-Bibliothek, die von jeder Software verwendet werden kann, die gegen diese Bibliothek gelinkt ist, und die die Dateninteraktion mit dieser Bibliothek abfängt und modifiziert.
Mit dieser Supply-Chain-Attack ist ein unbefugter Fernzugriff über SSH durch Umgehung der SSHD-Authentifizierung auf das System nicht auszuschließen. Das gelingt, da beim Start des OpenSSH-Server über den Umweg libsystemd auch liblzma aufgerufen wird. Dabei wird in der kompromittierten Version die Funktion RSA_public_decrypt an Malware-Code weitergeleitet, der die Authentifizierung umgeht und somit direkten Zugriff auf das System ermöglichen kann.
Von langer Hand geplant
Das Paket mit der Backdoor stammt vom Upstream von xz-utils. Offensichtlich hat sich ein böswilliger Akteur über Jahre Einfluss auf das Projekt verschafft, um eine anspruchsvoll programmierte Backdoor einzubauen, deren Ziele und Auswirkungen bisher nicht in Gänze überschaubar sind. Ein Dokument auf GitHub fasst zusammen, was bisher bekannt ist. GitHub hat zudem das Repository von xz geperrt. Der Versuch des böswilligen Akteurs, das Paket auch in Ubuntu hochzuladen, gelang zum Glück nicht.
Der heutige Tag wird vermutlich weitere Erkenntnisse bringen. Klar ist bereits, dass dies eine von langer Hand maliziös und akribisch vorbereitete Attacke ist. Handlungsanweisungen über die sofortige Aktualisierung von xz-utils und dem Abschalten von SSH hinaus gibt es bisher nicht.
> Sicherheitsforscher Andres Freund
https://www.openwall.com/lists/oss-security/2024/03/29/4
> I am *not* a security researcher, nor a reverse engineer.
danke,geändert.
Wie ich das mittlerweile verstanden habe, koennen alle die kein systemd verwenden die Schappatmung zurueck fahren.
Sie sind nicht betroffen.
Ich verstehe nicht, weshalb die bisherige Desinformation munter weiter getragen wird. Um das nochmal in aller Deutlichkeit zu sagen, hat es zu keinem Zeitpunkt eine Manipulation des Quellcode von xz gegeben! Daher ist ebenfalls keine einzige Linux Distribution davon betroffen, die den Quellcode direkt vom Git Repository herunter lädt! Das was hier ausschließlich betroffen war, war das optionale komprimierte Archiv was Github ebenfalls zum Download anbietet. Und dieses Archiv wird offenkundig nur mangelhaft kryptographisch geprüft oder zumindest verglichen, sonst hätte man es nicht einfach ersetzen und schädliche Skripte einfügen können. Dieses ganze Gelaber über staatliche Akteure oder irgendeine Katastrophe, geht maßlos an der Realität vorbei. Und davon gänzlich abgesehen, spielt xz seit längerer Zeit in vielfältigen Bereichen keine Rolle mehr. Nicht zuletzt da es potente Alternativen wie zstd gibt, die im Gegensatz zu xz auch dauerhaft aktiv betreut werden. Dazu zählen selbst Klassiker wie gzip oder bzip2. Und da Archiver ohnehin aus einer Zeit mangelnden Speicherplatzes entstanden sind, was heutzutage genau gegenteilig ist, so reicht für die meisten Fälle einfach tar, gänzlich ohne irgendeine Kompression.
Du hast insofern recht, dass wenn die Pakete nicht aus den Tarballs gebaut würden, dies nie passiert wäre. direkt aus dem Git ist halt etwas mehr Arbeit. Und was die Akteure angeht, was ist denn deine Idee, wer so etwas über Jahre mit einigem an Obfuscation inszeniert?
Devuan ist scheinbar nicht betroffen:
“Devuan is not affected by the latest vulnerability caused by systemd. The malicious backdoor in xz/liblzma is a vector for remote exploitation of the ssh daemon due to a dependency on systemd for notifications and due to systemd’s call to dlopen() liblzma library (CVE-2024-3094)”
https://toot.community/@devuan/112185687582188156
Ja die sind nicht betroffen.
Da Devuan auch kein systemd verwendet.
und wieder etwas in Verbindung mit glibc.
Beste Vermeidung ist musl nutzen.
war da nicht erst vor kurzem die Geschichte mit Snap ist unsicher und für die Containerisierung und Administration die schlechteste Wahl im Umgang mit der Ausrollung
von Code…
So schnell kann es gehen…
Ich habe es nicht verglichen, glaube aber, dass es ein aktuelleres Script gibt (veröffentlicht in der vergangenen Nacht um 2:14 Uhr). Zitat aus einem Heise Artikel:
https://www.heise.de/news/Hintertuer-in-xz-Bibliothek-gefaehrdet-SSH-Verbindungen-9671317.html
Das Script:
https://github.com/cyclone-github/scripts/blob/main/xz_cve-2024-3094-detect.sh
Das Script von Heise fragt zusätzlich die installierte Version von xz-utils ab, ist ansonsten identisch.
Gut das die Seite linuxnews davor gewarnt hat.
Erst Snap, dann Flat (im positiven) und nun dieses Kuckucksei.
Zeigt mMn nur, dass auch Linux immer mehr in den Fokus Gerät.
In diesem Sinn: Frohe Ostern!
Nein, im Linux wird nur besser geprueft.
Aber das scheint ja kein normales Ding zu sein.
Du meinst, dass all die Jahre sich Schad-bzw. manipulierte Software eingeschlichen hat und keiner hat das bemerkt? Erst jetzt wo mehr geprüft wird, bemerken wir das? Ich dachte das “freie” wäre einer der Vorteile von Linux!
Diese Backdoor ist nur durch Zufall entdeckt worden, weil jemand auffiel, dass der Zugriff per SSH seltsam lange dauerte. Dieser Angriff war von langer Hand geplant und minutiös darauf ausgerichtet, möglichst lange unentdeckt zu bleiben. Im Moment gehen Sicherheitsforscher davon aus, dass hier staatliche Akteure am Werk waren. Jetzt obliegt es den Strafverfolgungsbehörden, herauszufinden, woher dieser Angriff kam. Ob das zweifelsfrei gelingt erscheint mir fraglich.
Das ist doch immer so, oder? Genau meine gedanken. schoene Ostern Ferdinand
Na dann lies doch bitte den Beitrag richtig, da stehts doch.
Sorry Ralf, dass war ironisch gemeint. Frohe Ostern!
Unter Arch Linux wurden Pakete mit dem kompromittierten Code angeboten. Allerdings linkt sshd unter Arch Linux nicht gegen liblzma (lässt sich mit dem Befehl ldd $(which sshd) prüfen). Das ganze lässt sich daher in der Praxis nicht ausnutzen (https://security.archlinux.org/ASA-202403-1). Die Nutzer sollten natürlich trotzdem das Update auf die bereinigte Version installieren.
Der Artikel ist nicht ganz korrekt. sshd ist nirgendwo gegen liblzma gelinkt, jedoch auf einigen Systemen gegen libsystemd, welches wiederum liblzma nutzt. Die Kette ist also sshd -> libsystemd ->liblzma.
Mein schwarzes Loch behauptet:
ldd /usr/sbin/sshd | grep -i liblzma
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f7c47844000)
Arch linkt sshd aber auch nicht gegen libsystemd, von dem her ist zumindest der Part scheinbar korrekt 😉
Gentoo rät auch dazu, das Paket nicht weiter zu verwenden, obwohl es so scheint, dass das bösartige Script nur funktioniert, wenn es in einer .deb oder .rpm Umgebung läuft.
Vorsichtshalber ist man auf Version 5.4.2 (die letzte, die nicht mit dem neuen Schlüssel signiert wurde) zurückgegangen.
Unter .deb und .rpm laufen halt die meisten Server, die das vermutliche Ziel sind.
War ein ziemliches Erdbeben, ich habe es nur etwas am Rande beobachtet.
Bemerkenswert finde ich, dass Microsoft die Sache nun einfach wegsperrt. Es gibt noch immer keinen Prozess wie mit so etwas umgegangen wird. Weitere Untersuchungen am Original funktioniert nun nicht mehr.
Ja, das Repo zu sperren war nicht die beste Idee.
Zwei Tage zu früh für einen Aprilscherz und leider auch überhaupt nicht lustig.