Follow-Up: xz-utils / liblzma backdoored

Lasse Collin, der Original Author von XZ, hat sich des Problems bereits angenommen und andere Änderungen zurück genommen, die von dem „Jin Tan“ Angreifer gemacht wurden.

Follow-Up: xz-utils / liblzma backdoored

z.B. wurde die Sandbox wieder aktiviert, die absichtlich sabotiert wurde:

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

Das bedeutet für XZ, daß wir bald sehr viel mehr zu dem Ausmaß dieses Angriffsversuches wissen werden.

Im Gegensatz zu Fedora Devs auf der Mailingliste, hat das FOSS Sicherheitssystem versagt, weil die ganze Sache nur durch Zufall, nicht durch  Codereviewing wie es für OpenSource eigentlich gedacht ist, entdeckt wurde. Es gibt also noch viel zu verbessern, z.B. resultiert das ursprüngliche Problem darin, daß liblzma in Systemd verlinkt ist, damit der JournalD die Logfiles komprimieren kann. Zwei andere Kompressionsbibliotheken sind aber auch aus dem gleichen Grund eingebunden. Hier ist also eine einfach Möglichkeit die Angriffsfläche zu reduzieren, was im Umkehrschluss bedeutet, daß das erwählt Kompressionssystem besser überwacht werden wird, weil es das muß.

Wer mal wissen will, wann der Angriff in  die Tat umgesetzt wurde:

https://git.tukaani.org/?p=xz.git;a=commit;h=6e636819e8f070330d835fce46289a3ff72a7b89

Da kann man auch die Emailadresse des Angreifers sehen, vielleicht kennt ja wer wen bei der Google Security.

xz-utils / liblzma backdoored

Was für ein Morgen, wenn man so etwas liest, dann kräuseln sich einem erst einmal die Nägel. Aber fangen wir vorn an:

Die XZ Utilities beinhalten u.a. das XZ Kompressionsprogramm, was aber nicht Ziel des Angriffs war, sondern die Libs, die andere Programm benutzen um XZ und LZ Kompressionen durchzuführen. Das sind Kompressionsverfahren, die teilweise noch aus tiefster Vergangenheit stammen. In den 80er hatten wir auf dem Amiga schon LZH Kompressionsprogramme, die komprimierte Archive erzeugt oder ausgepackt haben.

XZ ist eine aktuelle Weiterentwicklung davon, die u.a. für die Kompression des Linuxkernelimages in /boot benutzt wird.

xz-utils / liblzma backdoored

Ohne Euch zu sehr mit Details zu nerven, zunächst mal was wir wissen:

Der Angriff wurde seit ~2.5 Jahren vorbereitet.

Ein GitAccount namens „Jin Tan/JinT75“ unterstützte den Author von XZ Lasse Collin vor 2-2.5 Jahren das erste mal offiziell. Erwähnt wird er von Collin im Juni 2022 im Zuge des JAVA Teils von XZ. Aus dem Post von Collin geht hervor, daß der User schon seit einiger Zeit hinter den Kulissen mit Collin kommuniziert und „Aushilft“.

Das XZ Projekt wird von Collin als Hobbyprojekt klassifiziert, da er auch quasi der Einzige ist, der daran Änderungen macht. Das dürfte der Grund sein, wieso sich die Angreifer XZ ausgesucht haben, denn Collin gibt in dem Post selbst an, daß er Psychische Probleme hat und sich nicht um das Projekt kümmern kann.  Da sind ideale Voraussetzungen für die Angreifer, da er ein dankbares Ziel für Hilfe ist.

Durch die Kette, das Systemd auf die XZ liblzma setzt und SSH mit Systemd daher angreifbar ist, machte XZ zum Ziel. Auch andere externe Teile, die von SSH genutzt werden, könnten betroffen sein, nur das da noch keiner nachgesehen hat.

Betroffen sind bislang nur Paketversionen >= 5.6.0 xz-libs

Die offensichtlichen Backdoor Commits auf Github sind bislang nur für die Version 5.6.0 und 5.6.1 identifiziert worden.
Bei Debian läuft aber eine Diskussion, ob man nicht auf 5.3.1 zurück gehen müßte, weil da die ersten, nicht eindeutig zuordenbaren Commits von „Jin Tan“ beginnen. Es müsse schliesslich alles als Teil der Backdoor angesehen werden.

Natürlich würde ein Angreifer den Author erstmal mit hilfreichem Code anfixen, so daß er Vertrauen aufbaut. Insofern sind vermutlich nicht alle Codezeilen ein Problem. Wissen kann man das natürlich nicht, da die Backdoor vielleicht nur die neueste Ausartung des Angriffs darstellt.

Nehmen wir an, im Code wurde ein Bufferoverflow eingebaut, mit dem ein RCE möglich ist, wenn z.b. ein TAR Archiv ausgepackt wird. Das könnte schon vor 2 Jahren in den 5.4er Zweig eingebaut worden sein, insofern ist die Annahme, das alles von „Jin Tan“ Schadcode ist vernünftig und alles muß überprüft werden.

Der Bugtracker von Debian ist überlastet, wenn Ihr da Heute am Tag des Postings draufklickt, nicht wundern wenn es lange dauert, oder gar nicht geht: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024

Debian und Redhat Buildinformationen triggern die Backdoor beim Bau

Im Makefile der Backdoor gibt es Hinweise darauf, daß die diese nur funktioniert, wenn glibc, der gcc und der Gnu Linker ld vorhanden ist. Für andere Plattformen wird die Backdoor nicht gebaut. Gleichzeitig gibt es Filter für X86_64 Architekturen, Debian und Redhatbasierte Distrokennungen.

OpenSUSE, Redhat,Fedora, Debian und Ubuntu haben reagiert

wobei hier anzumerken ist, daß der Versuch den Patch bei Ubuntu unterzubringen gefailed ist. Da war die Betafrist für die neue Version kurz vor dem Ablauf und den Ubuntu Leuten zu heikel. Gute Prinzipien helfen offenbar.

Fedora 38, 39 und alle Mobility Images sind bislang nicht betroffen

Fedora 38 und 39 basieren noch auf der 5.4.1 Version von XZ und sind daher bislang nicht betroffen. Fedora Mobility basiert auf Fedora 39.

Bitte daran denken, daß sich das ändern kann, wenn Schadcode in Form von Bufferoverflows im bisherigen Code auftauchen.

F40 soll vorsichtshalber reagieren, ist aber eh noch Beta, F41 ist abzuschalten.

Reguläre Benutzer werden noch nicht betroffen sein, daß Fedora 40 in der 5.6.0 erstmals auftaucht noch in der Betaphase ist und daher nicht produktiv ist Einsatz sein sollte. Für Fedora 40 wird auch ein Downgrade vorbereitet. Fedora 41 ist Bleeding Edge Software, das sollte niemand ernsthaft einsetzen.

Der Hack besteht am Ende aus einem unautorisierten Login via SSH

Die Kette von Ereignissen der Backdoor führt in letzter Konsequenz zu einem unautorisierten Login via SSH, zumindest war das die Absicht. Laut Analysen des getarnten Codes analysiert der Schadcode den Login kryptographisch. Da ein direkter Login mit einem beliebigen User nicht möglich ist, das würde schliesslich sofort auffallen, weil alle Botnetze direkt Zugriff bekommen würden, wird hier wohl zusätzlich ein Key ausgewertet.

Vermutung – Wer steckt hinter dem Angriff?

Hier müssen wir vorsichtig sein, weil einiges suspekt aussieht, es aber vielleicht nicht ist.

Vor einer Stunde ( 9:30 Ortszeit ) wurden Informationen gepostet, daß die Authorengruppe zu der auch der „Jin Tan“ Account zählt, an einer Unzahl von OSS-Projekten beteiligt war, die fast alle Kryptographischen Bezug haben z.B.:

That actor is involved in so many PR/commits/review in openssl and systemd, protobuf-c. llvms, util-linux. torvalds/linux, make-ca, cpython, curl, libxcrypt, dosbox-x, rust
16 repo contributed to this year, 47 repos in 2023, 38 in 2024.
Some of his PRs are reviewed in conjunction with xen0n or xry111 is reviewing PRs from him. xen0n has contributed 36 repos this year, 101 in 2023 and 136 in 2024.

Quelle: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

Die Gruppe versucht die LOONGSON Architektur in die Software einzupflegen, jetzt ratet mal, wessen CPUs das sind. Genau: Die neuen CPUs der Chinesen.  Da ist natürlich der erste Reflex ein Selbstläufer 😉

Die meisten Commits sind allerdings für den XZ Angriff irrelevante Anpassungen, da sie sich nur auf als LOONGSON gebaute Programme beziehen. Ein Generalverdacht existiert nicht.

Der Author des obigen Posts wurde dann von anderen korrekter weise darauf hingewiesen, daß er hier keine unbewiesenen Anschuldigungen machen soll, einige der LOONGSON Gruppen wären persönliche Bekannte. Fragt sich nur, von wem, denn auch über diese Leute wissen wir rein gar nichts 🙂

Ihr könnt erkennen, das driftet derart schnell in Verschwörungstheorien ab, da muß man richtig vorsichtig sein.

Fakt ist: die Backdoor ist da.

Alles andere muß sich finden, in dem die Repobesitzer die Commits der Verdächtigen überprüfen und zur Aufklärung beitragen.

Wer hier helfen will und abgedrehte C Erfahrungen hat , z.b. Fefe, die können ja mal die 700 Commits von „Jin Tan“ im XZ Repo unter die Lupe nehmen. Bei Exploitcode für C bin ich praktisch raus.

Quellen:

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

https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html

https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024

TheSameSam Gist zum XZ Vorfall

Fedora 38 / Firefox 124.0.1 : hier ist der Fix

Der Firefox 124.0.1 Build mit dem Patch gegen die Javascript Lücke für Fedora 38 ist leider für PPC64 schief gelaufen und daher als „failed“ markiert, was technisch stimmt, aber eben nur für PPC64 ( PowerPC Plattform ).

Fedora 38 / Firefox 124.0.1 : hier ist der Fix

„normale“ Fedora 38 User können also nicht auf eine neue Version hoffen? Doch Ihr könnt:

Klickt mal hierhin:

https://koji.fedoraproject.org/koji/taskinfo?taskID=115309290

Ihr seht dann diese Liste mit Links:

Eine Liste mit Links

Da schnappen wir uns die beiden benötigten Pakete und updaten das direkt mit dnf. Das dies auch funktioniert, beweißt dieser Post, ich habe nämlich schon 124.0.1 für Fedora 38 😉

$ sudo dnf update https://kojipkgs.fedoraproject.org//work/tasks/9290/115309290/firefox-124.0.1-1.fc38.x86_64.rpm https://kojipkgs.fedoraproject.org//work/tasks/9290/115309290/firefox-langpacks-124.0.1-1.fc38.x86_64.rpm

Und nun habt Ihr den Fix auch auf dem PC.

Warum ist das nötig?

Ihr dürft raten.. ein defekter Build kommt natürlich nicht ins Stable, auch wenn Teile kritisch sind und funktionieren. Außerdem hängt Martin zur Zeit nicht ganz so dahinter, wie das Firefox und Fedora derzeit bräuchten. Ich habe ihm direkt angeboten, bei FF zu helfen, damit in Situationen wie diesen, schneller reagiert werden kann. Ich brauche Firefox ja schliesslich selbst jeden Tag für meine Arbeit.