News Sicherheitslücke in xz: Backdoor in Linux-Archivbibliothek macht Systeme angreifbar

[Rassnahr]

VPN, Reverse Proxy u.ä. sind kein Begriff?

Auch wenn das VPN auf dem gleichen Server läuft bist du immer noch in einer bessere Situation als mit zig offen erreichbaren Diensten. Da brauchst du auch keinen extra Server für mieten

Aber eine VPN Verbindung ist auch nicht sicherer als SSH (mit pub/private key Auth), für den VPN braucht es auch einen offenen Port beim Server.

Ergänzung (1. April 2024)

Lücken in SSH sind sehr selten, das ist nicht die Angriffsfläche über die ich mir die meisten Gedanken machen würde.

Wie meinst du das?
Es war bzw. ist ja keine Lücke in SSH.
Sondern xz und weil beides mit SystemD gelinkt ist.

Ohne die SystemD Verlinkung geht es ja nicht, daher ist auch Arch nicht betroffen oder FreeBSD oder Homebrew.

 

[Termy]

Aber eine VPN Verbindung ist auch nicht sicherer als SSH (mit pub/private key Auth), für den VPN braucht es auch einen offenen Port beim Server.

Das nicht - aber der VPN-Server läuft in der Regel mit deutlich weniger Rechten als eine SSH-Sitzung. Es müssten also zwei Sicherheitslücken/Backdoors kombiniert werden, um RCE o.ä. durchführen zu können.

 

[lynx007]

Passend zum Thema ^^

 

[Skysnake]

Das Rootkonto nutzt man nur wenn man sehr viele Befehle hintereinander eingeben muss die Root benötigen.
Ist man fertig dann schnell "exit". Ansonsten reicht sudo vollkommen aus.
Wer aktiv mit dem Rootkonto arbeitet der wird schnell Lehrgeld zahlen.

Was man ja aber durchgehend macht, wenn man wirklich administriert und nicht nur nebenbei paar Sachen ändert.

Ich logge mich morgens ein einmal als root und einmal als normaler User und dann werden den ganzen Tag auf beiden Konten Dinge gemacht.

nfs mounts miz rootsquash machen es nötig.

Bei Open source kann man. Zwar theoretisch die Fehler finden, aber ich kenne keinen einzigen Programmierer der danach aktiv sucht. Ich übrigens auch nicht. Jeder hofft, dass die anderen das schon machen werden. ist eben eine total langweilige Aufgabe, fremden Code auf Fehler zu überprüfen.

Wenn was gefunden wird, dann eher zufällig, weil jemand über den Code stolpert. 🪤

Naja, also wenn ich über irgendwas stolpere dann suche ich erstmal den Code nach weiteren Fehlern entsprechend diesem Schema ab. Jetzt nicht Zeile für Zeile, aber nen kurzer regex oder sonstige systematische Suchen sind da schon der Standard. Die Erfahrung sagt einfach das Fehler oft systematisch sind. Da kann man mit sehr wenig Aufwand oft 80-90% ähnlicher bzw des gleichen Fehlers auch an anderen Stellen finden. Das ist eigentlich immer gut investierte Zeit.

 

[Grimba]

aber ich kenne keinen einzigen Programmierer der danach aktiv sucht. Ich übrigens auch nicht.

Und deswegen ist es für dich völlig unvorstellbar, dass sowas außerhalb deiner Wahrnehmungsbubble durchgeführt wird?

 

[Snowi]

Das nicht - aber der VPN-Server läuft in der Regel mit deutlich weniger Rechten als eine SSH-Sitzung.

Das musst du mir mal erklären bitte.
Ein SSH Server läuft prinzipiell mit den gleichen Rechten wie ein SSH Server.
Effektiv unterscheiden sich beide nicht, außer dass ein VPN Server mehr Code hat, und damit potenziell mehr Platz für Sicherheitslücken.
Aber wenn man den Fakt mal ignoriert, sind beide gleich kritisch. Da gibt es keinen Unterschied.

Anders verhält es sich nur, wenn man den VPN Server in einen Docker-Container wirft und die Containerumgebung vernünftig konfiguriert/absichert. Das kann man aber auch mit einem SSH Server tun, wenn man es möchte.
Da gibt es einfach effektiv keinen Unterschied. Kann man machen, ich würde niemandem davon abraten, aber mMn einfach unnötiger Aufwand, da es faktisch nichts ändert.

 

[TheChris80]

Pauschal bist du sicher, solange du nur Stabile Repos von Debian, Ubuntu oder Fedora nutzt, betroffen sind aber u.a. OpenSuse Tumbleweed (Der Rolling Release), Arch und Kali.
Bei Debian/Ubuntu/Fedora waren betroffenen Versionen, soweit bekannt, nur in Unstable/Testing Repos.

Aber ja, die Backdoor benötigt von außen Zugriff via SSH, wenn du den Zugang aufs Heimnetz einschränkst, zB über eine Firewall, dann ist das nach aktuellem Kenntnisstand nicht kritisch. Es gab noch weitere Bedingungen, die findet man zB im aktuellen Heise Beitrag dazu.

Ich nutze EndeavourOS welches ein Arch derivat ist. Da hab ich jetzt schon etwas bammel.

Der SSH-server selbst aktzeptiert nur anfragen vom Heimnetzwerk.(Die SSH Config) Ohne meinen Router geht gar nichts. Stell ich WIFI auf dem Handy aus dann komm ich nicht rein.

Haupsächlich nutze ich aber SSH nur zum steuern vom System wenn ich auf meiner couch sitze.
Zb für Streams oder Musik.

 

[mibbio]

Ich nutze EndeavourOS welches ein Arch derivat ist. Da hab ich jetzt schon etwas bammel.

Zumindest bei Arch selber ist OpenSSH von der bisher bekannten Backdoor nicht betroffen, da Arch dort nicht die Kopplung mit SystemD verwendet und folglich auch nicht die liblzma reinlinkt. Weiß jetzt aber nicht, ob Endeavour die Pakete direkt aus dem Arch-Repo bezieht oder bspw. OpenSSH in angepasster Form aus einem eigenen Repo.

https://security.archlinux.org/ASA-202403-1

https://archlinux.org/news/the-xz-package-has-been-backdoored/

 

[sedot]

Da hab ich jetzt schon etwas bammel.

Im Forum gibt es einen Thread;
https://forum.endeavouros.com/t/the...nd-the-xz-tarballs-have-been-backdoored/53253

Falls es Updates gibt, zeitnah installieren.

 

[Rassnahr]

Im Forum gibt es einen Thread;
https://forum.endeavouros.com/t/the...nd-the-xz-tarballs-have-been-backdoored/53253

Falls es Updates gibt, zeitnah installieren.

Und dort wird auch auf die Arch Linux news verlinkt welche folgende ist:

[...]
Arch does not directly link openssh to liblzma, and thus this attack vector is not possible. You can confirm this by issuing the following command:

ldd "$(command -v sshd)"

However, out of an abundance of caution, we advise users to remove the malicious code from their system by upgrading either way. This is because other yet-to-be discovered methods to exploit the backdoor could exist.

Also ja stimmt zeitnah ein Update machen aber nach bisherigen Infos ist Arch nicht betroffen.

 

[konkretor]

So hier einmal komplettes reverse engineering des Codes mit Demo

https://github.com/amlweems/xzbot

 

[lynx007]

@lorpel

Bei Open source kann man. Zwar theoretisch die Fehler finden, aber ich kenne keinen einzigen Programmierer der danach aktiv sucht. Ich übrigens auch nicht. Jeder hofft, dass die anderen das schon machen werden. ist eben eine total langweilige Aufgabe, fremden Code auf Fehler zu überprüfen.

Ich kenne einen der verdient sogar Geld damit, fehler aus dem Code zu bügeln. Was er mir so schildert, wäre es aber wohl auch kein Beruf für mich. Man muss praktisch alles Dokumentieren und jeden Fall der Fälle ausprobieren. Am ende, nach vielen Reports gibt er dann als teil es "Connsalting" seine Empfehlung ab, und muss schlucken wen er trotz empfehlung das Update zurück zu stellen, übergangen zu werden. Stelle ich mir unter umständen auch wenig satisfying vor.
.
Aber dafür hat er mit ende 40 seine eigene abbezahlte Eigentumswohnung. Hat also auch Vorteile, einen Job machen zu können, den nur wenige machen "können". Dafür hat er keinen Serverraum der "brennt" und ihm abwechslung bereitet. Manchmal habe ich den eindruck das selbst Ihn die arbeit nicht genügend aufregung bietet.

.
Aber ich finde einen Teilbereich der Fehlersuche, das "Bughunting" aber auch irgendwie spannend. Zumindest wen ich ausblende wieviel knowhow und systematische Arbeit dahintersteckt. Denn dann versteht man auch schnell warum keine Lust darauf hat. ^^

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

 

[Unnu]

Bei Closed Source bleibt nur das Vertrauen.

LOL! Ja!
Ich habe vollstes vertrauen in MS, dass die Regelmäßig fuckups liefern, die dann mit Pech schon ausgenutzt werden und man sich sputen muss, damit wenigstens die Endpoints nicht aufgemacht werden!

Ergänzung (2. April 2024)

Stellt euch nur mal vor, wenn das noch mindestens 1 Jahr nicht aufgefallen wäre.

Log4j here we come …!

 

[Grimba]

Naja, zumindest gibt's bei MS offenbar ein paar fähige Leute, denn der Finder der XZ Backdoor, Andres Freund, ist ja bei Microsoft. Immerhin.

 

[konkretor]

So gibt einen Honeypot

https://github.com/lockness-Ko/xz-vulnerable-honeypot

 

[Teuti]

Moin, langsam nervt die Diskussion hier, um dass eigentliche Thema geht’s hier überhaupt nicht mehr, nervtötend.

 

[dh9]

Das geht jetzt leider an der Sudo/Root Diskussion vorbei...

Russ Cox hat hier eine sehr detailierte Analyse geschrieben, wie genau sich die Backdoor "versteckt" und einrichtet:

https://research.swtch.com/xz-script

Mehr als nur trippy ;-)

 

[Pummeluff]

Auf Heise wurde die Geschichte auch nochmal hübsch aufbereitet.

 

[Grimba]

Da es sich bei so einer Backdoor um den feuchten Traum jedes Geheimdienstes handelt, frage ich mich, ob man jemals gesichert erfahren wird, wer dahinter steckt. Weil ein Interesse daran teilen ja quasi alle Tunichtgute auf dem Gebiet.

 

[dh9]

Ich tippe auf jemanden mit viel Zeit und Geld.

Interessanter finde ich allerdings nicht wer es war, sondern wie sich die OSS Community in Zukunft davor schuetzen wird. Die Buildprozesse usw. werden in Zukunft staerker beleuchtet und verbessert, bzw. abgedichtet.

1. Never allow files in release tar-balls which are not present in the repo.
2. As a consequence, all generated code should be checked in. Build scripts should re-generate all derived code and fail if the checked in code deviates from the generated.
3. No inscrutable data should be accessible by the release build process. This means that tests relying on binary data should be built completely separately from the release binaries.

Quelle