[English]Zum Freitag den 29. März 2024 hat Red Hat eine Warnung veröffentlicht. Die neuesten Versionen der „xz“-Tools und -Bibliotheken enthalten bösartigen Code, eine Backdoor, die offenbar dazu gedacht ist, unbefugten Zugriff zu ermöglichen. Betroffen von der Backdoor (Sicherheitslücke CVE-2024-3094) sind die Versionen 5.6.0 und 5.6.1 der Bibliotheken. Trifft verschiedene Nutzer von Linux und tangiert auch Open SSH.
Zufällige Entdeckung
Ein Blog-Leser hat im Diskussionsbereich auf den OpenWall-Post backdoor in upstream xz/liblzma leading to ssh server compromise hingewiesen (danke dafür). Microsoft Entwickler Andres Freund sind in den letzten Wochen einige merkwürdige Symptome rund um liblzma (ein Teil des xz-Pakets) unter Debian-Sid-Installationen aufgefallen. Seine Logins mit ssh benötigten eine Menge CPU-Leistung, es gab valgrind-Fehler etc.).
Er ist dann der Sache nachgegangen und hat einen Grund dafür herausgefunden: Das (auch von sssh benutzte) Upstream-xz-Repository und die xz-Tarballs wurden mit einem Backdoor versehen. Erst vermutete er, dass das Debian-Paket kompromittiert worden sei, stellte aber fest, dass die Backdoor im Upstream-Paket enthalten ist. Der Entdecker beschreibt einige Details in seinem Post.
Seit dieser Zeit ist die Linux-Welt in Aufruhr, da es verschiedene Produkte (Tarballs, ssh) in diversen Linux-Distributionen betrifft. Auf X hat mir schon jemand die Information zukommen lassen, dass GitHub die XZ Repository nach der Offenlegung der Backdoor suspendierte habe – merkt dazu aber an, dass die Plattform GitHub seit der Übernahme durch Microsoft “nur noch Müll sei”.
Norddeutsch hat es im Diskussionsbereich des Blogs zusammen gefasst. “XZ-Backdoor schlägt weitere Wellen. Für Backdoor wurde Manipulation v. Googles oss-fuzzing per Fake-Request versucht, um Entdeckung zu verhindern. HackerNews diskutiert, weitere Reviews existieren. Eine gute Analyse des Sachverhalts findet sich auf GitHub, die Manipulation per oss-fuzz ist hier bei Github/Google zu finden. Auf HackerNews gibt es einen Sammelthread dazu.
Warnung von Red Hat
Freitag, den 29. März 2024, hat Red Hat eine Warnung veröffentlicht, dass die neuesten Versionen der „xz“-Tools und -Bibliotheken bösartigen Code enthalten, eine Backdoor, die offenbar dazu gedacht ist, unbefugten Zugriff zu ermöglichen. Dazu heißt es:
Bösartiger Code wurde in den Upstream-Tarballs von xz, beginnend mit Version 5.6.0, entdeckt. Durch eine Reihe komplexer Verschleierungen extrahiert der liblzma-Erstellungsprozess eine vorgefertigte Objektdatei aus einer getarnten Testdatei im Quellcode, die dann verwendet wird, um bestimmte Funktionen im liblzma-Code zu verändern. Das Ergebnis ist eine modifizierte liblzma-Bibliothek, die von jeder Software verwendet werden kann, die gegen diese Bibliothek gelinkt ist, und die die Dateninteraktion mit dieser Bibliothek abfängt und modifiziert.
Betroffen von der Backdoor (CVE-2024-3094, CVSS Score 10.0) sind die Versionen 5.6.0 und 5.6.1 der Bibliotheken. Bei Red Hat heißt es, dass aktuelle Untersuchungen zeigen, dass die Pakete nur in Fedora 41 und Fedora Rawhide innerhalb des Red Hat Community Ökosystems vorhanden sind. Es sind keine Versionen von Red Hat Enterprise Linux (RHEL) betroffen, gibt Redhad an. The Register schreibt hier, dass auch bestimmte Fedora 40-Systeme das Update bekommen haben könnten.
Auf jeden Fall sollte die Verwendung der Fedora Rawhide-Instanzen sofort eingestellt werden. Auch andere Linux-Distributionen dürften durch diese xz-Tools und Bibliotheken betroffen sein.
Es scheint aber, ob es in vielen Fällen nochmals gut gegangen ist – mutmaßlich waren nur „unstable“ Distributionen betroffen. Das Internet Storm Center schreibt in diesem Tweet:
A quick note about xz-utils backdoor:
1 – luckily, this was caught early.
2 – most run xz-utils 5.2/5.4. 5.6 is bad.
3 – quick check: `xz -V`
4 – Thanks to people who paid attention
Man hat das Ganze also rechtzeitig aufgedeckt, bevor es breiter im Einsatz war. Fedora Rawhide / Fedora Linux 40 / openSUSE Tumbleweed können betroffen sein. Testen kann man es mit dem oben unter 3 genannten Befehl, der die Version anzeigt.
Die Diskussionen in diesem Sammelthread bringen noch einiges Licht in die Angelegenheit, wie die Backdoor in den Code gelangen konnte. Die Kollegen von Bleeping Computer haben hier auch noch einige Informationen dazu zusammen getragen.
https://news.opensuse.org/2024/03/29/xz-backdoor/
Suse Tumbleweed hat es definitiv erwischt
Ich glaube das nicht, das ist doch nur Lüge! ssh, xz und das ganze Linux ist doch Open-Source und der Quellcode wird täglich von Hunderten wenn nicht gar Quatrilliarden Leuten quergelesen, insbesonders solch sicherheitsrelevanten Sachen, da kann sich doch keine Backdoor einschleichen! Und sich unbemerkt bis in die Installations/Update-Repos der großen Distributionen durchschleichen. Jemand muss das doch schon beim Commit bemerkt haben! Das ist niemals und nie passiert, wer was anderes behauptet muss ein Verschwörungstroll sein!
Jedenfalls ist das doch das, was die üblichen Kommentatoren hier, bei Heise und sonstwo jedes Mal einem gebetsmühlenartig eintrichtern, wenn es mal wieder ein peinliches Sicherheitsleck in Microsoft-Software gibt. Im Linux und generell Open-Source kann das prinzipbedingt nicht passieren, das ist jedenfalls bei mir so angekommen.
Du bist ein richtiger Honk.
„im Linux und generell Open-Source kann das prinzipbedingt nicht passieren“… das ist Quatsch. Bei Open Source muss erstmal jemand aktiv jeden Commit anschauen und dann mit sehr viel Wissen und Können in der Software-Entwicklung die Änderung beurteilen.
Wenn jemand den Zugriff zu einem Repository und die dazu passenden Signaturschlüssel hat, dann „verteilen“ sich solche Commit meist automatisch in den aktiven Entwicklungszweig der großen Distributionen, wo sie getestet werden.
Die Maintainer der großen Distributoren müssen also Vertrauen haben, da die „Software-Lieferketten“ so komplex sind, dass NIEMAND alle Abhängigkeiten und Änderungen mehr als einzelne Person überblickt.
Dank an den Security Researcher „Andres Freund“ für die Entdeckung.
manchmal reicht ein falsches Komma damit eine Lücke entsteht.
erinnert sei an die Cryptolücke in den ein Feld genullt wurde obwohl es erhalten bleiben sollte.
So waren dann Zufallszahlen immer konstant.
Wer das Komma gelöscht haben muss war klar, nur wer das wirklich war, wo er her kam wurde nie geklärt. Aufgefallen war diese Änderung niemandem.
– dieses krampfhafte Verweisen auf Fehler Anderer ist bestenfalls Fanboyniveau, schlimmstenfalls Agenturniveau
– während „a malicious person“ es vermochte, *nix ein bösartiges Paket unterzuschieben (sie also Opfer eines Angriffs wurden) ist Microsoft selbst diese „malicious person“ (also der Angreifer), entwickelt den fehlerhaften oder gar bösartigen Code jeweils selbst. Das ist ein himmelweiter Unterschied bzgl. der Seriosität des Ladens.
„Der kleine Chelm ist ein Widerporst“
Werft den pösen Purschen zu Poden!
Troll, confirmed.
Tja bei Linux wird es aber zeitnah bemerkt und auch behoben. Bei deinem heißgeliebten Raffelkram aus Redmond wird es meist erst bemerkt wenn es längst zu spät ist und großflächig ausgenutzt wird. Und die Behebung dauert da gern auch mal Jahre wenn es blöd kommt.
Aber man merkt halt dass du ein MS-Fanboy bist das wird bei fast jedem deiner Kommentare deutlich.
Hat die Geschlossene mal wieder Ausgang oder was willst du uns mit diesem Kommentar beweisen?
@Günther Born: kann man diesen absoluten Nichtsnutztroll bitte irgendwie entfernen? Danke…
Wenn ich das richtig sehe, sind die großen Enterprise Distris und alles, was auf Debian Stable beruht, gar nicht betroffen. Alle anderen haben bereits einen Fix geliefert. Da läuft die Häme doch sehr ins Leere bzw kommt wie ein Bumerang zurück und macht ein großes blaues Auge.
Soweit ich das gesehen habe sind nur die rolling releases, testing und unstables bei suse, debian und fedora betroffen.
Suse empfiehlt bei thumbleweed wenn es über internet erreichbar und ssh server installiert ist, diese system platt zu machen und neu aufzusetzen.
Das heißt, wenn es nicht öffentlich vom Internet zugänglich war (z.B. hinter einer Fritzbox, also nur lokales Netz) und in der Zeit auch kein SSH benutzt wurde, sollte es nach dem „Update“ auf die alten xz/liblzma Versionen ohne Backdoor relativ sicher weiter benutzt werden können oder?
Habe 2 Debain sid im Einsatz, aber nur als Desktop Maschinen in Lokalnetzen und will die jetzt nicht zwingend platt machen. Die Lokalnetze haben allerdings Zugang zum Internet. Ich denke, ich war aber betroffen.
Die haben über Ostern leider Freigang. So etwas gehört dauerhaft weggesperrt wegen Gefährdung der Bevölkerung!
Ach, herrlich, wie ihr auf euer eigenes Argumentationsniveau reagiert!
Ob ich den Tag noch erlebe, bevor der Blog schließt, dass der Kindergarten weg bleibt? Die Hoffnung stirbt zuletzt.
Mit Windows wäre das nicht passiert. :)
da wäre ich mit nicht so sicher:
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5006600#gistcomment-5006600
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5006612#gistcomment-5006612
;-)
Dieses Problem hat mit Open-Source nichts zu tun. Das ist ein Versagen des Projekt Teams. Open-Source bedeutet nur das jeder den Code lesen darf, nicht das ihn jeder ändern darf. Ob Community Contributions angenommen werden und welche Sicherheitsmaßnahmen gelten, liegt allein in den Händen der Projektverantwortlichen. Aus eigener Erfahrung weiß ich das Closed-Source ebenso für Schadcode anfällig ist. Ich habe schon zu oft gesehen wie fragwürdiger Code von externen Mitarbeitern einfach ungesehen durchgewunken wurde, obwohl strikte Code Review Prozesse bestehen.
TL;DR: We think the following things need to be true for your system to be vulnerable:
You need to be running a rolling-release distro and updating religiously
You need to be running a distro that uses glibc and systemd
You need to have versions 5.6.0 or 5.6.1 of xz or liblzma installed (xz-utils provides the library liblzma)
You need to have your SSH port exposed to the public internet
-> blog.holz.nu
„…updating religiously…“ Bravo! ;-)
Der „quick check: `xz -V`“ wird jetzt nicht mehr so einfach für die Beurteilung sein. Z. B. Arch Linux zeigt für „xz“ weiter die Version 5.6.1 an, hat aber das Paket aktualisiert, um die Backdoor zu entfernen:
https://archlinux.org/packages/core/x86_64/xz/
(Mehr auf der Seite unter „Package Actions: View Changes“.)
Betroffen sind auch Windows-Systeme, die z. B. MSYS2 installiert haben. Auch dort wurden die XZ-Pakete aktualisiert und sind als Update verfügbar. (Allerdings läuft da wohl standardmäßig „/usr/sbin/sshd“ nicht bzw. ist gar nicht installiert.)
Sehen Sie es als Ausschlusskriterium an. Zeigt die Ausgabe 5.6.0/5.6.1?
Nein -> man ist bezüglich dieses Angriffes sicher
Ja -> man muss genauer hinsehen, weiter analysieren
„Ja -> man muss genauer hinsehen, weiter analysieren“
Was will man da genauer analysieren? Solche Systeme könnten kompromittiert sein. Sicher kann man sich da nie sein.
wenn ein System o.g. Kriterien erfüllte, „gewisse“ Zeit am Netz war oder ggf kompromittiert wurde gehört es analysiert und vom Netz bis Klärung erfolgt.
Ähnliche Worte finden auch Andere ( Opensuse, Debian sec-announce, Heise, Fedora oben ):
Ergo ist Weiteres nicht nur abhängig von der Versions-Bennenung, „xz -V“ ist nur ein Ansatz. Debian benennt hier den fix bspw in Version „xz-utils (5.6.1+really5.4.5-1)“ um. Noch einmal deutlich: Nur patchen reicht hier nicht! Schaut je nach Fall, ob wer drauf war, prüft die Syslogs, analysiert auf suspicious traffic, nutzt Tools wie „thor“, klemmt im Development erst mal die NIC ab…
Zum Glück sind Neuinstallationen unter GNU/Linux deutlich zeitsparender als unter Windows. Selbst wenn man am Desktop alles neu einrichtet ist das in der Regel in 1h erledigt.
Die Frage ist eher, wie man sowas in Zukunft vermeiden will.
Ein einfaches „pacman -Q“ zeigt ganz klar „xz 5.6.1-2“ an, also die gecleante Version. Zumindest, wenn man geupdated hat.
Es sieht aktuell so aus als ob es über Jahre geplant war
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
Danke für den Link. Liest sich wie ein Krimi.
Über Links von dort, eine Zusammenfassung:
https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/
und zur Info über Debian unstable:
https://security-tracker.debian.org/tracker/CVE-2024-3094
Sehr guter Link, Danke dafür!
Bei Heise steht auch schon was.
Das riecht nach einer staatlichen Aktion die von langer Hand vorbereitet wurde.
Gruß
Eine gute Hardware-Firewall mit intelligenter Artificial Intelligence erkennt das in 5-10 Sekunden und macht zu, wo ist das Problem? Das ist immer in jedem OS möglich!
Wir sind in diesem Fall auch nicht betroffen da wir eigene Kompressionsalgorithmen und eine eigene Linux-Distribution nutzen.
Ausser dieser Backdoor gibt es keine weiteren, ihr seid sicher.
Nein, wirklich sicher kann man nie sein. Das Ziel der empirischen Backdoor Forschung ist es, Erfahrungen über die Realität zu sammeln und/oder Erfahrungen über die Realität zu prüfen.
In der Realität gibt es zig Backdoors in allen Layern, in Softwareprodukten, Benutzeroberflächen, Betriebssystemen, Treibern, Firmware, inner halb CPU & GPU, in Mainboard Chipsätzen, in Netzwerkkomponenten Baseband, usw.
Dafür braucht man weniger empirischen Backdoor Forschung, es reicht auch ein gesunder Menschenverstand.
Frohe Ostern!
https://cdn.dnaindia.com/sites/default/files/2023/07/24/2600612-untitled-design-13.png
Eines Tages wirst auch Du den vorherigen Absatz verstehen, bis dahin weiterhin erfolgreiches Lernen der technischen Grundlagen in der IT-Welt.
Möge Deine „intelligente Artificial Intelligence Hardware-Firewall“ mit ihrer Software, Benutzeroberfläche, Betriebssystem, ihren Treibern und Firmwares, ihren spannenden Dingen innerhalb der CPU und in Mainboard Chipsätzen und in den Netzwerkkomponenten Basebands usw. Dich gut schützen.
Das hast du falsch verstanden, ich stimme dir völlig zu und ja die AI ist nur so gut wie „der Typ“ der die erstellt hat und der es kontrolliert.
https://ibb.co/phLp0m9
@Bernd B.
Auch dir und allen hier wünschen wir Frohe Ostern!
„Die Wirklichkeit sieht anders aus wie die Realität…“
Sie sollten unbedingt bei Fefes Umfrage mitmachen, KI-Gläubige werden eher nicht so häufig unter seinen Lesern sein.
blog. fefe. de/?ts=98f66681
HomeBrew unter MacOS ist auch betroffen, und sollte aktualisiert werden:
brew update && brew upgrade
8min Youtube zu den Details: https://www.youtube.com/watch?v=jqjtNDtbDNI
Es kommen erste Infos zur Funktion der Backdoor. Es soll sich um eine RCE (Remote Code Execution) handeln (https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b).
Wie hier schon erwähnt wurde, zeigt dieser Backdoor, dass Linux doch nicht so sicher ist, wie gerne behauptet wird.
Auch die Updateorgien sind nicht besser als bei Windows.
Ich muss mein Mint Server mindestens 1x die Woche neu starten, damit Updates übernommen werden.
Das Betriebssysteme angreifbar sind, ist doch klar.
Der Unterschied ist das unter GNU/Linux aufgrund der Repository-Struktur, aufgrund der Quelloffenheit und Transparenz solche Probleme schnell, grobflächig gefixt werden sobald das Problem bekannt ist.
Na na na,
jetzt komm mal nicht mit Argumenten:-)
Die Leute begreifen nicht das viele Updates ungleich weniger sicher ist.
Gruß
Na na na,
nun komm mal nicht mit Updates, denn die Updates werden bei Windows immer als „Nervig“ angeprangert.
Und das man nach Updates neu Starten muss ist ja unter Windows noch viel schlimmer.
Und seitens der Linux Trolle wird oft und gerne behauptet, dass Linux so sicher ist, dass man keine Angst haben braucht und Updates ja so selten kommen, weil es einfach super sicher ist.
Aber jetzt ist es ja ganz toll, dass man Updates machen muss und auch die Neustarts sind nicht so schlimm….solange es kein Windows ist.
Immer diese peinliche Doppelmoral!
Windows-Updates nerven:
Weil ich Windows für jedes kummulative Update 20min+ auf i5-CPUs warten darf.
Weil immer wieder nach dem Reboot entweder weitere Nachbearbeitungs-Zeiten und/oder weitere Updates mit weiterem Reboot anstehen.
Weil unter Windows 2-3x im Jahr irgendwas kaputt gepatcht wird.
Weil Windows Updates automatisch installiert, und den Rechner automatisch restartet – auch wenn kritische Prozesse laufen.
Weil Windows mit Updates die getroffenen System-Einstellungen ändert, oder neue zu Anwenders Ungunsten hinzufügt.
Trollbot von 1st1 oder was ist bei dir schief gelaufen?
der nächste Kernschwachsinn. Schön spannend, wie sich die Windows-Jünger hier als absolute IT Nullchecker outen…
Nullchecker sind eigentlich nur diejenigen, die immer wieder behaupten, dass Linux super sicher ist.
Man nie Updates braucht, denn es ist super sicher.
Neustarten braucht man nach Updates ja auch nicht, weil das alles unter Linux nicht notwendig ist.
Updates gehören dazu, und auch die Neustarts sind notwendig, unter Linux auch gerechtfertigt.
So zumindest die Aussagen der ganzen Nullchecker!
Hört bitte auf zu baten und zu polarisieren. Findet besser Analysen und Lösungen für uns alle.
Oder fangt endlich an, die derzeitige Situation Faktenbasiert zusammen und zielorientiert zu analysieren…
Kannst du eigentlich irgendwas außer dümmlich herumzutrollen, Stephan?
Windows 11 ist eventuell auch betroffen.
Der selbe bösartige Entwickler „Jia Tan“ hat nämlich auch Code zu libarchive beigetragen und der steckt auch in Windows 11.
Mit libarchive kann man (zum Beispiel auch der Windows-Defender) tar.xz öffnen.
gist[.]github[.]com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5006600#gistcomment-5006600
gist[.]github[.]com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5006612#gistcomment-5006612
Super Recherche, @Bolko. Dein 2. Link zu Github | thesamesam hat es in sich.
Gesichert scheint bis dato jedoch „nur“ die Teilnahme vom fraglichen Nutzer an entsprechender Entwicklung durch Commits:
Wann W11 zB durch Windows-Explorer bei „xz-Archiven“ entsprechende DLLs nutz{t|en könnte} findet Ihr dort mit Screenshots in der Diskussion.
Hat schon jemand Analyse oder Disassembly des entsprechenden Codes für Win11 22h2 und 23h2 gesehen?
Hat jemand Lust? Ist ja Ostern: EasterEggs in Windows-Code suchen? Die sind heute nicht mehr spassig, farbig oder gestreift, Easter Eggs haben heute Payload und sehen kryptisch aus.
Heise schreibt dazu:
[quote]Damit die Hintertür dann auch ausgeführt wird, müssen neben der gültigen Signatur noch weitere Vorbedingungen erfüllt sein:
Die Umgebungsvariable TERM – üblicherweise Kennzeichen für eine interaktive Terminal-Sitzung – darf nicht gesetzt sein,
Der Zielprozess muss /usr/sbin/sshd heißen,
weder die Umgebungsvariablen LD_DEBUG noch LD_PROFILE sind gesetzt,
eine Sprache ist mittels der Umgebungsvariable LANG festgelegt
keine Debugging-Session mittels rr oder gdb findet statt.
Trifft eine der Vorbedingungen nicht zu, verweigert die Hintertür den Dienst.[/quote]
Bis auf die zwei Systemvariablen mit LD_ am Anfang trifft keine Bedingung zu. Also, selbst wenn der Code da wäre, würde es nicht passen.
Ja, natürlich passt (bisherige) Linux-Backdoor-Info nicht auf Win, nicht mal auf viele Linuxe. Hehe, aus Versehen in VM sogar getestet, verwechselte Script zum Test mit bösem Sript, die „if ! .. exit 0“ funktionieren total gut ;-).
Derzeit sehe ich das immer noch als „investigating“ – so checkt thesamesam @gist.github auch andere Projekte und Commits von „Jia Tan“, Heise ist schon 1.5 Tage alt, bisher bezog man sich primär auf Linux. Was da ggf in 1-2 Tagen noch gefunden wird – wer kann es ohne Analyse, Disassemble oder Review sagen… Daher schau ich immer gern nach.
thesamesam nennt es „it’s still fairly early days here on this“
Ideologische Verblendung ist eine der drei Kardinalsünden des menschlichen Geistes.
Nachdenken.
Anschließend bitte die Problemlösung erarbeiten. Danke.
v.e.d.
M
Hier bei Gynvael eine sehr nette Analyse vom Bash-Scripting der Backdoor. Witam und Dziękuję an Gynvael @coldwind ! Die bisher beste Analyse die ich für den Bash-Roleout der Backdoor sah.
Bei dem ganzen Replace mit „tr“ (Linux, tr wandelt Zeichen um) wird einem schwindelig. Einmal quer durch die Linux-Shell von AWK, head bis tr: Primär LOTL (live of the land, Lebe von Funktionen im System).
Summary bei coldwind: „Someone put a lot of effort for this to be pretty innocent looking and decently hidden … if this was found by accident, how many things still remain undiscovered“
Nachtrag: Und hier bei Rhea’s Substack der Versuch einer Geo-Eingrenzung anhand von Timezons und Commits
Bzgl. Rhea’s Substack:
Ich bin da nicht so optimistisch wie er. „Jia“ hat sehr geplant und sorgfältig gearbeitet, so simple Dinge wie Spuren verwischen könnte aber schon ich als ehem. Hobbyprogrammierer:
Man arbeitet mit einem lokalen git (war um 2000 Usus!) und scheduled commits zu Github in das gewünschte Zeitfenster. Muss man nur 1x sauber aufsetzen, dann geht das automatisiert.
Generell ist cyber attribution mMn weit eher Schlangenöl (und (polit.) Propaganda)* als seriöse Arbeit, man verlässt sich mehr oder weniger darauf, dass der Angreifer unprofessionell/unachtsam/schlampig arbeitet und nicht gezielt Falschhinweise einbaut (ähnlich „Swatting“ in den USA).
* deswegen finde ich es auch schade, dass Hr. Born so dankbar auf den Zug aufspringt
Für alle, die immer noch Ihre Test-, Op-, oder Dev-Systems nicht gemanaged oder isoliert haben – es kursieren schon erste Exploits – zB hier auf Github, um mit eigenen Mitteln Eure Thumbleweed oder SID-Server zu kapern (4 Tage nach Disclosure – da war wohl jemand nicht nur 4 Tage an der Konsole und hatte auch „lecker Lammbraten“ oder „Ostereier suchen“).
macht also was!
Mehrere Fehlannahmen:
– die Distri’s haben nachgebessert, wenn automatisch gepatcht wird (was in der Regel der Fall ist, sonst wäre man gar nicht erst potentiell betroffen), ist das Thema vom Tisch
– der „Exploit“ funktioniert nur, wenn man selbst noch die liblzma patcht und dann den eingepatchten Schlüssel veröffentlicht. Das wäre, wie wenn du den Schließzylinder deiner Wohnung austauschst und den Schlüssel von außen an die Tür klebst/nagelst
So oder so, ein Exploit von dritten, die nicht die Backdoor gebaut haben, ist aktuell sehr unwahrscheinlich.
Hier die Analyse des „schönen Sprechers von SEMPERVIDEO“ ->
https://www.youtube.com/watch?v=lZ273lk8-2c