News Sicherheitslücke in xz: Backdoor in Linux-Archivbibliothek macht Systeme angreifbar

[Sweepi]

"Sicherheitslücke in xz"
Ich finde das fuer den normalen User missverstaendlich.
In xz ist keine Sicherheitsluecke, sondern absichtlich böser Code. (CVE Type 506: "Embedded Malicious Code")

 

[Krik]

Die Steam Decks sind nicht betroffen. Aber da läuft ja ein modifiziertes Arch Linux drauf. Das soll ja diesen Angriffsvektor nicht haben.

$ ldd "$(command -v sshd)"
        linux-vdso.so.1 (0x00007ffe78d18000)
        libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x00007f810d907000)
        libpam.so.0 => /usr/lib/libpam.so.0 (0x00007f810d8f6000)
        libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x00007f810d200000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00007f810d8a2000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00007f810d7ca000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007f810d7b0000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f810d016000)
        libaudit.so.1 => /usr/lib/libaudit.so.1 (0x00007f810d784000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00007f810d756000)
        libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x00007f810d750000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00007f810d742000)
        libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0x00007f810d73b000)
        libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007f810d727000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f810da91000)
        libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0x00007f810d71f000)

 

[Dalek]

Es ist hier jetzt nochmal glimpflich verlaufen, aber das war mehr Glück. Das hat ein Postgres-Experte zufällig gefunden weil die Backdoor Performanceprobleme verursacht hat. Und in vielen Distros ist die Version noch nicht drin gewesen, das wäre aber mit der Zeit sicher noch passiert.

Eine andere Frage ist hier ob das die erste Lücke ist die über diese Person (oder die Gruppe/Geheimdienst die hinter dieser Identität stecken) eingeschleust wurde.

 

[HaZu]

Wenn Sicherheitslücken bei closed source nicht bemerkt werden können, wie kommt es dann, dass es trotzdem etliche Sicherheitslücken gibt? Wie kommen Jailbreaks zustande?
Dieser ewige Mythos von "OS ist sicherer" ist absoluter Unfug.

Hab ich auch nicht behauptet. Da steht erst mal nur, dass diese Backdoor gefunden wurde, weil jemand den SC analysieren konnte.

 

[entropie88]

Ich hab mir schon gestern das Orginal durchgelesen.

Es betrifft nur Distributionen die sshd gegen systemd (liblzma) linken. Nur in diesem fall wird bei der Nutzung von sshd Code nachgeladen.

Nutzbar war die Backdor nur in Fedora Rawhide und Debian Testing. Und das nur kurz.

Es gab nie ein Problem?

 

[DFFVB]

@Kaito Kariheddo Vorbildlich geschriebener Artikel! Das wünsvht man sich häufiger bei Security Issues. Nicht einfahc nur wilde Panikmache, sondenr genau was los ist wer wie wo wann betroffen ist. 👍

 

[ghecko]

Es betrifft nur Distributionen die sshd gegen systemd (liblzma) linken. Nur in diesem fall wird bei der Nutzung von sshd Code nachgeladen.

Auf dem git ist man sich da noch nicht so sicher:

It may activate in other scenarios too, possibly even unrelated to ssh.

https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
Der Code und die Funktionen dahinter scheinen noch nicht komplett analysiert.

 

[BFF]

Würde mich nicht wundern, wenn China dahintersteckt.

Mein Lütter ist sich da fast sicher.
Rein wegen gefundener Gemeinsamkeiten/Auffälligkeiten zu Sachen womit er sich eigentlich beschäftigt.

 

[Tanzmusikus]

@Kaito Kariheddo

"Sicherheitslücke in xz"
Ich finde das fuer den normalen User missverstaendlich.
In xz ist keine Sicherheitsluecke, sondern absichtlich böser Code. (CVE Type 506: "Embedded Malicious Code")

 

[Tornhoof]

diese Backdoor genau macht

Wie auch im arstechnica Post steht, ist das aktuell nicht wirklich klar, es ist zwar klar was der Code macht und wieso er zb soviel CPU Last erzeugt, aber das wieso und das Ziel ist unklar, da bisher kein aktiver Angriff identifiziert wurde. Je nach wem man glaubt, ist's die Lücke identifiziert wurden bevor sie aktiv ausgenutzt wurde, einfach auch, weil die meisten Distributionen die Version nicht im stable Zweig hatten und es nicht viele gibt, die Rolling Distributionen produktiv einsetzen.

 

[Laktose-Larry]

Laut Will Dormann sind wohl nur Redhat Rawhide-Benutzer und Kali-Benutzer betroffen, die zwischen dem 26. und 29. März aktualisiert haben:

https://x.com/wdormann/status/1774058618729419155?s=20

 

[Multivac]

Ein billiger Strohmann war gerade nicht zur Hand?

Zumindest der Mensch/die Gruppe hinter diesem Angriff ist nicht deiner Meinung, denn sie haben die entscheidende Payload nicht commited, sondern haben den RedHat/Fedora/Debian/... Maintainern eine spezielle Version gegeben, dessen Buildscript nach dem Bauen aus dem sauberen Sourcecode das Binary gepatched hat...
Warum die Angreifer wohl drauf verzichtet haben, die Backdoor direkt im Sourcecode einzubauen?

Hast du uberhaupt den orignal post von Andres Freund gelesen? Der Hauptteil der backdoor war in
tests/files/bad-3-corrupt_lzma2.xz
tests/files/good-large_compressed.lzma
Der payload war im repo. Die backdoor ist aufgefallen weil die kompromitieren binarys scheisse waren nicht weil sich jemand das repo anguckte.

 

[Tornhoof]

Wer C kann und was lesen will
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7

(Finde den Trick wie Landlock deaktiviert wird)

Lösung hier:

Spoiler

https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00

 

[Photon]

Lösung hier:

Das ist ja kein C sondern was auch immer cmake für eine Syntax hat (die ich nicht kenne). Was bewirkt denn der Punkt in dem Kontext?

 

[Tzk]

Es kommt übrigens noch hinzu, dass der Autor der Lücke zusätzlich noch bei diversen Projekten angefragt und um Aktualisierung der Verlinkungen auf die 5.6.0 bzw 5.6.1 Version von XZ gebeten hat. Also genau die, wo im TAR der Code eingeschleust wurde.

Hier hat jemand sehr viel Zeit und Geduld investiert um eine (potenzielle) Lücke zu implementieren und verbreiten.

 

[Laktose-Larry]

Dave Anderson / Mar 30, 2024, 18:10:

"The poor original maintainer of xz is on it now, and has already found another "fun" thing:
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00

The configure check for enabling the Landlock sandboxing facility was subtly broken, so that Landlock support would never get enabled. The original malicious commit landed around the same timeframe as the main backdoor, also at an abnormal time of day compared to the new maintainer's historical activity pattern."

https://hachyderm.io/@danderson/112185746000358589

 

[Tornhoof]

Das ist ja kein C

Der Teil in "check_c_source_compiles" ist C. Siehe auch
https://cmake.org/cmake/help/latest/module/CheckCSourceCompiles.html


Ich hab keine Ahnung was der dot da exakt macht, aber er führt wohl dazu, dass die Methode nicht geprüft wird. Also my_sandbox nicht dabei ist. Effektiv macht er dem ganzen Check nutzlos.

Das ist so advanced C fuckery, da habe ich keine Ahnung von

 

[dev/random]

Es betrifft nur Distributionen die sshd gegen systemd (liblzma) linken. Nur in diesem fall wird bei der Nutzung von sshd Code nachgeladen.

Ohne eine vollständige Analyse der verdächtigen commits und des eingeschleusten Codes gibt, halte ich so eine Aussage für etwas optimistisch.
Der bisher bekannte Angriffsvektor auf den openssh server nutzt systemd und liblzma (und glibc).
Das bedeutet aber nicht, dass es keine weiteren Angriffsvektoren oder Auswirkungen geben kann.

 

[konkretor]

Danke für die News.

Github hat aktuell das Repository vom Netz genommen. Was ziemlich dumm ist, da jetzt erstmal nicht jeder sich den Code und die Vorgehensweise analysieren kann. Es ist möglich das es noch mehr solcher Angriffe auf andere Pakete gibt.

 

[Savage_Sinusoid]

Zu ldd: Der heise Artikel zum Thema verlinkt ein FAQ, das davon abrät, ldd auf untrusted binaries auszuführen, da dabei unter Umständen Code des Binaries ausgeführt wird. Wusste ich vorher nicht, und frage mich, ob es da so clever ist ldd zu nehmen um zu schauen ob man betroffen ist 🤔.

Vergl.:
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
https://jmmv.dev/2023/07/ldd-untrusted-binaries.html

Beste Alternative ist die Verwendung von libtree $(command -v sshd). Unter Fedora/CentOS/RHEL muss man dafür das Paket libtree-ldd installieren; unter Debian/Ubuntu/etc. und Gentoo heißt das Paket libtree. Wer Arch nutzt, geht leer aus und muss es händisch von GitHub runterladen und kompilieren.

Der Unterschied zu ldd ist, dass libtree die zu untersuchende Binärdatei nicht durch den dynamischen Lader jagt (also partiell ausführt), sondern sie nur einliest und die relevanten ELF-Sektionen parst. Außerdem prozuziert es eine schicke Ausgabe in bunt und gut lesbar als Baumstruktur!