Forum: Offtopic CVE-2024-3094: Backdoor in Linux Tool XZ


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

- 
https://www.helpnetsecurity.com/2024/03/29/cve-2024-3094-linux-backdoor/
- https://www.openwall.com/lists/oss-security/2024/03/29/4
- https://archlinux.org/news/the-xz-package-has-been-backdoored/

TLDR
1
The cause of the vulnerability is actually malicious code present in 
2
versions 5.6.0 (released in late February) and 5.6.1 (released on March 9) 
3
of the xz libraries

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

War offenbar sehr sorgfältig geplant und vorbereitet:

https://boehs.org/node/everything-i-know-about-the-xz-backdoor

: Bearbeitet durch Moderator
von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

Ja, die haben sich da echt mühe gegeben.
Zum Glück relativ schnell aufgefallen.

von Stephan S. (uxdx)


Lesenswert?

Wenn so etwas 3 Jahre lang vorbereitet wird, ausgerechnet bei XZ, das 
z.B. für die Verteilung von Datenträger-Images verwendet wird (Raspberry 
OS !!!), dann taucht die Frage auf: was steckt dahinter?

EDIT
Ich habs: LZMA wäre auch betroffen, sodass teilweise OpenSSH indirekt 
(über systemd) betroffen wäre

: Bearbeitet durch User
von Le X. (lex_91)


Lesenswert?

Stephan S. schrieb:
> EDIT
> Ich habs: LZMA wäre auch betroffen, sodass teilweise OpenSSH indirekt
> (über systemd) betroffen wäre

Yep, diese Kausalkette gab es heute Nacht schon beim fefe erläutert.

Vor der genialen Umsetzung dieses Angriffes habe ich ja schon etwas 
Respekt.

von Norbert (der_norbert)


Lesenswert?

Da würde man sich schon wünschen das man diese Leute erwischt und sie zu 
einem Baseball-Spieleabend einlädt…

von Dergute W. (derguteweka)


Lesenswert?

Moin,

War nicht "neulich" auch mal was aehnlich clever gemachtes in jbig-kit?
Also Augen auf beim komprimieren...

Gruss
WK

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?


von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

Stephan S. schrieb:
> was steckt dahinter?
Riecht nach einem staatlichen Aktuer.
Und ssh belauschen ist immer interessant.

Stephan S. schrieb:
> LZMA wäre auch betroffen, sodass teilweise OpenSSH indirekt
> (über systemd) betroffen wäre
systemd ist dabei relativ egal und nicht das Problem, auch wenn das 
einige Leute gerne so sehen möchten. xz wird von genug anderen sachen 
benutzt.
1
$ paru -Rns xz
2
checking dependencies...
3
error: failed to prepare transaction (could not satisfy dependencies)
4
:: removing xz breaks dependency 'xz' required by arm-none-eabi-gdb
5
:: removing xz breaks dependency 'xz' required by base
6
:: removing xz breaks dependency 'xz' required by bind
7
:: removing xz breaks dependency 'xz' required by botan
8
:: removing xz breaks dependency 'xz' required by botan2
9
:: removing xz breaks dependency 'xz' required by ffmpeg
10
:: removing xz breaks dependency 'xz' required by ffmpeg4.4
11
:: removing xz breaks dependency 'xz' required by file
12
:: removing xz breaks dependency 'xz' required by gdb
13
:: removing xz breaks dependency 'xz' required by gimp
14
:: removing xz breaks dependency 'xz' required by grub
15
:: removing xz breaks dependency 'xz' required by imagemagick
16
:: removing xz breaks dependency 'xz' required by imlib2
17
:: removing xz breaks dependency 'xz' required by karchive
18
:: removing xz breaks dependency 'xz' required by kmod
19
:: removing xz breaks dependency 'xz' required by lib32-xz
20
:: removing xz breaks dependency 'xz' required by libarchive
21
:: removing xz breaks dependency 'xz' required by libelf
22
:: removing xz breaks dependency 'liblzma.so=5-64' required by libelf
23
:: removing xz breaks dependency 'xz' required by libtiff
24
:: removing xz breaks dependency 'xz' required by libunwind
25
:: removing xz breaks dependency 'xz' required by libxml2
26
:: removing xz breaks dependency 'xz' required by libxmlb
27
:: removing xz breaks dependency 'xz' required by libxslt
28
:: removing xz breaks dependency 'xz' required by lldb
29
:: removing xz breaks dependency 'xz' required by megaman-rocknroll
30
:: removing xz breaks dependency 'xz' required by minizip-ng
31
:: removing xz breaks dependency 'xz' required by perf
32
:: removing xz breaks dependency 'xz' required by raptor
33
:: removing xz breaks dependency 'xz' required by rustup
34
:: removing xz breaks dependency 'xz' required by systemd
35
:: removing xz breaks dependency 'xz' required by systemd-libs
36
:: removing xz breaks dependency 'xz' required by wxwidgets-common
37
:: removing xz breaks dependency 'xz' required by zstd

von (prx) A. K. (prx)


Lesenswert?

Kaj G. schrieb:
> Zum Glück relativ schnell aufgefallen.

Aber wie steht es um jene Fälle, in denen es nicht aufgefallen ist?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Kaj G. schrieb:
> systemd ist dabei relativ egal und nicht das Problem,

Offenbar schon, wenn man davon ausgeht, dass es das Ziel ist, in sshd 
einzubrechen (um auf diese Weise ein Einfallstor zu bekommen). Das wäre 
rein über lzma nicht ohne systemd's Mitwirkung gegangen, da sshd 
eigentlich nichts mit lzma zu tun hat.

Nach allem, was bisher analysiert worden ist, ist /usr/sbin/sshd 
explizit darin erwähnt, in allen anderen Fällen macht die Backdoor 
vermutlich gar nichts.  gdb oder rustup und dergleichen sind halt für 
einen Remote-Angriff eher uninteressant …

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

xz-Attacke: Hintertür enträtselt, weitere Details zu betroffenen Distros
https://www.heise.de/news/xz-Attacke-Hintertuer-entraetselt-weitere-Details-zu-betroffenen-Distros-9671588.html

"I'm watching some folks reverse engineer the xz backdoor, sharing some 
preliminary analysis with permission."
https://bsky.app/profile/did:plc:x2nsupeeo52oznrmplwapppl/post/3kowjkx2njy2b

von Bauform B. (bauformb)


Lesenswert?

Stephan S. schrieb:
> Ich habs: LZMA wäre auch betroffen, sodass teilweise OpenSSH indirekt
> (über systemd) betroffen wäre

Indirekt, weil sshd mit libsystemd gelinkt wird, was nur nötig ist, weil 
systemd sonst nicht richtig funktioniert. So ein sshd ist selbst von 
liblzma abhängig und deshalb angreifbar. Dafür muss systemd nicht einmal 
installiert sein.

Nebenbei: auch der kernel benutzt xz.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Bauform B. schrieb:
> So ein sshd ist selbst von liblzma abhängig und deshalb angreifbar.

Nö, bei mir nicht.

von Mario M. (thelonging)


Lesenswert?

Kaj G. schrieb:
> Zum Glück relativ schnell aufgefallen.

Debian stable rulez! 😂

von Bauform B. (bauformb)


Lesenswert?

Jörg W. schrieb:
> Bauform B. schrieb:
>> So ein sshd ist selbst von liblzma abhängig und deshalb angreifbar.
>
> Nö, bei mir nicht.

Das Paket braucht die Abhängigkeit wohl nicht, weil dpkg von liblzma5 
abhängt und dpkg ist priority: required. Aber:
1
# lsof -c sshd | grep lzma
2
(...) /usr/lib/x86_64-linux-gnu/liblzma.so.5.4.1

von Bauform B. (bauformb)


Lesenswert?

Jörg W. schrieb:
> Bauform B. schrieb:
>> So ein sshd ist selbst von liblzma abhängig und deshalb angreifbar.
>
> Nö, bei mir nicht.

Das Paket braucht die Abhängigkeit wohl nicht, weil dpkg von liblzma5 
abhängt und dpkg ist priority: required. Aber:
1
# lsof -c sshd | grep lzma
2
(...) /usr/lib/x86_64-linux-gnu/liblzma.so.5.4.1

Mario M. schrieb:
> Kaj G. schrieb:
>> Zum Glück relativ schnell aufgefallen.
>
> Debian stable rulez! 😂

Meinten Sie
1
Reverting the backdoored version to a previous version is not
2
sufficient to know that Jia Tan has not hidden other backdoors
3
in it. Version 5.4.5 still contains the majority of those commits.
4
5
I'd suggest reverting to 5.3.1.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024

: Bearbeitet durch User
von Mario M. (thelonging)


Lesenswert?

"Right now no Debian stable versions are known to be affected."
 https://lists.debian.org/debian-security-announce/2024/msg00057.html

von Frank K. (frank)


Lesenswert?

(prx) A. K. schrieb:
> Kaj G. schrieb:
>> Zum Glück relativ schnell aufgefallen.
>
> Aber wie steht es um jene Fälle, in denen es nicht aufgefallen ist?

Opensuse empfiehlt alle Systeme die betroffen sein könnten neu zu 
installieren: https://news.opensuse.org/2024/03/29/xz-backdoor/

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Bauform B. schrieb:
> Das Paket braucht die Abhängigkeit wohl nicht, weil dpkg von liblzma5
> abhängt und dpkg ist priority: required.

Mag sein. Ich habe kein dpkg. ;-)

Allerdings würde deine Annahme auch voraussetzen, dass der Schadcode 
sich selbst über das reine Dekomprimieren in den sshd einnisten können. 
Danach sieht es nach jetzigen Erkenntnissen ja überhaupt nicht aus, 
sondern obwohl er gern sshd angreifen möchte (verständlich), benutzt er 
den Umweg, um über systemd und dessen Abhängigkeiten aufgerufen zu 
werden.

von (prx) A. K. (prx)


Lesenswert?

Frank K. schrieb:
>>> Zum Glück relativ schnell aufgefallen.
>>
>> Aber wie steht es um jene Fälle, in denen es nicht aufgefallen ist?
>
> Opensuse empfiehlt alle Systeme die betroffen sein könnten neu zu
> installieren: https://news.opensuse.org/2024/03/29/xz-backdoor/

Ich dachte oben eher an andere Backdoors in wichtigen Produkten, die 
niemandem auffielen, und die seit Jahren unerkannt in den Systemen 
stecken.

Mario M. schrieb:
> "Right now no Debian stable versions are known to be affected."

Das ist eine entscheidende Aussage. Hoffentlich korrekt.
Ähnliches fand ich zu Red Hat bzgl RHEL, und Ubuntu.

: Bearbeitet durch User
von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

Jörg W. schrieb:
> benutzt er den Umweg, um über systemd
weil ssh und systemd mit den gleichen rechten laufen wenn ssh über 
systemd gestartet wird. wenn ich ein rustup aufrufe wäre es auffällig 
wenn ich plötzlich sudo aufrufen müsste. und bei einem aufruf von gdb 
triggert der exploit ja absichtlich nicht.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

rustup oder gdb sind für den Exploit reichlich uninteressant. Selbst, 
wenn GDB mal einen TCP-Port öffnet, ist der eh verfirewallt.

sshd ist interessant, weil er an vielen Stellen offen ist und man 
darüber auch tatsächlich remote eindringen kann.

von Daniel A. (daniel-a)


Lesenswert?

Bezüglich systemd, vor 8 Jahren hab ich das hier geschrieben:
https://github.com/Daniel-Abrecht/fuck_systemd
> Too many different things have been merged into systemd, too many things
> depend on it. Take libsystemd0 for example, the same library contains, among
> other things, functions to notify systemd about service state changes
> (sd_notify), and functions to log messages using journalctl (sd_journal_send).
> Those are some completely unrelated things which belong into different
> libraries, so they can be replaced easily.

TLDR: Unterschiedliche APIs, wie sd_notify, sd_journal_*, gehören in 
unterschiedliche Libraries, nicht alle in libsystemd0.

Um sd_notify zu implementieren, braucht man kein liblzma, man öffnet nur 
einen Socket und sendet was da hin. Wäre das eine eigene Library 
gewesen, wäre sie daher sicher nie von liblzma abhängig gewesen, 
vermutlich sogar von gar keiner weiteren Library.

Hier also mal wieder, systemd hat ein eigentlich gutes User Interface, 
gute cli Tools. Aber die Technische Umsetzung dahinter, die Aufteilung 
und Abhängigkeiten zwischen den Komponenten, sind einfach weiterhin 
falsch. Mir passt das nicht, weil die dann schwerer ersetzbar sind, und 
jenachdem nicht ohne Systemd laufen. Aber hier hatte es nun sogar 
Sicherheitsrelevante Auswirkungen!

Ich wünschte, die Entwickler hätten mal eine Erleuchtung, und würden ein 
kräftiges Refactoring durchführen. Aber daraus wird wohl nichts werden. 
Stattdessen laden sie die libs jetzt bei erster Verwendung mit dlopen...

von Daniel A. (daniel-a)


Lesenswert?

Bauform B. schrieb:
> Das Paket braucht die Abhängigkeit wohl nicht, weil dpkg von liblzma5
> abhängt und dpkg ist priority: required.

Ich habe bei mir auch nochmal nachgesehen, in devuan, mit ldd. Das 
libsystemd0 von libelogind-compat (der default dort) hängt nicht davon 
ab. Das libsystemd0 von systemd schon.

Auch lsof zeigt hier kein liblzma:
1
root@dragonfly:~# lsof -c sshd | grep lzma
2
root@dragonfly:~#

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Daniel A. schrieb:
> Aber hier hatte es nun sogar Sicherheitsrelevante Auswirkungen!

Das war just auch mein Eindruck, nachdem ich das gelesen hatte.

Dass man das alte /sbin/init ablösen wollte, ist verständlich. Aber eine 
eierlegende Wollmilchsau stattdessen ist fragwürdig.

Aber nicht meine Baustelle …

von Bauform B. (bauformb)


Lesenswert?

Jörg W. schrieb:
> Daniel A. schrieb:
>> Aber hier hatte es nun sogar Sicherheitsrelevante Auswirkungen!
>
> Das war just auch mein Eindruck, nachdem ich das gelesen hatte.

Ja, ohne den sd_notify Patch wären libsystemd und liblzma nicht nötig. 
Dann hätte man genau den gleichen Angriff eben mit einer anderen lib 
realisiert. OK, andere libs werden nicht von so vielen Programmen 
benutzt, aber was nützt das dem Angreifer?

Der sshd benutzt z.B. libz aka zlib, muss der sshd png-Bilder auspacken? 
Egal, meinetwegen soll er, aber deren Homepage macht auch nicht den 
Eindruck, dass da ein großes junges Team dahinter steht. Oder die 
libwrap, Wietse Venema's TCP wrappers, stammt auch von einem 
Einzelkämpfer, oder? Aber so richtig stilecht wäre es natürlich, die 
libselinux zu missbrauchen :)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Bauform B. schrieb:
> Der sshd benutzt z.B. libz aka zlib, muss der sshd png-Bilder auspacken?

Datenströme lassen sich optional komprimieren.

von Kurt (Gast)


Angehängte Dateien:

Lesenswert?

xkcd

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Kurt schrieb:
> xkcd

Nur wieder aufgewärmt, das war log4j.

von Thomas W. (thomas_v2)


Lesenswert?

Jörg W. schrieb:
> Kurt schrieb:
>> xkcd
>
> Nur wieder aufgewärmt, das war log4j.

Wobei der Angriffspunkt wohl ähnlich ist: Nicht das Hauptprojekt selber 
anzugreifen, sondern prüfen, welche Abhängigkeiten bestehen, und dann 
versuchen in diese meistens eher unbeachteten Projekte die Hintertüren 
einzuschleusen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

log4j war aber meiner Erinnerung nach ein Bug, kein vorsätzlich 
gefahrener Angriff. Das ist schon noch ein Unterschied.

von Steve van de Grens (roehrmond)


Lesenswert?

Jörg W. schrieb:
> log4j war aber meiner Erinnerung nach ein Bug

Es war featuritis. Man hat mächtige "coole" Funktionen eingebaut, ohne 
sich der Konsequenzen bewusst zu sein.

Weniger ist mehr.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Steve van de Grens schrieb:
> Es war featuritis.

Aber eben schon anders als hier, mit einer langfristig geplanten 
Backdoor.

von Alexander (alecxs)


Lesenswert?

Schlagzeilen

Wie die Open-Source-Community an Ostern die Welt gerettet hat

von Le X. (lex_91)


Lesenswert?

Alexander schrieb:
> Schlagzeilen
> Wie die Open-Source-Community an Ostern die Welt gerettet hat

Eher ein einsamer Held von Microsoft.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.