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

[Dalek]

In der CVE Beschreibung steht das es mit allem funktioniert welches gegen die manipulierte Lib Version gelinked wurde, also prinzipiell sollte es nicht nur mit openssh funktionieren.

Es ist grundsätzlich möglich das andere Sachen auch angegriffen wurden, der SSH Teil ist das was bisher bekannt ist. Kann also sein das da mehr als ein Exploit drin ist, aber da müssen wir noch etwas warten bis das weiter analysiert wurde.

 

[flaphoschi]

Eine Anmerkung. Das ist keine Sicherheitslücke, sondern ein Backdoor.

Die Manipulation zielte auf Debian/Ubuntu und Red Hat/Suse ab. Die Patchen wohl alle an OpenSSH herum, verbinden es so mit Systemd (welches wie fast alles eine Abhängigkeit auf xz hat). Also kein Vorwurf an Systemd oder OpenSSH! Ich persönlich mag ungefragte Patcherei nicht, das soll nur bei Notwendigkeit oder Anwenderwunsch passieren. Das Arch Rolling ist, hat innen die manipulierte Version reingezogen, das Arch nur Vanilla-Upstream verwendet hat sie wohl gerettet.

Bei OpenSuse Tumbleweed hat das wohl leider die Konsequenz, dass man die Installation als kompromittiert betrachten muss. Vermutlich auch diverse Testzweige von Debian (Unstable), Ubuntu und Fedora (Rawhide).

Das große Problem ist. Der Angreifer hat seit Jahren die Permission zum Committen (ich konnte gestern Nacht noch Commits in 2022 sehen). Das Microsoft das Repo abgeschaltet hat, erschwert die Aufklärung. Das ist wiederholt ein schlechte Aktion von Microsoft (GitHub). Ein zusätzlicher Sicherheitslock wäre besser oder eine geänderte URL mit sprechenendem Nahmen “https://dangerous.github.com…”.

Was ist da sonst noch? Welche Software verwendet noch xz - unter allen Betriebssystem? Das bedeutet auch:
Wer eine alte Version hat, sollte sich nicht zurücklehnen. Da kann noch etwas kommen

Die Problematik von wenigen Entwicklern bei wichtiger Software ist bekannt. Und dass Bibliotheken besonder kritisch sind, ebenso. Und hier hat es nur ein zweites paar Augen gegeben. Prüfen kann man das bei offenem Quellcode wenigstens, aber kaum jemand hat die Ressourcen.

Meine Lehren bisher:
Der Angreifer hat nicht den Quellcode manipuliert, neben Buildscripts sind jegliche Ressourcen (Testdaten) eine Gefahr. Was schlecht lesbar und kompliziert ist, ist und bleibt schlechter Code. Vertrauen ist gut, Kontrolle und Kontrolle und Kontrolle sind besser.


Exkurs:
Bei JavaScript (NPM) sind Leute die Pakete manipulieren ja schon länger ein Problem. Und woher das JavaScript kommt scheint Websitenbetreibern egal, die ziehen das von fremden Servern. Dann muss halt der Besucher Bitcoin mit seinem Browser berechnen - ob der das will oder nicht.

// edit 2024-04-01
// Das Repository auf deren eigenen Server soll weiterhin lesbar zu sein.

 

[Tornhoof]

Ah okay, komisch das dass nicht in der CVE Beschreibung mit drinsteht.

Zu neu, unabhängig davon sind CVE Beschreibungen nicht als Analyse gedacht, sondern rein als formalisierter Mechanismus um Schwachstellen zu bewerten. (Mit allen zugehörigen Kritikpunkten)
In dem Fall beschreibt die CVE die Schwachstelle in der Bibliothek und nicht den interessanten Teil, nämlich die eigentliche Zielplattform, in dem Fall openssh.

 

[orodigistan]

"Durch jahrelange Vorarbeit ist es Angreifern gelungen, den Quellcode der Kompressionssoftware xz zu kompromittieren. Gezielt eingereichte Patches schufen Sicherheitslücken und diese wurden proaktiv in aktuelle Linux-Distributionen eingepflegt."

aha? liest sich heftig! jetzt sieht man, wie sehr Unternehmen oder sogar Regierungen gehen würden.

 

[JustAnotherTux]

Zu neu, unabhängig davon sind CVE Beschreibungen nicht als Analyse gedacht, sondern rein als formalisierter Mechanismus um Schwachstellen zu bewerten. (Mit allen zugehörigen Kritikpunkten)
In dem Fall beschreibt die CVE die Schwachstelle in der Bibliothek und nicht den interessanten Teil, nämlich die eigentliche Zielplattform, in dem Fall openssh.

Aber die CVE Beschreibung ließt sich so als wäre es nur Logik um mitlesen zu können über unabhänig davon installierte Malware bzw. Software.

Aber scheinbar enthält der Schadcode ja noch diese extra Logik für SSH bzw. die Installation von weiterer Malware welche von der manipulierten Lib gebrauch macht ist ja scheinbar garnicht notwendig, IMO sollte das schon auch in der CVE Beschreibung stehen.

 

[kim88]

eben, nicht die kompromiterten library ist ja in den distubutionen gelandet.

Nur in ein paar weniger. Eigentlich nur in Rolling Release Distirbutionen wie Arch Linux und in "Beta, Testing, Unstable" Zweige von Point Release Distros.

Und der Grossteil von Linux läuft auf Server, und dort läuft keine Fedora 40 Beta sondern hauptsächlich: Ubuntu, Debian, Red Hat und SLES

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 gibt hier: https://git.tukaani.org/?p=xz.git;a=summary ein Mirror vom Repository daher alle Anpassungen und Änderungen von Jia Tan kann man weiterhin nachverfolgen.

 

[Grimba]

Tja, jemand wird sich schon die Commits angucken, und Open Source ist sicher, ist damit wohl widerlegt

Naja, es hat sich ja schlussendlich jemand angeguckt. Und das konnte der auch nur, weil es eben offen war. Niemand hat gesagt, Open Source wäre per se sicher. Allerdings macht man seine Schandtaten dort nunmal offen. Das hat im Nachhinein, wenn sowas passiert, den Vorteil, dass die Situation viel besser nachvollzogen werden kann. Man muss ja nicht erst warten, bis eine Firma konkrete Angaben macht, den Fehler patcht, und ist auch nicht auf puren Glauben angewiesen, ob das auch stimmt. Jeder kann ja den Code patchen. Also ich sehe da ehrlich gesagt keine Widerlegung von irgendwas.

Aber es zeigt selsbtverständlich ein Problem auf. Da wurde auch perfide vorgegangen. Da wird sicher noch an vielen Stellen umgedacht werden müssen.

 

[Tornhoof]

IMO sollte das schon auch in der CVE Beschreibung stehen.

Ich empfehle einfach, CVE abseits von einer groben Liste von Nummern für Schwachstellen komplett zu ignorieren, das Konzept ist mittlerweile nur noch eine Karikatur der originalen Idee. Das einzig relevante mittlerweile ist, gleiche Nummer bedeutet wir reden über das gleiche Problem

 

[greatdisaster]

Finde ich jetzt nicht unbedingt dämlich, ein bekanntermaßen kompromittiertes Repository temporär offline zu nehmen, um seine weitere Verbreitung vorerst zu verhindern, bis es anständig auditiert wurde.

Dann sollten die ein komplett mirror Repository Online stellen unter einem eindeutigen Namen.

 

[mibbio]

Oder zumindest das Repo in einen speziellen Read-Only Modus schalten, bei dem dann sämtliche git Commands zum Runterladen des Quellcodes (git clone, git pull, ...) und sonstige Downloads (automatisch erstelltes Archiv des Quellcodes) gesperrt sind. Eine Kopie des Quellcode zwecks Analyse kann dann nur der Repo-Inhaber oder der Github-Support rausgeben, aber prinziepiell einsehen kann den auf der Webseite Jeder.

Das würde auch schon verhindern, dass sich jemand versehentlich den kompromittierten Code runterlädt oder der sich sonstwie einfach so verbreitet.

 

[Calzifer]

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

Das ist so simples C. Du stehst einfach nur auf dem Schlauch.

Das Buildscript soll das kurze Stück C Code kompilieren und wenn es erfolgreich kompiliert wird das Feature aktiviert.
Der Punkt sorgt einfach dafür, dass der Code fehlerhaft ist und damit niemals erfolgreich kompiliert und damit dieses (Sicherheits)feature immer deaktiviert ist. Ein Punkt einfach weil er wenig auffällt. Noch besser wäre vermutlich irgendein nicht sichtbares Unicode Zeichen.

Also hast du im Endeffekt Recht, der Punkt macht den Check effektiv nutzlos.


Überhaupt ist es erstaunlich, dass der Angriff im Großen und Ganzen gut gemacht ist sich dann aber doch ein paar Nachlässigkeiten leistet. Der Schadcode wurde ja in Testdaten versteckt. Diese ohne einen dazugehörigen Test hinzuzufügen ist schon gewagt. Mag jetzt im Nachhinein mehr auffallen, aber auch die Begründung warum man die nicht genutzten Testdateien (den Schadcode) später geändert hat war schon seltsam.

 

[UrlaubMitStalin]

Tja, jemand wird sich schon die Commits angucken, und Open Source ist sicher, ist damit wohl widerlegt. Frage mich nur, wie viele Schläfer in Closed-Source-Produkten Backdoors platzieren.

Jonathan Blow on backdoors and cybersecurity

Anders herum wird ein Schuh draus.
In Open Source hat man es gefunden... in closed source nicht.
In Closed Source können Backdoors Jahrzehnte lang überleben.

 

[Randnotiz]

Ich als normaler Benutzer habe davon bis zu den Meldungen in Linux-Discords und hier auf der Seite, herzlich wenig mitbekommen.

Fürs schnelle beheben der Sicherheitslücke kann ich mich daher nur bedanken und freuen.

Natürlich wirft das ganze jetzt auch Fragen auf, wieso es überhaupt soweit kommen konnte.
Allerdings denke ich mir, kann man das auch als Denkanstoß nutzen, um den Prozess für Vertrauen und Commits nochmal zu überarbeiten.

Passt also alles, bei Windows und macOS hätte man auch nur von großen Problematiken berichtet, die Anwender hätten selbst aber recht wenig gemerkt und am nächsten Tag hätte sich die Welt um den PC normal weitergedreht.

 

[SSD960]

Überrascht mich nicht. Man sollte davon ausgehen das jedes OS Komprometiert ist. Nichts ist sicher.

 

[Mordi]

Man sollte davon ausgehen das jedes OS Komprometiert ist.

Von was? Der hier beschriebenen Backdoor nur wenn du Fedora 40 Pretelease/Rawhide, Debian Sid oder ähnliches nutzt.

 

[Savage_Sinusoid]

Aber die CVE Beschreibung ließt sich so als wäre es nur Logik um mitlesen zu können über unabhänig davon installierte Malware bzw. Software.

Aber scheinbar enthält der Schadcode ja noch diese extra Logik für SSH bzw. die Installation von weiterer Malware welche von der manipulierten Lib gebrauch macht ist ja scheinbar garnicht notwendig, IMO sollte das schon auch in der CVE Beschreibung stehen.

Ja, die CVE-Beschreibung ist ziemlich irreführend beziehungsweise unvollständig.

Laut dieser vorläufigen Analyse handelt es sich bei der Hintertür um einen ziemlich schicken Mechanismus, mit dem man über eine SSH-Verbindungsanfrage ein beliebiges Shell-Kommando absetzen kann. Soweit ich das überblicke, kommt dabei bewusst keine echte SSH-Sitzung zustande (da sie im Syslog auftauchen würde). Das Ganze ist abgesichert per asymmetrischer Kryptografie: Der Sesam öffnet sich nur, wenn man im Besitz des richtigen privaten Schlüssels ist. Das heißt, in ein verwundbares System kommt nicht einfach jedes beliebige Skript-Kiddie rein, sondern vermutlich nur ein ganz, ganz enger Kreis von Personen. Davon kann Cisco noch was lernen! 😆

Auch sehr spannend zu lesen: Die Analyse, wie der (für x86_64 vorkompilierte) Schadcode in einem mehrstufigen Vorgang zuerst entschleiert und letztendlich in die Bibliothek eingeschleust wird.

 

[nöörd]

Die großen Linux-Distributionen Debian, Ubuntu und Fedora haben den schadhaften Code lediglich in ihren Test-Versionen wie etwa Debian Sid ausgeliefert und sich wieder auf sichere Versionen zurückgezogen.

 

[Multivac]

Naja, es hat sich ja schlussendlich jemand angeguckt.

Nein die commits die die backdoor beinhalten hat sich sich keiner rechtzeitig angeguckt! Das Problem liegt hier klar bei der art und weise wie opensource projekte funktionieren das vertrauen in eine person kommt durch die invesierte zeit der Person zustande. xìngshì kann ein russischer Agent sein der aus einen buero aus sanktpetersburg agiert. Wenn jemand bei microsoft arbeitet kann er auch ein agent sein aber der aufwand ist groesser.

 

[Snowi]

Stellt euch nur mal vor, wenn das noch mindestens 1 Jahr nicht aufgefallen wäre.

Wären nicht alle so ignorant, wäre das ein Weckruf, die ganzen IoT Sachen mal vernünftig patchbar zu machen, und das auch regelmäßig zu tun.
Aber wie wir alle wissen, wird dieser Vorfall bei den ganzen Herstellern exakt 0 ändern :')

 

[konkretor]

@Kaito Kariheddo der maintainer der schon immer am Projekt gearbeitet hat.
Hat ne Webseite erstellt, leider sehr ungenau

https://tukaani.org/xz-backdoor/

Ergänzung (31. März 2024)

Es könnte auch Windows 11 betroffen sein

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

Dort in den Kommentaren wurde folgendes gepostet