DJKuhpisse
Volt-Modder(in)
Das Ding hat es auf ein paar Produktivsysteme geschafft. Ob und wie viele davon dann kompromittiert wurden, ist mir unbekannt.
News Ubuntu 24.04 LTS ("Noble Numbat"): Schädlicher Code sorgt für schlechte Nachrichten
- Ersteller PCGH-Redaktion
- Erstellt am
retrogamer0815
Komplett-PC-Aufrüster(in)
Ich hab mir eingebildet der Hack wär Linux only ....oder ist Windwos schon Linux mit MS UI ?
DJKuhpisse
Volt-Modder(in)
Da unter Windows das Linux-Subsystem zur Verfügung steht, kann es auch hier betroffene Systeme geben, sofern die Version von liblzma installiert ist/war.
Schnitzelnator
Software-Overclocker(in)
Das stimmt, aber wenn man nur das Kompilat in Binärform vorliegen hat, ist das Finden von Lücken natürlich fast unmöglich - vor allem wenn, wie hier wohl, die Lücke nur mit einem bestimmten Schlüssel ausnutzbar ist. Ich denke, wenn im Microsoft RDS so etwas wäre, könnte das nur Microsoft selbst finden. So viele Menschen, die Binärcode lesen können, gibt es nicht...
Es stimmt, dass die Projekte oft von einzelnen Personen betreut werden. Aber den Grund für den Beinahe-GAU sehe ich darin nicht. Ich denke, dass nicht verhindert werden kann, dass jemand sich das Vertrauen erschleicht und eine Backdoor veröffentlicht. Meiner Meinung nach hätten die Systeme der Distributoren es aber spätestens beim Paketieren erkennen müssen.
Und ich denke auch, dass es sogar leichter wäre, V-Männer als Mitarbeiter in Unternehmen einzuschleusen, die Closed-Source Software herstellen, um Lücken einzubauen, als Lücken in Open Source Projekte einzubringen. Denn den Mitarbeitern wird ja bereits ein Grundvertrauen entgegen gebracht, das dahergelaufene sich erst "erarbeiten" müssen.
Ich denke nicht, dass in einem weiteren so elementaren Bestandteil wie SSH etwas gefunden wird. Aber es ist gut, systematisch zu prüfen und eine entsprechende Stiftung wäre vermutlich eine sinnvolle Einrichtung.
Ich sehe da weiterhin einen sehr großen Unterschied. Schaut man sich Projekte wie OpenBSD an ("Only two remote holes in the default install, in a heck of a long time!"), dann kann man vermuten, dass in Open Source Software sehr viel weniger Lücken sind. Zwar hatte Linux in seiner Geschichte sicherlich mehr Lücken als OpenBSD, aber tendenziell weniger als in Closed-Source-Projekten an unbekannten Lücken schlummern, oder solchen, die nur wenige kennen.
Welche Produktivdistro ist denn betroffen? Oder ist das vielleicht einfach nur eine Lektion, warum man auf Produktivsystemen besser nicht den neuesten Kram laufen lässt?
wurstkuchen
BIOS-Overclocker(in)
Falsch. Ist es so schwer sich die beiden Posts anzuschauen? Da geht es um WINDOWS Integration wo der Jia auch Code beigesteuert hat in der Datei C:\Windows\System32\archiveint.dll das hat nichts mit dem Linux Subsystem zu tun. Das ist Windows Explorer Code um XZ Archive zu nutzen unter Windows.
Mit dem Update hier wurde das eingebaut https://support.microsoft.com/en-us...631-2715-f9e3e13c-5e98-42c2-add8-f075841ca812
Es ist also davon auszugehen dass die dll archiveint.dll auch Schadstoff enthält, wie das genau funktioniert oder überhaupt ist nicht offen da kein Quellcode vorhanden.
DJKuhpisse
Volt-Modder(in)
OpenSUSE Tumbleweed, Arch.
Dann natürlich noch die ganzen Entwicklerversionen. Die sind auch auf Produktivsystemen im Einsatz, u.a. bei einigen Debian-Entwicklern und auch bei mir, weil ich uralte Versionen auf meinem Desktop-PC nicht brauchen kann.
Warum soll das denn im Windows-Subsystem für Linux nicht auch funktionieren, wenn man da eine entsprechende Distribution samt sshd hat?
wurstkuchen
BIOS-Overclocker(in)
Mein Gott natürlich würde es da auch gehn, wayne? Und in einer Virtuellen Maschine auch. UND!? Darum ging es nicht. Es ging darum dass es Schadcode scheinbar auch direkt in Windows gibt in einer dll. Und man nicht weiss was dieser genau tut, das könnte auch ein ganz anderer Trojaner sein der auf Windows Systeme zugeschnitten ist. Nur dass dort wohl auch Code von dem selben Dev in Windows code eingebaut ist.
Arch als Produktivsystem? Tumbleweed soll ja sogar eine stabile Produktions- und sogar Serverdistro sein, das hätte ich nicht erwartet oder zumindest, dass dann zwischen dem Erscheinen von neuen Versionen und deren Verteilung mehr Zeit liegt. So, wie Tumbleweed beschaffen ist, halte ich das als Produktionsdistro für sehr gewagt.
Ich nehme mal nicht an, dass die Debian-Entwickler auf den Testversionen mit sensiblen Daten hantieren. Für Privatkram kann man das ja machen, im produktiven Umfeld halte ich das aber für eine schlechte Idee, auch auf Desktops.
DJKuhpisse
Volt-Modder(in)
Dürfte auf ein Großteil der Arch-Systeme zutreffen.
Von SUSE gibt es verschiedene Varianten. Tumbleweed-Nutzer wollen genau dieses Verhalten und akzeptieren, dass das eben kein RHEL mit 10 Jahren Support ist, bei dem man in dieser Zeit keine großartigen Änderungen erwarten kann.
Auch ein Laptop kann damit laufen und ein Produktivsystem sein, bei dem Daten vorhanden sind, die nicht in fremde Hände gelangen sollen.
So z.B. bei mir. Da gibt es dann manchmal auch einen SSH-Zugang für den Fernzugriff. Ich brauche sowas z.B..
Ich vermute, dass das oft der Fall ist. Auch außerhalb wird unstable doer testing für produktive Zwecke genutzt. Klar ist das instabiler, aber das bedeutet halt nicht, dass es unattraktiv für Angreifer sein muss.
Auch da wird das manchmal gemacht, wenn z.B. einfach die aktuellste Software benötigt wird.
Schnitzelnator
Software-Overclocker(in)
Tumbleweed ist im Prinzip eine Art SUSE-Version von Arch. Es ist sehr stabil im Bezug auf die Funktion. Aber es wird die neueste Software vom entsprechenden Open Source-Projekt ohne Verzögerung geliefert.
Ich sehe die Verbreitung dieser Distributionen auch hauptsächlich auf dem Desktop. Für einen Server finde ich z.B. Tumbleweed, Arch usw. zu neu, weil neu aus meiner Sicht auch bedeutet, dass der Code noch nicht so lange öffentlich herumliegt und das ist natürlich generell ein höheres Risiko.
In der Regel ist SSH auf Desktopsystemen nicht aktiv - bei Tumbleweed beispielsweise ist bei einer Desktopinstallation standardmäßig der SSH-Server inaktiv. So ist das auch bei all meinen Tumbleweed-Systemen.
Das ist natürlich in dem Fall schlecht gelaufen. Natürlich sind manche Systeme letztlich betroffen gewesen. Aber ich denke, dass es nicht häufig ist und wenn es ein staatlicher Angreifer war, ist es extrem unwahrscheinlich, dass er schon häufig angegriffen hat. Denn im Zeitpunkt des Angriffs kann man auch die Lücke entdecken.
Vermutlich wollte man sich diese Zugriffsmöglichkeit ganz gezielt für bestimmte Systeme vorbehalten oder warten, bis alle Systeme betroffen sind, und dann einen Großangriff auf einen Schlag starten.
Somit denke ich, dass alle nochmal mit einem blauen Auge davon gekommen sind und manche nur ihre Daten sichern und ihr System neu aufsetzen sollten.
Offensichtlich ganz im Gegenteil. So ist nun mal die Situation und das Risiko geht man dann halt ein. Muss halt jeder für sich entscheiden. Ich würde vermutlich eher einzelne Pakete, die ich in wirklich aktuell brauche, als Flatpak installieren.
Das widerspricht sich halt schon irgendwie. Stabilität und Sicherheit sind natürlich relativ, aber Software, die aktueller ist, ist einfach weniger stabil und sicher als welche, die schon länger verfügbar ist. Das heißt natürlich nicht, dass neuere Versionen nicht benutzbar sind, aber es ist halt, wie du selbst schreibst:
Ich sehe es bei produktiv genutzten Desktops halt ähnlich.
The_Invisible84
Komplett-PC-Aufrüster(in)
Wir haben selbst über 250 Linux VMs und 2 Kubernetes Cluster am laufen, dort irgendwas anderes als LTS/Enterprise Distros zu verwenden wäre Wahnsinn, Rolling Release hat im Enterprise segment quasi nix zu suchen.
Schnitzelnator
Software-Overclocker(in)
Teilweise ja, man kann aber auch etwas dagegen tun, z.B. indem man Snapshots testet und so sicherstellt, dass in Tumbleweed nichts sehr wichtiges kaputt gegangen ist. (Edit: Einen Test für Steam und Wine gibt es da auch.)
Aber natürlich kann man solch ausgeklügelt versteckten Sicherheitslecks wie hier damit nur schwer auf die Schliche kommen.
Sicherlich steckt in Versionen, für die Firmen Wartungsverträge haben, noch viel mehr Manpower und somit sind die auch nochmal deutlich stabiler. Für ein Gamingsystem für das eigene Zuhause sollten solche Tests wie oben erwähnt aber erst mal ausreichen und Tumbleweed in der Stabilität deutlich vor viele andere Distributionen bringen (die ebenfalls sehr neue Pakete ausliefern).
Deshalb kann es vorteilhaft sein - selbst wenn man Community-Distributionen für Zuhause benutzt, auf solche zu setzen, hinter denen eine Firma steht, die entsprechende Ressourcen auch zur Verfügung stellen kann. Manch andere Distribution, die ein Hobbyprojekt mehrerer Entwickler ist, hat nicht die finanziellen Mittel solche Tests usw. auf die Beine zu stellen. (Edit: Die Stabilität der Funktion ist auch der Hauptgrund, warum ich selbst zu Hause Tumbleweed nutze, auch wenn manch andere Community-Distribution insgesamt mehr Pakete bietet.)
Zuletzt bearbeitet:
Das ist auch nicht die Message.
Die Message ist, dass OpenSource nicht sicherer ist, nur weil es offen ist. Dieser Mythos ist schlicht nicht haltbar. OpenSource lässt sich leichter nachvollziehen, hat dafür auch Angriffsmöglichkeiten, die Closed Software nicht hat.
Generell: Dogmen ("OSS ist immer besser da sicherer") sind fehl am Platz.
Kann man wie gesagt alles machen, vor allem, wenn halt nicht viel dranhängt. Aber manche Probleme treten oder fallen auch erst später auf, komplexe Produktionsumgebungen lassen sich leider nicht ohne weiteres komplett testen. Was da alles schiefgehen kann, lässt sich kaum vorhersagen. Meine Erfahrung ist, dass man selbst mit einem System wie Debian besser die Möglichkeit zur Rückabwicklung hat, wenn man upgraden will.
Ja, im Vergleich unter Rolling-Release-Distros mag das sein, wobei das meiste ja relativ schnell zurück in die eigentlich Paketquellen propagiert werden sollte und so auch in anderen Distros landen sollte. Ich denke aber auch, dass es ein bisschen zum Deal so einer Communityversion gehört, dass man auch ein bisschen Tester ist, was ich durchaus legitim finde, was man aber auch in die Wahl der Distro für einen bestimmten Zweck bedenken sollte.
Allgemein, je größer die Nutzerbasis ist, desto schneller werden Probleme erkannt und desto größer ist in der Regel auch die Maintenance, auch wenn sicher in ein paar Fällen auch umgekehrt ein Schuh draus wird. Auf jeden Fall sind größere Distros in der Regel stabiler und man sollte sich dem bewusst sein, wenn man etwas Exotischeres nutzen will.
Welche Angriffsmöglichkeiten meinst du?
Schnitzelnator
Software-Overclocker(in)
Ich sehe keine Angriffsmöglichkeit, die Closed Source Software nicht hat. Ich sehe nur die Unmöglichkeit, so eine Lücke wie hier bei Closed Source Software zu entdecken.
Denn genauso wie hier jemand eine Lücke in Open Source Code eingebaut hat, kann es gut sein, dass Security-Teams vieler Firmen bereits durch staatliche oder andere Agenten unterwandert sind. Man muss ja nur seine Leute auf die Stellen bewerben, die gut ausgebildet sind, und einen guten Eindruck machen und schon hat man nach wenigen Jahren seine V-Männer in den Firmen an den entsprechenden Stellen und kann da seine Lücken integrieren.
Das Kalkül von Open Source ist, dass selbst wenn jemand eine Lücke in den Quelltext bekommt, diese Lücke in kurzer Zeit auffällt. Und dieses Kalkül ist hier aufgegangen und hat dafür gesorgt, dass die Lücke so gut wie keinen Schaden anrichten konnte. Wie bereits geschrieben sollte man sich damit nicht zufrieden geben, denn es geht noch besser. Aber das ist im Gegensatz zu Closed Source Code eine massive Verbesserung.
Die gleiche Lücke in Closed Source Code könnte nur der Entwickler selbst entdecken, weil ohne Quelltext kaum ein anderer den Binärcode entziffern kann.
Das was passiert ist zeigt klar einen Angriffs-Vektor, den Closed Software nicht hat. Bei Closed SW kann sich keine unbekannte Person einfach als Maintainer einschleichen.
Hier hat man einfach unverschämtes Glück gehabt, sonst hätte OpenSource quasi dazu führen können, dass die gesamte IT der westlichen Welt in Geiselhaft hätte gemommen werden können.
Schnitzelnator
Software-Overclocker(in)
Es ist doch im Bezug auf den Angriffsvektor völlig egal, ob sich eine unbekannte Person 2 Jahre lang nett benimmt und dann böse wird, oder ob in Firmen eingeschleuste Mitarbeiter sich dumm stellen. Der Vektor ist beide Male der Gleiche.
In beiden Fällen ist es auf die gleiche Weise mit etwas Mühe und Geld möglich, durch V-Leute Lücken in den Code zu bekommen, aber nur bei Open Source Code ist die Wahrscheinlichkeit hoch, dass ein Unabhängiger sie schnell entdecken kann.
Edit: Und wenn jemand mit genug Personen die Lücken dort halten will, ist sogar die Unabhängigkeit eventuell die einzige Chance, dass die Lücken entdeckt werden können, weil vielleicht alle, die mit diesem Code betraut sind, die Lücken "übersehen" wollen...
Zuletzt bearbeitet:
Ähnliche Themen
