xz 5.6.x wurde kompromittiert

[TRex]

https://lwn.net/ml/oss-security/2024032 ... arazel.de/

Betroffen sind testing und neuer, ein aktuelleres Paket ist bereits veröffentlicht.

Auch interessant ist die Diskussion auf Hackernews: https://news.ycombinator.com/item?id=39865810

Relatiert:

- 1067708 (der Upload durch die Sockenpuppe, nicht nur bei debian, sondern auch an vielen anderen Stellen - andere Distris und Github-Projekte)
- Zusammenfassung: https://gist.github.com/thesamesam/2239 ... 78baad9e27
- Eine Analyse: https://boehs.org/node/everything-i-kno ... z-backdoor

[slu]

Autsch! Hoffentlich bleibt Bookworm sauber.

[wanne]

Uff. Ziemlich beeindruckend was da für Aufwand rein gesteckt wurde. Der hat ja mit bestimmt einem dutzend Projekten aktiv kommuniziert um seine Lücke zu verstecken oder ausreden für Obskures Verhalten zu finden. (Debian, RedHat, gcc, Fedora, Google, Gentoo.) Offensichtlich absolut keine Skrupel.
Btw: Schlägt wohl absichtlich nur zu wenn der distro-SSH als systemd-Service läuft um nicht erwischt zu werden. Gut, dass sich da jemand drüber aufgeregt hat, dass sein ssh ca. eine halbe Sekunde länger zum starten braucht.

[MSfree]

Auf meiner Trixie-Kiste wurde die kompromitierte liblzma am 5.3.24 eingespielt. Ich hatte mich auch schon über die Verzögerung beim Login via SSH gewundert.

Heute wurde die hoffentlich saubere Version eingespielt. Die Verzögerung von SSH ist jetzt weg.

Heise hat inzwischen auch einen Artikel:
https://www.heise.de/news/Hintertuer-in ... 71317.html

Die genaue Funktion der Hintertür ist bisher nicht bekannt. Mal sehen, was sich im Laufe der nächsten Tage an Erkenntnissen ergibt und ob durch die Kompromitierung noch weiterer Schaden, z.B. in Form von "versteckten" Programmen, angerichtet wurde.

[schorsch_76]

Das ist ja mein faules Osterei

[michaa7]

Quelle: https://www.heise.de/news/Hintertuer-in ... 71317.html

Der Finder der Hintertür hat ein Bash-Skript geschrieben, um eine potentiell anfällige liblzma-Version auf dem eigenen System zu finden.

https://raw.githubusercontent.com/cyclo ... -detect.sh

[Virya]

Devuan ist scheinbar besser dran:

"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

[wanne]

Devuan is not affected by the latest vulnerability caused by systemd.

Uff Die Medldung ist aber stark irreführend. Der Code bricht die Ausführung absichtlich ab, wenn er nicht in Umgebungen ausgeführt wird, die nicht nach systemd/sshd aussehen, um zu verhindern, durch debugging entdeckt zu werden.
Man kann zwar sagen, dass der sshd unter devuan tatsächlich keine Abhängigkeit nach xz hat. Aber natürlich hängt das trotzdem an zig anderen Stellen im System, an denen der Angreifer genau so hätte zuschlagen können. (z.B. im initramfs beim boot.)

[Virya]

... um zu verhindern, durch debugging entdeckt zu werden ...

Das scheint ja eine ganz üble Sache zu sein. Ich bin gespannt, wie das weiter geht. Leider fehlen mit alle Fähigkeiten solche Dinge tatsächlich zu verstehen.

[Livingston]

Das scheint ja eine ganz üble Sache zu sein.

Es gibt schlimmeres. Zum einen wurde es ja dank eines aufmerksamen Users gerade noch rechtzeitig entdeckt. Zum anderen sind (zumindest in Debian) nur testing und unstable betroffen. In den seltensten Fällen nutzt man diese Releases für öffentlich zugängliche und produktive Server.
Zugegeben: sshd kommt auch im Privatbereich zum Zuge, und natürlich gibt es da auch eine Menge Leute, die testing und unstable auf sensible Daten loslassen. Man sollte dieses aktuelle Ereignis zum Anlass nehmen, sich über Sicherheitskonzepte Gedanken zu machen.

[Stefan]

Hallo zusammen,

eine Aufarbeitung sollte schon stattfinden.
Wer hat die Möglichkeiten und die Intressen an solchen Attacken.
Auch das ein Aufmerksamer User das gefunden hat ist zwar lobenswert, für das Thema Sichrheit ist das aber nicht der beste Weg und wird aus meiner Sicht Linux netgativ belasteten.

[niemand]

für das Thema Sichrheit ist das aber nicht der beste Weg und wird aus meiner Sicht Linux netgativ belasteten.

Ansichtssache. Linux hat damit eher nichts zu tun, eher ist’s das Open-Source-Prinzip. Und da würde ich es es nicht als negativ sehen, sondern darauf verweisen, dass man sowas in Closed-Source-Software nie gefunden hätte, bzw. es dort ungleich einfacher für einen entsprechenden Angreifer wäre: die ganze Zeit, den ausgeklügelten Plan – nichts davon hätte es dort gebraucht.

[katzenfan]

... und wird aus meiner Sicht Linux netgativ belasteten.

Wieso sollte es das?

Das Gute an Linux ist, daß die Software grundsätzlich quelloffen ist und keiner längere Zeit so völlig unbemerkt da was "hineinbuddeln" kann. Und das ist durchaus "pro Sicherheit" zu werten.

[Livingston]

Die Details sind ein starkes Stück: Ein Projekt mit Busfaktor 1 wird ausdauernd mit Hilfe von Social Engeneering aufs Korn genommen und dann am Ende erlegt - so zumindest der Plan.
Die Herangehensweise ließe sich auch gegen einen einsamen, verlorenen Programmierer im Closed Source-Handwerk anwenden, indem man ihm freundlichst Hilfe anbietet und die hohe Arbeitslast abnimmt.

Die Art und Weise, wie das ganze gelaufen ist, schärft bei Open Source zumindest den Blick: Es wird der Finger auf die Wunde gelegt, dass es zahlreiche Projekte gibt, in der sich einzelne Leute den Allerwertesten bis zur Selbstaufgabe aufreißen. Die aktuelle Beihnahe-Katastrophe eröffnet Möglichkeiten, das Problem strukturiert anzugehen. Sehen wir es uns mal bei Debian an: dpkg läuft schon nicht mehr ohne die xz-utils. Das Problem lässt sich nicht mehr ignorieren. Insofern darf man hoffen, dass dieses spezielle Ereignis die Motivation erhöht, die Grundlast bei kritischen Projekten auf mehrere Köpfe zu verteilen.

[ung]

xz-utils 5.6.1+really5.4.5-1 könnte nur der erste Schritt zurück sein, weitere könnten folgen. 1068024

[wanne]

Überraschend guter Artikel beim Standard: https://www.derstandard.at/story/300000 ... hrammt-ist
Hat mir besser gefallen als was viele Fachzeitschriften abgeliefert haben.

[cosinus]

Hi in die Runde,

mir ist noch nicht ganz klar, was nun die Auswirkungen sind. Ich hab hier ja ein Debian/siduction. Da läuft auch sshd. Ist aber übers Internet nicht erreichbar und die Kiste wurde nach Bekanntwerden schon gepatcht, sprich das nicht trojanisierte liblzma ist seit gestern installiert.

Ist die Backdoor trotzdem aktiv weil sshd einmal mit der faulen Version lief oder brauchte es dafür einen Verbindungversuch von außen mit dem richtigen private Key?

[slu]

[...] oder brauchte es dafür einen Verbindungversuch von außen mit dem richtigen private Key?

So hatte ich das seither verstanden, mal sehen was noch kommt.
Vermutlich war das Ziel in Ubuntu 24.04 zu kommen und später eine große Nummer zu starten....

[cosinus]

So hatte ich das seither verstanden, mal sehen was noch kommt.
Vermutlich war das Ziel in Ubuntu 24.04 zu kommen und später eine große Nummer zu starten....

So hatte ich das auch verstanden, war mir nur nicht ganz sicher. Mittlerweile schrieb mir auch einer bei heise.de und bestätigte deine und meine Vermutung siehe https://www.heise.de/forum/heise-online ... 9487/show/

Es muss erst einen Loginversuch mit dem passenden Payload gegeben haben. "Passend" hat hier die Bedeutung, dass nur der Autor der Hintertür einen solchen Payload generieren kann (kryptografisch signiert). Der Payload ist außerdem kryptografisch auf den Host-Key zugeschnitten, funktioniert also nur jeweils für einen einzigen Host (das Ziel-System).



Rein theoretisch könnte der Angreifer, da er bereits Pre-Auth root Rechte hat, das ssh-Log verfälschen und so selbst den SSH-Loginversuch und jegliche weiteren Aktivitäten "unsichtbar" machen... u.a. wegen dieser Ungewissheit baut u.a. Debian deren gesamte Build-Infrastruktur neu auf.


edit: Und nur zur Klarheit: liblzma zu aktualisieren reicht alleine nicht aus. Da die alte Version wahrscheinlich noch im Adressraum von openssh geladen ist, muss mindestens openssh neu gestartet werden, am besten natürlich die ganze Kiste.

[slu]

Das Problem könnte noch größer werden wenn man schaut wer commits in libarchive geliefert hat..

[cosinus]

Das Problem könnte noch größer werden ...

Ich glaube nicht nur ich frage mich gerade, wieviele Hintertüren denn nicht gefunden wurden, die es aber in gängige Distris geschafft haben.
Das faule Ei in liblzma 5.6.x wurde ja nur zufällig gefunden weil da jemand ne Leideschaft für benchmarks hat

[niemand]

Ich glaube nicht nur ich frage mich gerade, wieviele Hintertüren denn nicht gefunden wurden, die es aber in gängige Distris geschafft haben.

Das fragen sich derzeit wirklich viele Leute …

[OrangeJuice]

Vermutlich war das Ziel in Ubuntu 24.04 zu kommen und später eine große Nummer zu starten....

Das hatten sie schon geschafft, allerdings nur die proposed-Quellen, die nicht ab Werk aktiviert sind.

The affected version of xz-utils was only in noble-proposed, and
was removed before migrating to noble itself. No released
versions of Ubuntu were affected by this issue. Quelle

[schorsch_76]

Ich frage mich ja gerade, warum libsystemd libarchive/liblzma lädt. Laut man Page deutet libsystemd/bzw. der Patch für systemd-notify eigentlich nicht in die Richtung Kompression. Welches Feature von systemd nutzt Kompression?

https://github.com/openssh/openssh-portable/pull/375
https://www.man7.org/linux/man-pages/ma ... emd.3.html

Edit: Auch eine gute Feststellung:
https://news.ycombinator.com/item?id=39878181

It's not pulled in on any sysvinit Debian system I run. It is on stable, oldstable, and oldoldstable systems via systemd.

[OrangeJuice]

Ich glaube nicht nur ich frage mich gerade, wieviele Hintertüren denn nicht gefunden wurden, die es aber in gängige Distris geschafft haben.

Da war doch was mit NPM...
Paketmanager npm: Entwickler macht eigene Packages unbrauchbar