Erstmal Danke, dass ihr über dieses Thema berichtet habt. Ich finde ihr habt ein bisschen einen falschen Fokus auf den Foss-Aspekt anstelle des Resourcen-Aspekts bei der Erklärung des Problems gelegt. Im Endeffekt habt ihr die richtigen Schlüsse gezogen, aber die Darstellung einiger Zusammenhänge scheint mir doch nicht ganz getroffen:
„Open-source software muss maintained werden, damit sie sicher ist“ → alle software muss maintained werden. Nur „sparen“ Unternehmen bei oss gerne Geld!
„Ein Krimineller konnte den Maintainer status erschleichen weil es ein Open source projekt war“ → er konnte sich den status erschleichen, weil niemand resourcen investiert hat, damit xz-utils sicher bleibt. Obwohl es, wie ihr richtig gesagt habt, überall verwendet wird.
„Der Staat muss Resourcen in Foss stecken, damit sowas nicht passiert“ → Ja, aber eben auch Unternehmen, die mit dieser software Milliardengewinne machen. Oft machen sie das sogar auch, aber eben noch nicht genug.
Zusammengefasst:
Sicherheit ist vorallem abhängig von der Pflege, nicht von der Softwarelizenz. Eine Foss Lizenz macht es
Unternehmen leichter, die Resourcen für Sicherheit zu vernachlässigen. Dem kann man entgegenwirken, indem Unternehmen auf ihr Sicherheitsinteresse und die nötigen Bedarfe hingewiesen werden.
Gerade diese kleinen Programme sind ein großes Problem.
Wenn man nun eine Software wie Openoffice nutzt, dann ist der Nutzen direkt vor der Nase und ein Spendenaufruf macht aus den Augen des Nutzers Sinn.
Ein kleines Programm, das nur eine Bibliothek zur Verfügung stellt oder im Hintergrund läuft, wird nicht wahr genommen und muss erstens viel mühevoller um Hilfe werben und fällt zweitens bei Unterstützungen meist hinten runter.
Das stimmt. MMn Müssten die Unternehmen, (z.B. Amazon, Google, Hetzner etc) Openssh soweit unterstützen, dass die dann auch ihre Abhängigkeiten im Auge haben können bzw. Dann im Kontakt diese Unternehmen darauf hinweisen, falls woanders Resourcen benötigt werden.
Habe ich das richtig verstanden, dass über die staatliche Förderung der Maintainer mit seiner eigenen Qualitätssicherung beuftragt wird oder er zumindest Mitspracherecht diesbezüglich erhält, wo genau der Schuh drückt und welcher Coder für die Umsetzung herangezogen werden sollte?
Im vorliegenden Fall hatte der gute Maintainer sich schon weitestgehend zurückgezogen und der böswillige Maintainer hatte schon ausreichend Vertrauen gewonnnen. In dieser Situation hätte das Programm also genau gar nichts gebracht und vermutlich noch insofern geschadet, als dass das Softwarepaket gewissermaßen noch ein Prüfsiegel bekommen hätte.
Ja. Da war das Kind schon in den Brunnen gefallen.
Ich kenne mich mit den genauen Abläufen nicht aus.
Aber der Maintainer soll sicher nicht herausgedrängt sondern unterstützt werden, vor allem finanziell.
Man kennt das ja.
Am Anfang geht man mit viel Enthusiasmus an ein Projekt ran. Je länger es geht, desto größer die Gefahr, dass jeder das Projekt nutzt und das immer mehr als Normalität hinnimmt, keiner dankt, aber sofort motzt, wenn etwas nicht funktioniert.
Geld kann hier helfen, dass der Einsatz zumindest symbolisch entlohnt wird, auch mal Verstärkung eingekauft werden kann.
Noch wichtiger ist natürlich Know-How und Manpower, am besten auch ehrenamtlich. Deren Intention kann man nur schwer herausfinden. Da muss man sich aufs Gefühl verlassen Und wenn da ein staatlicher Akteur auftritt, hat er quasi unbegrenzte Ressourcen. Es ist nicht das erste Mal dass ein Projekt unterwandert wurde und bestimmt nicht das letzte Mal.
Ich sehe hier auch wenig Schutzmöglichkeiten, außer regelmäßige Reviews des Codes - besonders in den Momenten vor dem Stable-Status.
Auch von meiner Seite aus vielen Dank für das Ansprechen des wirklich unterschätzten Themas. Was aber in meinen Augen etwas arg zu kurz kam, auch weil ich das in den Kommentaren vieler Nachrichtenartikel diverser Medien imho falsch/unzureichend dargestellt vernommen habe, und daher bitte wenn möglich noch in der nächsten Folge ergänzt wüsste:
Den ursprünglichen Maintainer von xz utils trifft keine Schuld (das Vorgehen dort war nach gängiger Erfahrung nicht anders als in anderen open source Projekten mit ähnlicher Ausgangslage)
Die Person bekam für dieses ‚kleine Hobby‘ kein! Geld und hat es vorwiegend allein gewuppt in seiner Freizeit, neben Hauptberuf und Familie (gerade dass dies keine Seltenheit in Open source Projekten ist, ist vielen Menschen leider nicht bewusst)
Der social engineering Angriff nutzte halt den in der Folge beschriebenen psychischen Druck (plus Die Tatsache dass der maintainer gemäß damaliger eigener Angaben bereits mit psychischen Problemen zu kämpfen hatte) und auch die daraus folgende Resignation aus (wer würde nicht einknicken, wenn viel gemeckert und gefordert wird, bei etwas dass man einst aus Leidenschaft an einer Problemlösung als Hobby begann, aber nun zur unnötigen Qual neben allen anderen Alltagspflichten [Beruf, Familie etc.] wird und man nicht mal finanziell entschädigt wird [um ggf. doch dadurch mehr Zeit dafür investieren zu können])
Der wichtige Punkt ist die Lehren die man daraus zieht wie dem Sovereign Tech Fund.
Die Software & Komponenten sind zwar OpenSource aber für Qualität und Sicherheit muss man dennoch Geld investieren.
Noch eine Ergänzung, wie genau die Sicherheitslücke erkannt wurde:
„Bei seinen Tests bemerkte er, dass der Login über SSH ungewöhnlich lange dauerte, nämlich eine dreiviertel Sekunde anstelle der üblichen Viertelsekunde.“
Mitnichten. Die halbe Sekunde hat der Programmierer nicht selbst „gespürt“ oder so, sondern sein Computer hat die gemessen.
Sowas ist einfach gründliches arbeiten. Computer sind Maschinen die nach naturwissenschaften Regeln funktionieren. Wenn ein Computer plötzlich länger für eine Aufgabe braucht als zuvor, dann hat das einen Grund. Während viele 0815-Arbeiter dann einfach mit den Schultern gezuckt hätten und gesagt hätten:„Naja, funktioniert ja immer noch“, hat Herr Freud die Ärmel hochgekrempelt und den Fehler gesucht.
Das einige hier bei sowas an Autismus denken, sagt eventuell mehr über ihr eigenes Arbeitsverständnis aus, als ihnen lieb ist.
Tue ich auch nicht. Aber eigentlich müsste man als Software-Entwickler viel gründlicher sein, als es die meisten (inklusive mir) normalerweise sind. Aber man hat eben häufig einfach keine Zeit und oft kann man auch nicht in die Quellen von dem sehen, was man so verwendet. Da sollten wir alle froh sein, dass es hier anders war.
Naja es hängt eben davon ab, was damit gemeint ist, dass die Verbindung länger dauerte. Wenn bei mir auf Client-Seite der SSH-Verbindungsaufbau zu einer Postgres-Datenbank eine halbe Sekunde länger dauern würde, würde ich auch erstmal Schwankungen in der Netzwerk-/Internetgeschwindigkeit vermuten und nicht gleich einen tieferen Programmierfehler. Das ist dann auch nicht automatisch ungründlich.
Viel wichtiger als die Diskussion über die Gründlichkeit einzelner EntwicklerInnen ist imho der folgende Aspekt (aus dem heise-Artikel):
Die Open-Source-Ideologie hat es über die Jahre und Jahrzehnte geschafft, den Wert unserer Zeit als Entwicklerinnen und Entwickler zu untergraben. Denn seien wir ehrlich: Für die meisten geht es bei Open Source nicht primär um den Zugang zum Quellcode, sondern um die Kostenfreiheit. Dass dabei Menschen wie Lasse Collin auf der Strecke bleiben können, wird als bedauerlicher, aber akzeptabler Kollateralschaden angesehen. Hauptsache, Open-Source-Software bleibt sowohl für die breite Masse als auch Unternehmen kostenfrei verfügbar…
Ehrlich gesagt wollte ich erst ähnliches auf @eis Autismus-Verdacht schreiben und ich halte ihn auch jetzt noch für unangebracht.
Allerdings habe ich meinen Beitragsentwurf dann wieder gelöscht weil ich an die Voraussetzungen zur Aktivierung der Backdoor denken musste.
Heise fasste die so zusammen
Üblicherweise nutze ich für solche Tests wie du sie beschreibst Profiler. Aber die sind ja durch die LD_PROFILE Variable außer Kraft gesetzt. Möglich, dass der Entdecker einen tic-toc Ansatz (nicht mit der chinesischen Plattform verwechseln) gewählt hat um seinen Code zu profilen, aber das würde nicht gerade für professionelle Arbeit stehen.
Hallo,
Ich würde gern die Genauigkeit der abgesprochenen Folgen diskutieren: So wie ich den Podcast verstanden habe, hätten die Hacker alle Rechner übernehmen können, die dieses Programm installiert haben. Mein Mann ist it Berater und führt an, dass die entsprechenden Rechner dazu aus dem Internet per ssh erreichbar sein müssten. Dies ist aus Sicherheitsgründen für kritische Infrastruktur nicht akzeptabel. Ergo hätte dieser Angriff nur solche Rechner betroffen, bei denen die Firmen eine sehr schlechte it Sicherheit haben (das könnten leider auch auf kritische Infrastruktur zutreffen, sollte aber die Ausnahme sein) und das wären dann vermehrt unwichtige Rechner. Im Podcast wurde der Eindruck vermittelt, dass ein globaler Blackout abgewendet werden konnte. Dies scheint deutlich übertrieben.
Erstens ist es nicht ungewöhnlich, den ssh Dienst für das Internet oder auch nur für bestimmte Bereiche davon freizugeben. Und zweitens gibt es auch immer die Gefahr des „lateral movements“ von Eindringlingen. Diese nutzen eine andere Schwachstelle in einem anderen System aus und bewegen sich dann lateral im Netz weiter. Hier wären die Systeme mit ssh ebenfalls leichte Ziele.
Außerdem ließe sich mit der Argumentation auch der Betrieb jeglicher Software, die vom Internet aus erreichbar gemacht wird, so abkanzeln. ssh ist weit verbreitet, gilt allgemein hin, so es denn korrekt konfiguriert ist, als sicheres Protokol. Natürlich muss man den Nutzen einer Erreichbarkeit aus dem Internet immer argumentieren.
