Linux: Backdoor in Upstream xz/liblzma; Kompromittierung der SSH-Server

Sicherheit (Pexels, allgemeine Nutzung)[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.


Anzeige

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:


Anzeige

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.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit, Software abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

62 Antworten zu Linux: Backdoor in Upstream xz/liblzma; Kompromittierung der SSH-Server

  1. hanz Dampf sagt:

    https://news.opensuse.org/2024/03/29/xz-backdoor/

    Suse Tumbleweed hat es definitiv erwischt

  2. 1ST1 sagt:

    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.

    • Anonymous sagt:

      Du bist ein richtiger Honk.

    • Linux-User-and-Developer sagt:

      "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.

      • Pau1 sagt:

        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.

    • Bernd B. sagt:

      – 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.

    • T Sommer sagt:

      "Der kleine Chelm ist ein Widerporst"

    • Anonymous sagt:

      Troll, confirmed.

    • Daniel sagt:

      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.

    • Ottilius sagt:

      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.

      • T Sommer sagt:

        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.

        • keychess sagt:

          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.

      • Termy sagt:

        Die haben über Ostern leider Freigang. So etwas gehört dauerhaft weggesperrt wegen Gefährdung der Bevölkerung!

    • 1ST1 sagt:

      Ach, herrlich, wie ihr auf euer eigenes Argumentationsniveau reagiert!

    • Dat Bundesferkel sagt:

      Mit Windows wäre das nicht passiert. :)

    • Anonymous sagt:

      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.

  3. nook sagt:

    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! ;-)

  4. Patrick sagt:

    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.)

    • Bernd B. sagt:

      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

      • Robert sagt:

        "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.

    • Norddeutsch sagt:

      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 ):

      – OpenSuse: "we recommend installing fresh"
      – OpenSuse: "rotation of any credentials"
      – Fedora, Born: Nutzung einstellen
      – Debian, Heise, OpenSuse: "Update!"

      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…

      • McAlex777 sagt:

        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.

    • Tim B. sagt:

      Ein einfaches "pacman -Q" zeigt ganz klar "xz 5.6.1-2" an, also die gecleante Version. Zumindest, wenn man geupdated hat.

  5. Hanz Dampf sagt:

    Es sieht aktuell so aus als ob es über Jahre geplant war

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

  6. Benny sagt:

    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.

  7. McAlex777 sagt:

    HomeBrew unter MacOS ist auch betroffen, und sollte aktualisiert werden:

    brew update && brew upgrade

  8. Anonymous sagt:

    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).

  9. Stephan sagt:

    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.

    • McAlex777 sagt:

      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.

      • rpr sagt:

        Na na na,
        jetzt komm mal nicht mit Argumenten:-)
        Die Leute begreifen nicht das viele Updates ungleich weniger sicher ist.
        Gruß

        • Stephan sagt:

          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!

          • McAlex777 sagt:

            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.

    • Ottilius sagt:

      Trollbot von 1st1 oder was ist bei dir schief gelaufen?

    • Ottilius sagt:

      der nächste Kernschwachsinn. Schön spannend, wie sich die Windows-Jünger hier als absolute IT Nullchecker outen…

      • Stephan sagt:

        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!

        • Norddeutsch sagt:

          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…

        • Ottilius sagt:

          Kannst du eigentlich irgendwas außer dümmlich herumzutrollen, Stephan?

  10. Bolko sagt:

    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

    • Norddeutsch sagt:

      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:

      – Win10 22h2 – durch Alter "clean" (libarchive Version 3.5.1.0)
      – Win11 22h2 – Commits von Jia Tan vorhanden (3.5.1 .. 3.6.2 )
      – Win11 23h2 – (Stand vor 12h dort in Diskussion)

      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.

      • 1ST1 sagt:

        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.

        • Norddeutsch sagt:

          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"

  11. M sagt:

    Ideologische Verblendung ist eine der drei Kardinalsünden des menschlichen Geistes.
    Nachdenken.
    Anschließend bitte die Problemlösung erarbeiten. Danke.

    v.e.d.

    M

  12. Norddeutsch sagt:

    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

    • Bernd B. sagt:

      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

  13. Norddeutsch sagt:

    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!

    • Anonymous sagt:

      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.

  14. Tom sagt:

    Hier die Analyse des "schönen Sprechers von SEMPERVIDEO" ->

    https://www.youtube.com/watch?v=lZ273lk8-2c

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.