- 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 |
|
2 |
|
3 |
|
War offenbar sehr sorgfältig geplant und vorbereitet:
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
Ja, die haben sich da echt mühe gegeben. Zum Glück relativ schnell aufgefallen.
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
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.
Da würde man sich schon wünschen das man diese Leute erwischt und sie zu einem Baseball-Spieleabend einlädt…
Moin,
War nicht "neulich" auch mal was aehnlich clever gemachtes in jbig-kit? Also Augen auf beim komprimieren...
Gruss WK
Mitlerweile auch auf Heise zu finden:
https://www.heise.de/news/Hintertuer-in-xz-Bibliothek-gefaehrdet-SSH-Verbindungen-9671317.html
was steckt dahinter?
Riecht nach einem staatlichen Aktuer. Und ssh belauschen ist immer interessant.
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 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
12 |
|
13 |
|
14 |
|
15 |
|
16 |
|
17 |
|
18 |
|
19 |
|
20 |
|
21 |
|
22 |
|
23 |
|
24 |
|
25 |
|
26 |
|
27 |
|
28 |
|
29 |
|
30 |
|
31 |
|
32 |
|
33 |
|
34 |
|
35 |
|
36 |
|
37 |
|
Zum Glück relativ schnell aufgefallen.
Aber wie steht es um jene Fälle, in denen es nicht aufgefallen ist?
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 …
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
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.
So ein sshd ist selbst von liblzma abhängig und deshalb angreifbar.
Nö, bei mir nicht.
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 |
|
2 |
|
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 |
|
2 |
|
Kaj G. schrieb:
Zum Glück relativ schnell aufgefallen.
Debian stable rulez! 😂
Meinten Sie
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
"Right now no Debian stable versions are known to be affected." https://lists.debian.org/debian-security-announce/2024/msg00057.html
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/
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.
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.
"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.
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.
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.
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...
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 |
|
2 |
|
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 …
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 :)
Der sshd benutzt z.B. libz aka zlib, muss der sshd png-Bilder auspacken?
Datenströme lassen sich optional komprimieren.
Gast
#7639569
xkcd
Angehängte Dateien:
-
dependency.png
(23 KB)
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.
log4j war aber meiner Erinnerung nach ein Bug, kein vorsätzlich gefahrener Angriff. Das ist schon noch ein Unterschied.
Gast
#7639757
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.
Es war featuritis.
Aber eben schon anders als hier, mit einer langfristig geplanten Backdoor.
Schlagzeilen
Wie die Open-Source-Community an Ostern die Welt gerettet hat
Schlagzeilen Wie die Open-Source-Community an Ostern die Welt gerettet hat
Eher ein einsamer Held von Microsoft.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.