Warnung: Backdoor in Paket xz-utils 5.6.0 bis 5.6.1
Zitat von Alexs am 30. März 2024, 10:13 UhrMit der Version xz-utils 5.6.0 wurde in den Quellen ein Backdoor eingeführt, welches mit der Debian-Version 5.6.1+really5.4.5-1 wieder bereinigt wurde. [1][2][3][4]
Diese Warnung betrifft Debian-Anwender die unter testing bzw. unstable/sid xz-utils 5.6.0 bis 5.6.1-1 installiert haben. Die aktuelle Debian-Version 5.6.1+really5.4.5-1 wurde lediglich auf die nicht kompromittierte Version 5.4.5 zurückgesetzt.Aber auch andere Distribution verwenden xz 5.6.0 oder 5.6.1.[5] Welche Version installiert ist, ist unter xz --version ersichtlich.
Bekannt wurde der Backdoor, als Andres Freund langsame und unbekannte Login-Versuche mit SSH, bzw. merkwürdige liblzma-Nutzlast auf diversen Debian/unstable-Installationen bemerkte.[2]
Es ist noch nicht bekannt wie groß das Ausmaß der Kompromittierung ist, momentan suchen u.a. Mitglieder der CISA nach Ursachen und den möglichen Verursacher. Aktuell brodelt auch die Gerüchteküche.[6]
Betroffen sind auf jeden Fall Anwender, welche die oben genannten Versionen installiert haben, eine Aktualisierung auf die aktuelle – gefixte – Version sollte schnellstmöglich erfolgen. Da das Backdoor ein aktiviertes SSH benötigt, sollten diejenigen welche SSH bis jetzt benötigten, in Betracht ziehen aus Sicherheitsgründen ein sicheres Backup (welche die betroffenen Versionen nicht beinhalten) einzuspielen, oder im Fall von Siduction ein neues frisches ISO [7] mit gefixten xz-utils zu installieren.
Ich zitiere devil (Ferdinand Thommes) vom Siduction-Forum und Gründer von LinuxNews:
Als erste Maßnahme zur Überprüfung, ob ein System infiziert ist, kannst du das Skript detect.sh am Ende von https://www.openwall.com/lists/oss-security/2024/03/29/4 herunterladen, es ausführbar machen und mit sudo ./detect_sh.bin ausführen. Ich habe folgendes Ergebnis erhalten: probably not vulnerable. Es scheint in jedem Fall eine gute Idee zu sein, SSH auszuschalten wenn es nicht benötigt wird.
Weitere Informationen werden wahrscheinlich in den nächsten Tagen auftauchen. Wenn das Skript feststellt, dass dein System wahrscheinlich nicht angreifbar ist, würde ich persönlich bis morgen warten. Wenn das Skript feststellt, dass du (vermutlich) infiziert bist, würde ich eine Neuinstallation vom Backup in Betracht ziehen. Entscheiden müsst ihr, die verfügbaren Informationen sind zu dünn für eine klare Empfehlung.
[1] https://forum.siduction.org/index.php?topic=9320.0
[2] https://linuxnews.de/kompromittiertes-paket-in-arch-debian-fedora-und-opensuse/
[3] https://www.openwall.com/lists/oss-security/2024/03/29/4
[4] https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
[5] https://xeiaso.net/notes/2024/xz-vuln/
[6] https://boehs.org/node/everything-i-know-about-the-xz-backdoor
[7] https://testbuilds.siduction.org/ (Neue Testbuilds von Siduction; ob sich darinnen schon die t64er-Pakete befinden weiß ich nicht, nehme es aber an)Nachtrag 30.03.2024 – 16:50:
Unten ein Link zur vorläufigen Stellungnahme vom Betreuer des Projektes Lasse Collin (Larhzu):
[8] https://tukaani.org/xz-backdoor/Die Personen, hinter den Pseudonymen Jia Tan, Jigar Kumar, misoeater91, krygorin4545, Hans Jansen usw. scheinen nach langer Vorbereitungszeit (diverse Commits) und Druck auf den Betreuer die Chance genutzt zu haben einen Backdoor einzuschleusen.
[9] https://www.mail-archive.com/xz-devel@tukaani.org/msg00566.html
Mit der Version xz-utils 5.6.0 wurde in den Quellen ein Backdoor eingeführt, welches mit der Debian-Version 5.6.1+really5.4.5-1 wieder bereinigt wurde. [1][2][3][4]
Diese Warnung betrifft Debian-Anwender die unter testing bzw. unstable/sid xz-utils 5.6.0 bis 5.6.1-1 installiert haben. Die aktuelle Debian-Version 5.6.1+really5.4.5-1 wurde lediglich auf die nicht kompromittierte Version 5.4.5 zurückgesetzt.
Aber auch andere Distribution verwenden xz 5.6.0 oder 5.6.1.[5] Welche Version installiert ist, ist unter xz --version ersichtlich.
Bekannt wurde der Backdoor, als Andres Freund langsame und unbekannte Login-Versuche mit SSH, bzw. merkwürdige liblzma-Nutzlast auf diversen Debian/unstable-Installationen bemerkte.[2]
Es ist noch nicht bekannt wie groß das Ausmaß der Kompromittierung ist, momentan suchen u.a. Mitglieder der CISA nach Ursachen und den möglichen Verursacher. Aktuell brodelt auch die Gerüchteküche.[6]
Betroffen sind auf jeden Fall Anwender, welche die oben genannten Versionen installiert haben, eine Aktualisierung auf die aktuelle – gefixte – Version sollte schnellstmöglich erfolgen. Da das Backdoor ein aktiviertes SSH benötigt, sollten diejenigen welche SSH bis jetzt benötigten, in Betracht ziehen aus Sicherheitsgründen ein sicheres Backup (welche die betroffenen Versionen nicht beinhalten) einzuspielen, oder im Fall von Siduction ein neues frisches ISO [7] mit gefixten xz-utils zu installieren.
Ich zitiere devil (Ferdinand Thommes) vom Siduction-Forum und Gründer von LinuxNews:
Als erste Maßnahme zur Überprüfung, ob ein System infiziert ist, kannst du das Skript detect.sh am Ende von https://www.openwall.com/lists/oss-security/2024/03/29/4 herunterladen, es ausführbar machen und mit sudo ./detect_sh.bin ausführen. Ich habe folgendes Ergebnis erhalten: probably not vulnerable. Es scheint in jedem Fall eine gute Idee zu sein, SSH auszuschalten wenn es nicht benötigt wird.
Weitere Informationen werden wahrscheinlich in den nächsten Tagen auftauchen. Wenn das Skript feststellt, dass dein System wahrscheinlich nicht angreifbar ist, würde ich persönlich bis morgen warten. Wenn das Skript feststellt, dass du (vermutlich) infiziert bist, würde ich eine Neuinstallation vom Backup in Betracht ziehen. Entscheiden müsst ihr, die verfügbaren Informationen sind zu dünn für eine klare Empfehlung.
[1] https://forum.siduction.org/index.php?topic=9320.0
[2] https://linuxnews.de/kompromittiertes-paket-in-arch-debian-fedora-und-opensuse/
[3] https://www.openwall.com/lists/oss-security/2024/03/29/4
[4] https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
[5] https://xeiaso.net/notes/2024/xz-vuln/
[6] https://boehs.org/node/everything-i-know-about-the-xz-backdoor
[7] https://testbuilds.siduction.org/ (Neue Testbuilds von Siduction; ob sich darinnen schon die t64er-Pakete befinden weiß ich nicht, nehme es aber an)
Nachtrag 30.03.2024 – 16:50:
Unten ein Link zur vorläufigen Stellungnahme vom Betreuer des Projektes Lasse Collin (Larhzu):
[8] https://tukaani.org/xz-backdoor/
Die Personen, hinter den Pseudonymen Jia Tan, Jigar Kumar, misoeater91, krygorin4545, Hans Jansen usw. scheinen nach langer Vorbereitungszeit (diverse Commits) und Druck auf den Betreuer die Chance genutzt zu haben einen Backdoor einzuschleusen.
[9] https://www.mail-archive.com/xz-devel@tukaani.org/msg00566.html
Zitat von zebolon am 30. März 2024, 15:43 UhrHallo @alexs,
hatte meine Nachricht bzgl. Linux News wieder zurück gezogen. Gibt ja fast zeitgleich einen Link von @baumi05 dazu und es wurde zwischenzeitlich von Dir ergänzt...
Das erwähnte Skript hab ich unter Siduction schon durchlaufen lassen - mit gleichem Ergebnis...
Hallo @alexs,
hatte meine Nachricht bzgl. Linux News wieder zurück gezogen. Gibt ja fast zeitgleich einen Link von @baumi05 dazu und es wurde zwischenzeitlich von Dir ergänzt...
Das erwähnte Skript hab ich unter Siduction schon durchlaufen lassen - mit gleichem Ergebnis...
Zitat von Alexs am 30. März 2024, 15:50 UhrHallo @zebolon,
danke trotzdem für deine Erwähnung, mein Edit hat wohl etwas zu lange gedauert. Das Script zeigt bei mir die gleiche negative Meldung an, zudem verwende ich kein SSH.
Edit 1:
Hier ein Video auf Englisch, wo das Problem erklärt wird:https://www.youtube.com/watch?v=jqjtNDtbDNI
Edit 2:
Unten ein Link zur vorläufigen Stellungnahme vom Betreuer Lasse Collin (Larhzu) des Projektes:
https://tukaani.org/xz-backdoor/
Hallo @zebolon,
danke trotzdem für deine Erwähnung, mein Edit hat wohl etwas zu lange gedauert. Das Script zeigt bei mir die gleiche negative Meldung an, zudem verwende ich kein SSH.
Edit 1:
Hier ein Video auf Englisch, wo das Problem erklärt wird:
Edit 2:
Unten ein Link zur vorläufigen Stellungnahme vom Betreuer Lasse Collin (Larhzu) des Projektes:
https://tukaani.org/xz-backdoor/
Zitat von Alexs am 31. März 2024, 14:10 UhrNeues Lesematerial:
Wie die Computerwelt gerade haarscharf an einer Sicherheitskatastrophe vorbeigeschrammt ist (Der Standard)
xz-Attacke: Hintertür enträtselt, weitere Details zu betroffenen Distros (Heise)
Neues Lesematerial:
Wie die Computerwelt gerade haarscharf an einer Sicherheitskatastrophe vorbeigeschrammt ist (Der Standard)
xz-Attacke: Hintertür enträtselt, weitere Details zu betroffenen Distros (Heise)
Zitat von Alexs am 31. März 2024, 16:57 UhrCVE-2024-3094 concerning a backdoor exploit in XZ Utils 5.6.0 and 5.6.1 releases are currently being analyzed, for the moment we have paused Archive processing. We will advise as soon as possible. For more reading and information: https://tukaani.org/xz-backdoor/
Quelle https://micronews.debian.org/2024/1711830544.html Debian micronews (gibt es auch als Atom/RSS Feed)
CVE-2024-3094 concerning a backdoor exploit in XZ Utils 5.6.0 and 5.6.1 releases are currently being analyzed, for the moment we have paused Archive processing. We will advise as soon as possible. For more reading and information: https://tukaani.org/xz-backdoor/
Quelle https://micronews.debian.org/2024/1711830544.html Debian micronews (gibt es auch als Atom/RSS Feed)
Zitat von robertgoedl am 1. April 2024, 8:04 UhrDie größten Probleme damit, werden eher Distributionen haben, die diese Software-Version bereits im produktiven System haben - solche kenne ich aber nicht.
Die andere Geschichte - ohne SSH (zumindest private User) zu nutzen, funktioniert es so gesehen nicht.
Das Interessante daran - die lange Vorbereitungszeit, die Software zu implementieren. Derjenige - oder eher Diejenigen, die den kompromittierten Code implementiert haben, haben sich sehr viel Zeit gelassen. Ein normaler Entwickler solcher Software würde es einfach tun - man hat so gesehen sehr professionell gehandelt. Manche sprechen davon, es könnte im Auftrag eines Staates geschehen sein.
Das Schöne daran - es zeigt, wie und warum freie Software sicherer ist. Solche Dinge lassen sich im Gegensatz zu geschlossener Software recht einfach entdecken.
Zum Test-Script
Es ist recht einfach zu nutzen - Download von folgendem Link detect.sh. Ausführbar machen - per Rechtsklick auf die Datei "Eigenschaften → Berechtigungen", aktivieren der Checkbox "Ausführbar", oder eben am Terminal mit dem Befehl:
chmod +x detect.sh
su
./detect.shOder eben:
sudo ./detect.sh
Nächstes Wochenende werde ich hoffe ich auch wieder zu einem normalen Leben zurückkehren und mich wieder so wie ich will der Linux Bibel widmen können 😀
Die größten Probleme damit, werden eher Distributionen haben, die diese Software-Version bereits im produktiven System haben - solche kenne ich aber nicht.
Die andere Geschichte - ohne SSH (zumindest private User) zu nutzen, funktioniert es so gesehen nicht.
Das Interessante daran - die lange Vorbereitungszeit, die Software zu implementieren. Derjenige - oder eher Diejenigen, die den kompromittierten Code implementiert haben, haben sich sehr viel Zeit gelassen. Ein normaler Entwickler solcher Software würde es einfach tun - man hat so gesehen sehr professionell gehandelt. Manche sprechen davon, es könnte im Auftrag eines Staates geschehen sein.
Das Schöne daran - es zeigt, wie und warum freie Software sicherer ist. Solche Dinge lassen sich im Gegensatz zu geschlossener Software recht einfach entdecken.
Zum Test-Script
Es ist recht einfach zu nutzen - Download von folgendem Link detect.sh. Ausführbar machen - per Rechtsklick auf die Datei "Eigenschaften → Berechtigungen", aktivieren der Checkbox "Ausführbar", oder eben am Terminal mit dem Befehl:
chmod +x detect.sh
su
./detect.sh
Oder eben:
sudo ./detect.sh
Nächstes Wochenende werde ich hoffe ich auch wieder zu einem normalen Leben zurückkehren und mich wieder so wie ich will der Linux Bibel widmen können 😀
Zitat von zebolon am 1. April 2024, 10:03 UhrNun ja, der ganze Aufwand der hier geleistet wurde, legt zumindest die Vermutung nahe, dass hier staatlich gelenkt wurde/wird. Für die aggressiv böse Absicht dahinter kämen so einige Akteure der aktuellen welt-politischen Lage in Frage...
Nun ja, der ganze Aufwand der hier geleistet wurde, legt zumindest die Vermutung nahe, dass hier staatlich gelenkt wurde/wird. Für die aggressiv böse Absicht dahinter kämen so einige Akteure der aktuellen welt-politischen Lage in Frage...