extrem relevant für alle Menschen, die das Internet benutzen! Diese Hintertür hätte SSH Zugriffe auf Server unsicher machen können, welche alle Server Admin benutzen um auf Server zuzugreifen. Wäre diese Lücke nicht (per Zufall) aufgefallen, hätte eine Gruppe von Hackern das ganze Internet ausspionieren oder manipulieren können.
diese Hintertür zeigt ein großes Problem des Internets auf: Einige EXTREM wichtige Bibliotheken werden von sehr wenigen Menschen gepflegt. In diesem Fall konnte die Hintertür eingebaut werden, weil ein einzelner Maintainer an Burn-Out litt und hilfe von einer, wie sich dann später herausstellte, nicht-vertrauenswürdigen Person (Jia Tan) bekam. Dies ist ein strukturelles Problem was mal angesprochen werden sollte.
der Fall ist einfach unglaublich spannend. Ist eigentlich schon Stoff für einen True-Crime Podcast. Aber wegen Punkte 1 und 2 halte ich es auch für einen Nachrichten-Podcast relevant.
Ich würde mich freuen, wenn dieses Thema in der Lage aufgegriffen wird.
Ich glaube, du übertreibst da.
Soweit ich das mitbekommen habe, war die Lücke nur in Beta-Versionen integriert.
Und darauf sollte man ein produktives System nicht laufen lassen.
Ja, die Realität sieht anders aus.
Aber statt hier ein Fass aufzumachen, sollte man vielleicht allgemein die Frage stellen, ob manche Bürger (und noch schlimmer: Netzwerkadministratoren) zu nachlässig sind, was Sicherheitsaspekte angeht.
Das ist nicht der relevante Punkt. Die Lücke wurde nur nicht übersehen (und mittelfristig in stabile Versionen integriert), weil ein Informafiker eher zufällig über kleinste Ungereimtheiten Zeit-Benchmarks stieß.
Das Problem ist, dass ein für unglaublich viel Software so elementares Projekt durch organisierte Akteure (mutmaßlich sogar staatlich) infiltriert und absichtlich mit einer Hintertür versehen werden konnte.
Ja, die gepatchte Software war „nur“ in einigen Testing-Distributionen. Aber wäre in einer solchen nicht aufgefallen, dass ein Login mit SSH in einer solchen Testumgebung etwas mehr CPU-Zyklen benötigt als vorher (wir reden hier von 500 Milisekunden), wäre das Paket über kurz oder lang auch in die Stable Versionen eingeflossen.
Der von @Dirksen verlinkte XKCD Comic beschreibt die Situation ganz gut. Viele Sachen unserer modernen Internetgesellschaft basieren auf Bausteinen, die vor Jahrzehnten mal hals Hobbyprojekt begonnen wurden und (zum Glück) ist das an den allermeisten Stellen bis heute gut gegangen. Es ist aber davon auszugehen, dass uns als Gesellschaft sowas irgendwann einmal komplett um die Ohren fliegen wird.
Es würde also zur Lage passen, in diesem Kontext noch einmal auf Projekte wie zb den Sovereign Tech Fund einzugehen.
Absolut. Und „Relevant“ ist hier fast noch untertrieben.
Sehe ich auch so, bis auf den staatlichen Akteur. Das ist zwar eine plausible Annahme, aber eine Ransomware-Gang hätte aus so einer Hintertür auch ein enormes Kapital schlagen können.
Das könnte natürlich passieren.
Was aber dagegen spricht, ist dass solche open source tools von sehr versierten Anwendern benutzt werden. Und da es sich um open source software handelt, können diese Anwender auch mal gucken was das Tool (hier xz), eigentlich genau macht. Das ginge bei closed source Software natürlich nicht.
Durch diese quasi „Emanzipation“ der Benutzer, reichte ein aufmerksamer Anwender aus, um ein Riesenproblem zu finden. Ich sehe darin einen Riesenvorteil von open source software.
Dem widerspreche ich. SSH benutzt man schon, wenn man zu Hause ne Nextcloud rumliegen hat. Es reichen also auch schon mäßig Interessierte.
Wichtig ist aber, dass diese „sehr versierten Anwender“ eben dieses Internet betreiben. Die gesamte Infrastruktur läuft auf Severn und der Zugang auf diese passiert eben über SSH. Man könnte also jeden Internetserver unter Kontrolle bringen.
Das ist der perfide an dieser Hintertür. Der Quellcode ist sicher. Niemand konnte durch das Überprüfen der Bibliothek auf Schadsoftware stoßen.
Die Lücke wurde in dem „Verpacken“ eingebaut. Das wäre vergleichbar mit, dass nur eine .exe den Schadcode enthält, aber nicht der Quellcode. Sicherheitsforscher weltweit versuchen diesen Angreifsmodus zu verstehen. Das ist ziemlich neu.
Daher besteht auch die Möglichkeit, dass noch viel mehr Pakete betroffen sind.
Das macht in der Praxis aber kein Developer. Wir verlassen uns auf die Reputation des Maintainers. Für ausführliche Checks außerhalb von tatsächlich auftretenden Problemen ist meist keine Zeit.
Das wäre auch gar nicht möglich. Denn (professionelle) Software besteht aus so vielen Abhängigkeiten, dass das kaum analysierbar ist und jede Abhängigkeit allein enthält zehntausende Zeilen Code.
Hier benötigt es ein anderes Mindset. Mehr kritisches Hinterfragen, langsamere Release Cycles, mehr Testing. Natürlich kostet das Geld oder erhöht die Dauer bis zum neuen Feature. Aber uns fällt die Geschwindigkeit sonst auf die Füße. Es würde auch keiner in ein Auto einsteigen, dessen Motor gerade gestern erst ganz neu entworfen wurde. Oder dessen Bremsen Prototypcharakter haben.
Aber bei Software ist es völlig selbstverständlich, dass wir bleading edge arbeiten.
Für diejenigen, die sich noch etwas mehr damit geschäftigen wollen, hier ist ein Link zur der Original-Mail, in der Andres Freud die Backdoor quasi gemeldet hat (plus anschließender Mail-Listen-Diskussion):
Und hier ist die Seite des Original-Maintainers, in der den aktuellen Stand des Projektes und ein bisschen seine Sicht auf die Geschehnisse beschreibt:
