Lücke in XZ Utils und damit ggf. auch in SSHD unter Linux

  • Moin Leute,

    öfter mal was neues. Falls Ihr einen Server betreibt der einen SSH Server bereitstellt (ist ja nicht ungewöhnlich) dann checked doch bitte mal eure Version der xz Utils (beinhaltet liblzma) unter Linux (Kommando ist xz -V).

    Die Versionen 5.6.0 und 5.6.1 haben scheinbar eine Backdoor eingebaut welche am 29.03.2024 entdeckt wurde. Realistisch muss man sagen das man wohl eher nur betroffen ist wenn man einen Server mit einer Rolling Release Distro betreibt. Die Versionen der xz Utils unter Debian 11 und 12 sind z.B. viel zu alt um betroffen zu sein.

    Eine Übersicht wo die verwundbaren Pakete drin stecken können seht ihr hier: https://repology.org/project/xz/versions

    Eine detaillierte Beschreibung der Lücke findet ihr hier:

    Externer Inhalt gist.github.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.

    Deutsche Infos gibt es hier: https://www.borncity.com/blog/2024/03/3…der-ssh-server/

    Wenn Ihr die V 5.6.0/5.6.1 irgendwo bei euch findet unbedingt updaten oder das System so lange vom Netz nehmen bis es Updates gibt.

  • Ziemlich krasse Sache, es gab ja auf allen möglichen Techseiten Berichte dazu. Wenn man sich mal durchliest, wie perfide und langfristig das geplant war, dann will ich mir gar nicht vorstellen, was es da schon an Hintertüren gibt, von denen einfach keiner weiß.

  • Jap das hat eher sehr viel mit klassischem Social Engineering zu tun.

    Das Problem was es hier gibt ist mit der Log4J Lücke vor einigen Jahren vergleichbar. Eine wichtige Software Komponente in der Open Source Szene die von einer Einzelperson, am Rande des Burnouts, in Ihrer Freizeit Maintained wird.

    Aber auch hier hätte es ggf. die Möglichkeit gegeben es technisch zu unterbinden. Scheinbar wird nämlich nicht gechecked ob die Release Tarballs die Upstream gehen dem entsprechen was im Git Repo steckt. Bei alles was ich gelesen habe war das Backdoor ja nicht im Git Repo vorhanden sondern wurde in den Tarballs versteckt die an die Distributionen gingen. Wäre das Backdoor in den Commits des Git Repo aufgetaucht dann hätte man es früher bemerken können.

  • Und wie laeuft der exploit ab ? Wollte da jetzt nicht stundenlang lesen bis ich auf was stosse.

    Vermute mal, das der exploit nicht erlaubt einfach von aussen via SSHD ins system zu gelangen ohne passwort, aber das wenn sshd laeuft das der exploit als root (weil SSHD root ist) am system rumpfuscht ??

  • Doch anscheinend ist genau das der Fall:

    Red Hat mentions that “the resulting malicious build interferes with authentication in sshd via systemd. Under the right circumstances, this interference could potentially enable a malicious actor to break sshd authentication and gain unauthorized access to the entire system remotely.”

    XZ Utils SSHd Backdoor | Qualys Security Blog
    On March 29th, 2024, security researcher Andres Freund discovered a backdoor in XZ Utils versions 5.6.0 and 5.6.1. Under certain conditions, this backdoor may…
    blog.qualys.com
  • Danke. Mehr Details waeren natuerlich interessant. Frage mich ob die ganze Schadsoftware erst durch ein laufendes sshd getriggert werden muss, und wie der schadcode dann am system rumpfuscht.

  • Sicher ein verwundbares (extern erreichbares) sshd muss auf dem System laufen. So wie ich das gelesen habe sorgt die bösartige liblzma dann übrigens dafür das die Authentifizierungsroutine von sshd so manipuliert wird das ein Schlüssel den nur der Angreifer hält für valide gehalten wird.

    Externer Inhalt gist.github.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.

    Das blöde daran: eigentlich braucht SSHD die liblzma eigentlich nicht, Sie wird nur von den meisten Distri's mit reinkompiliert weil Systemd eine Abhängigkeit dazu hat.

  • für LE12 (11 ?) wurde es gefixt (?), zumindest auf eine unbetroffene (?) xz-Version reverted

    xz: revert to 5.4.6 by HiassofT · Pull Request #8773 · LibreELEC/LibreELEC.tv
    xz release tarballs 5.6.0 and 5.6.1 have been compromised with malicious code https://www.openwall.com/lists/oss-security/2024/03/29/4 tukaani-project/xz#92…
    github.com

    und mehr:

    move xz (lzma) support out of sysroot by heitbaum · Pull Request #8779 · LibreELEC/LibreELEC.tv
    The follow changes allow the xz package to be moved out of sysroot The pre_configure_target for vfs.libarchive and pvr.iptvsimple allow xz to be linked in…
    github.com

    und

    drop xz package entirely by heitbaum · Pull Request #8775 · LibreELEC/LibreELEC.tv
    The follow changes allow the xz package to be entirely dropped some run testing is definitely needed The patches to vfs.libarchive and pvr.iptvsimple upstream…
    github.com
  • Haben halt einen Rollback gemacht. Aber in dem Beitrag steht auch das man dort keine Zeichen einer Infektion gefunden hat.

    Wenn Sie liblzma aus den Sourcen bauen sind Sie nicht betroffen, das Backdoor war nur in den Release Tarballs die Upstream gegangen sind und nicht im Sourcecode auf Github. Nen Rollback zu machen war aber auf jeden Fall die bessere wahl.

  • Soweit ich gelesen habe, waren "nur" einige Nightlies und Rolling Releases betroffen. Glücklicherweise wurde es ja entdeckt, bevor die neue Bibliothek in die Main Releases übernommen wurde.

    Das wurde von den Urhebern aber wohl massiv gepusht, und dann wäre Tür und Tor offen gewesen.

    Vielleicht hat es ja was Gutes und es werden mehr und bessere Tests für den ganzen Kram eingeführt, was dann wieder zu etwas mehr Sicherheit führt.

  • Falls Ihr einen Server betreibt der einen SSH Server bereitstellt

    Ich finde diese Formulierung etwas unglücklich.

    Ich betreibe mit LE auch keinen Server, stelle aber n.M.n. trotzdem unter LE einen SSH-Server bereit.

    Falls ich richtig liege: Nicht, dass sich Non-Server-Betreiber in, ggf. falsche, Sicherheit wiegen ...

    Schon klar: Dass Server-Betreiber, mit ggf. externen Zugängen, nochmal zusätzlich exponiert sind !

  • Kannst mich gerne berichtigen aber unter LE ist der SSH Server nicht standardmäßig aktiv und ohne das man Portforwarding einrichtet schonmal garnicht über das Netz erreichbar. Es gibt mMn auch absolut keinen Grund den SSH Server eines LibreElec ins Internet zu hängen. Genauso wenig wie bei Desktop Linux Systemen. Wenn man dies jedoch tut dann weiß man hoffentlich ganz genau was man macht und dann sollte auch diese Formulierung nicht missverständlich sein.

    Radiuskoepfchen hat schon recht. Dadurch das dieses Backdoor es nur in einige Rolling Release Distributionen und Testbranches geschafft hat ist der Schaden zum Glück gering. Das sind eigentlich Distributionen die man idR nicht als Server OS nutzt und schon garnicht als Produktivumgebungen. Aber wer weiss vielleicht war das ganze auch nur ein Testballon.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!