Laut heise.de soll der Text fortlaufend aktualisiert werden.
https://forum.manjaro.org/t/the-xz-package-has-been-backdoored/159043/3
4 Likes
die frage ist ja ob diese hackergruppe nicht noch weitere pakete manipuliert hat.
die vertrauenswĂĽrdigkeit wurde jedenfalls von den hackern brutalst ausgenutzt.
das ist eine geschichte für einen krimi. der hauptentwickler wird genötigt/erpresst um “auszusteigen”, verschwindet danach spurlos weil er eine “auszeit” genommen hätte und die kriminellen kapern die projektseite um ihre schadsoftware zu installieren mit der sie über eine “gesicherte” ssh verbindung zugriff auf die rechner zu bekommen.
hört sich für mich aber nicht nach einem ausländischen dienst an sondern eher eine kriminelle bande die auf cryptomining aus ist.
Holywood hat von weniger Films gemacht 
1 Like
Hallo,
da ich von den Details so gut wie gar nichts verstehe, möchte ich Euch gerne fragen:
Besteht auch fĂĽr die Manjaro-Benutzung eine Gefahr?
Und: Kann man da etwas dagegen tun, auch wenn jemand, so wie ich, im Prinzip keine Ahnung von der Problematik hat?
Mach ein Update (heute) fĂĽr den Rest sorgt manjaro 
Es besteht im Moment kein wirklicher Grund zur Beunruhigung.
Manjaro (Arch) ist mit einem blauen Auge davongekommen. Wirklich betroffen waren Debian und Suse. Für eine vollständige Entwarnung ist aber noch nicht der Zeitpunkt gekommen.
Der Angriff war zwar da, aber er ist relativ schnell entdeckt worden, und Gegenmaßnahmen laufen auf vollen Touren. Die Aufräumarbeiten können aber schon noch einige Zeit dauern 
1 Like
Nein zu beiden Fragen.
FĂĽr Manjaro (stable) ist das ohnehin (noch) kein Problem gewesen.
Und auch für “unstable” gab es - nach dem was bisher über das Ausmaß bekannt ist - keine Folgen.
Es ist ein häßliches (ein weiteres häßliches) Abbild menschlichen Verhaltens.
Wurde bemerkt bevor es kritisch wurde.
Menschen sind halt so - scheint halt nicht nur so. Ist so.
FĂĽr Dich bestand oder besteht keine Gefahr.
Meine Meinung:
das war wohl ein “Backdoor in the making” - noch nicht komplett fertig.
Wenn es unbemerkt geblieben wäre - und tiefer in andere Projekte eingedrungen wäre - dann hätte das wirklich häßlich werden können.
… meine Meinung …
3 Likes
@andreas85
leider ist es nicht schnell entdeckt worden. das ganze hat schon vor 2-2,5 Jahren begonnen und was die vorhatten und wie weit sie schon waren ist noch ganz im dunklen. das ist imho auch das wirklich erschreckende. die art und weise wie sie das projekt im wahrsten sinne gekapert haben und schritt fĂĽr schritt die schadsoftware verbessert und ausgebaut haben und es so lange unentdeckt geblieben ist.
… es gab ja anscheinend nur den einen einzigen Maintainer - der auch explizit gesagt hat, daß er damit zu Zeiten überfordert ist
Ich hätte mich wohl auch (durch die offensichtlich kompetente) Unterstützung überreden lassen.
Wer hat’s geprüft?
er allein - wie es aussieht
aufgefallen ist es erst, als sshd nicht mehr performte
… das Leben ist lebensgefählich …
1 Like
man hat auf alle fälle enormen druck auf ihn ausgeübt damit er das projekt abgibt.
schlimm wird es wenn trittbrettfahrer diese methode kopieren (werden). es gibt genug durch und durch kriminelle die mit gekaperten rechnern cryptomining betreiben. ist für mich in dem aktuellen fall auch das wahrscheinlichste motiv, irgendein “fremder dienst” ist wohl eher mediale fiktion. aber gut das muss man erstmal abwarten wer und warum und vor allem wie das funktionieren sollte.
Wirklich sehr detailiert ausgedacht, um der Entdeckung zu entgehen. Das indirekte Laden um die Ecke per sshd → systemd → lib ist wirklich perfide.
Den SchlĂĽsselaustausch von sshd zu kompromitieren ist in mehrfacher Hinsicht ein einmaliges Vorgehen. Da hat sich jemand wirklich umfassend Gedanken gemacht. Das war keine Einzelperson.
Da waren Profis am Werk.
1 Like
aus dem bericht
Somit können ... Angreifer ohne Zugangsdaten Code ausführen,
das “zwar” erspare ich mir bewusst, weil es verharmlosend ist. schon heftig wie sie es geschafft haben die ssh-verschlüsselung auszuhebeln und selbst ohne einen account code ausführen können. kann man nur hoffen das die devs vom ssh-projekt diese schwachstelle zügig bereinigen damit nicht trittbrettfahrer die selbe schwachstelle des ssh-dienstes ausnutzen. klar ist für mich das ssh aktuell absolut nicht sicher ist und ein potentielles risiko darstellt. das ist ein ernstes problem das unverzüglich behoben werden muss, ansonsten können/müssen wir uns das thema linux als sicheres system schenken.
die hacker haben ihr ziel also erreicht gehabt, sie konnten ssh nutzen um code auszufĂĽhren ohne zugangsdaten zu besitzen. so ist ssh ein absolutes no-go.
Hi zusammen
Sorry falls OT, ich bin mir nicht sicher, ob das hier der richtige Platz fĂĽr meine Frage ist.
Es gibt bei allem, was ich zum Thema gelesen habe, eine Sache, bei der ich mir nicht sicher bin, ob ich sie richtig verstanden habe:
Auf meinem Desktop und zwei Laptops läuft Manjaro (stable). Ich habe aber auch zwei Server unter Debian Bookworm laufen, ein Raspi mit RaspberrypiOS und einen Strato VPS mit Debian. Die Version von xz-utils unter Bookworm ist 5.4.1, also nicht betroffen. Aber ich habe mich natürlich von meinen Manjaro-Rechnern auf den Debian-Servern eingeloggt. Besteht das Riskio in diesem Fall für den lokalen Rechner oder den Server?
suse,debian,fedora und alle ubuntu-derivate sind auf alle fälle kompromitiert. dort musst du schauen was die distromaintainer als quick-fix anbieten. downgraden ist eine ganz schlechte lösung, mittlerweile weiß man das das ganze schon in 2021 angefangen hat, was und wieweit infiziert ist wird noch geprüft aber man sollte besser vom schlimmsten fall ausgehen. klar ist jetzt das ein betroffener rechner code ohne jegliche zugangsdaten ausführen kann und das geht dann vice-versa.
unter manjaro solltest du auf alle fälle die version 5-6.2-1 installieren. alles andere steht noch in den sternen und wie gesagt bei debian schau auf deren seiten und foren nach wie die das aktuell handhaben.
debian,fedora und alle ubuntu-derivate sind auf alle fälle kompromitiert.
Die unstable und testing Versionen. Es geht ja erst um Versionen ab 5.6.0, und unter Bookworm läuft ja noch 5.4.1. Daher eben meine Frage, weil ich mich natürlich seit Februar ja von meinen Manjaro-Systemen da eingeloggt habe.
In anderen Worten, auf welchem Rechner wird der Schadcode ausgefĂĽhrt, lokal oder remote?
ja, gehe davon aus das alles bis auf die aktuelle 5.6.2-1 potentiell betroffen ist, ohne ausnahme.
prinzipiell beides. mit dem trick kann man vice-versa rechner steuern und code ausfĂĽhren. volltreffer in der kombĂĽse !
Kein Grund zur Panik !
Es ist erstmal nur der Rechner betroffen, der
- die kompromittierte Bibliothek auch hat, (5.6.0 oder 5.6.1)
- der systemd und
- sshd aktiv hat
Fehlt eine der 3 Voraussetzungen, ist der Rechner nicht betroffen.
Ssh selbst scheint nicht betroffen, sondern nur sshd !
Dein lokaler manjaro Rechner ist also nicht in Gefahr. FĂĽr den Server reicht es zu prĂĽfen, welche Version der betroffenen Bibliothek aktuell eingesetzt wird.
Nach momentanem Kenntnisstand verschwindet die Backdoor, sobald die Bibliothek gegen eine nicht kompromittierte Variante ersetzt wird. Es ist also erstmal nichts was sich auf dem Rechner irgendwie einnistet. 
2 Likes
das problem verschwindet aber nicht ! letzten endes ist es der ssh-dienst der es zulässt das man über rsa-schlüssel code ohne jede zugangsberechtigung ausführen kann. das problem ist imho nicht die schadhafte bibliothek mit der man das genutzt hat, sondern der ssh-dienst der diese lücke zulässt und diese lücke (stand heute) kann jederzeit wieder genutzt werden. da liegt für mich das eigentliche problem.
Danke 
Falsch!
Auch das geht an den Fakten vorbei!
Im Moment sind sich alle Fachleute darin einig dass nur sshd betroffen ist (das ist der server)
Ssh selbst scheint nicht betroffen, und ist auch keinesfalls schuld an dem Problem
Das Emoji das ich unter Deinen Beitrag gemacht habe heißt “pray”
Ich möchte es aber als “Dankeschön” verstanden wissen.
… so ist das mit Emojies - offen für Interpretationen 
1 Like