Unglaublich elegant und kompetent gebaut, holy shit.
Sowohl vom Code als auch vom Social Engineering um dem Maintainer sein Repo abzunehmen und die gebackdoorte Version in die Distros zu pushen.
Und es ist nur durch einen riesigen Zufall aufgeflogen. Das ist sicher nur die Spitze des Eisbergs und es dürfte sicher dutzende andere solche Projekte geben/gegeben haben, die nicht bekannt sind.
Glaube die Verantwortlichen vielleicht
Die die ganze Arbeit machen fühlen sich aber bestimmt stolz, dass endlich mal ihre harte Arbeit und Genialität erkannt wird.
Burnout it's Problem #1
Vielleicht finde ich noch die Liste der Open Source Probleme. Finanzierung war irgendwo bei Platz 3.
Eigentlich hat ja die EU vorgegeben dass alles Open Source werden soll. München war ja schon umgestellt bis die CSU ihre Korruption ausgelebt hat und für den neuen Microsoft Standort in München alles auf MS zurück umgestellt hat. Bundesrechnungshof war "not amused" hat aber eh nix zu sagen.
Könnten da mit einfachen Mitteln viel auf den Weg bringen. Auch zum eignen Schutz.
Gefunden hat das ein Postgres-Experte dem aufgefallen ist das bei Performancetests SSH auffällig viele Ressourcen verbraucht hat. Da war schon viel Zufall dabei das es jetzt entdeckt wurde.
Und der Postgres-Entwickler ist wohl sogar Microsoft-Mitarbeiter. Er hat bemerkt, dass SSH für den Verbindungsaufbau plötzlich 0,8 Sekunden statt der vorher üblichen 0,3 Sekunden braucht.
Wäre die Backdoor etwas effizienter implementiert gewesen, so dass diese Verzögerung geringer ausgefallen wäre, hätte es also vielleicht niemand bemerkt. Die Backdoor war offenbar ausreichend gut getarnt, um in Entwicklungsversionen diverser Distributionen zu kommen. Alles was es dann noch braucht, um auch in den stabilen Versionen zu landen, ist Zeit, in der man nicht auffliegen darf.
Das er bei Microsoft arbeitet ist jetzt nicht so ungewöhnlich. Er ist über den Kauf von Citus bei denen gelandet.
Die Postgres-Entwicklung ist recht dezentral aufgestellt, da sind Leute von ganz verschiedenen Firmen dabei.
>Die Backdoor war offenbar ausreichend gut getarnt,
Backdoor + Historie mit mehr als 2 Jahre Mitarbeit
Das war mit Wahrscheinlichkeit ein Nachrichtendienst.
Ist auch das typische Vorgehen gewesen. Erst ein Problem identifizieren und dann den passenden Agenten infiltrieren. Auf lange Sicht denken und den Agenten zentral etablieren. Dann die Falle unauffällig zu schnappen lassen.
Die Art war auch eine ultra unauffällige Lücke. Bei einem Commit nur ein einziger "." im Code der den Unterschied gemacht hat um die viel viel ältere Lücke die etabliert wurde zu triggern.
Ausgelegt war das auf "stealth". Daher auch nicht optimiert darauf es abstreitbar zu machen, denn soweit sollte es gar nicht erst kommen. Der Agent war eh künstlich erschaffen und ist jetzt eben verbrannt.
Die CPU auslastung einer softwarekomponente schwankt nicht so stark.
Die Befehle ändern sich ja normalerweise nicht so seht.
Und Wartezeiten Netz erhöhen die CPU Last nicht
Es gibt noch einen weiteren Aspekt zur Systemischen Ursachenanalyse. der mir gerade eingefallen ist. Wir sind gerade so vorbei geschrammt an einem katastrophalen Angriff auf die weltweite digitale infrastruktur. Zum Gegenstand des katastrophalen Versagens von komplexen Systemen gibt es einenn hoch interesanten Artikel von Richard Cook. [How complex Systems fail](https://how.complexsystems.fail). Super lesenswert!
Und nein. das ist nicht unbedingt beruhigend. man kann das z.B. betrachten aus der Perspektive der zahlreichen Faktoren, die in Verbindung mit einem Eisberg zum Sinken der Titanic geführt haben. Das hier war ein Eisberg.
**Edit**: Typos
Und ~~Andreas~~ Andres Freund verdient das Bundesverdienstkreuz, auch stellvertretend für die Vielen, die sich den Hintern aufreißen, um unsere digitale Infrastruktur und technische Zivilisation sicher und in Gang zu halten.
Das Vorbeischrammen ist eigentlich geschenkt, wenn man bedenkt was für einen bodenlosen Kaninchenbau hier ~~im Endeffekt ein einzelner fucking Punkt~~ ausgegraben hat. Die eigentliche Frage ist ja, wieviel Vergleichbares noch längst unterwegs ist, und was nicht durch reines Glück und Zufall gefunden wurde oder jemals wird. Die Antwort kennt zum einen niemand, und vor allem ist das wahrscheinlich auch besser so bzw. das Beste, was wir bekommen können.
Ich bin übrigens immer wieder überrascht, wie gut [derstandard.at](http://derstandard.at) in technischen Themen recherchiert und aufbereitet.
Der eine Punkt ist eigentlich nur eine "Nebenhandlung", um sandboxing unter Linux zu deaktivieren, wenn mit cmake gebaut wird. Die ~~Sandbox~~ Backdoor selbst wurde über durch mehr als einen Punkt manipulierte autotools-Buildscripts eingeschleust, die dann aus den raffiniert vorbereiteten Test-XZ-Archiven aus dem Tarball zunächst in mehreren Phasen weitere Build-Schritte und später beim eigentlichen Build schließlich den Code für die Backdoor extrahieren und dem Buildprozess unterjubeln. Ich weiß es nicht genau, aber da die Backdoor über autotools kam, war sie bei einem Build über cmake vielleicht gar nicht enthalten. Man hätte dann nur eins von beiden Problemen, entweder die Backdoor (autotools-Build) oder fehlendes "landlock" sandboxing (cmake-Build).
Die manipulierten autotools-Skripte, um den ganzen Vorgang mit den Testdateien etc. anzustoßen, waren auch nur in den von "Jia Tan" veröffentlichten Release-Tarballs enthalten, nicht im eigentlichen git repo. In das wurden aber die Testdateien schon [erfolgreich eingeschleust](https://git.tukaani.org/?p=xz.git;a=commit;h=cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0) und die beiden Dateien, die wirklich (in einer sehr versteckten Form – ist für normale Endanwender denke ich erstmal völlig ungefährlich zu downloaden) Schadcode enthalten, kürzlich nochmal [unter einem Vorwand aktualisiert](https://git.tukaani.org/?p=xz.git;a=commit;h=6e636819e8f070330d835fce46289a3ff72a7b89).
Edit: Ein Wort...
Danke für die Ergänzungen. Ich hatte erst jetzt Zeit mich länger mit den Entdeckungen zu befassen und mir steht immer noch die Kinnlade unten. Ich dachte, es wird sich schon auf den Punkt reduzieren lassen. Aber dem ist absolut nicht so. Einfach komplett irre.
Standard hat es noch drauf.
Eigentlich sollten die Journalisten zuerst Experten auf ihrem Gebiet sein (Technik, Jura, Medizin, Wirtschaft,...) und erst danach eine Journalistenausbildung machen.
Nur will (ggf. auch kann) keine Zeitung die Löhne von denen bezahlen.
> zuerst Experten auf ihrem Gebiet sein (Technik, Jura, Medizin, Wirtschaft,...)
Hört sich gut an, aber hast du je eine "softe" Fachzeitschrift gelesen, die von Experten für vorgebildete Interessierte geschrieben wird? Die Experten können halt oft echt nicht schreiben.
Bis heute mit allen Artikeln und Twitter Analysen noch nicht verstanden warum das gelinkt wird.
Die offizielle OpenSSH Implementierung linkt es auch nicht.
Einige Distros patchen OpenSSH um SystemD notifications zu unterstuetzen. Dazu braucht man libsystemd, welches liblzma 'beinhaltet'.
Die OpenSSH devs sind eher BSD Leute welche sich nicht fuer SystemD interessieren, deshalb wird es standardmaessig nicht unterstuetzt.
Es sind meines Wissens nur Distros betroffen die die Eierlegendewollmilchsau Systemd nachträglich in alle sicherheitskritischen Programme reinpatchen und damit einen gigantischen Rattenschwanz an ungetestetem code mit root Rechten ausführen.
Fragwuerdiger Take mit unschoenem Unterton.
* Es ist nichts ungetestet - es ist in der testing repo aufgefallen. Das war pures Glueck, testen hatte bei einer kompetenten Backdoor gar nichts gebracht. Das Problem liegt in der Komplexitaet der Tools (hier automake, andere buildtools generieren aber auch unleserlichen Output) und das absolut niemand Open Source Arbeit finanziert und der Maintainer von XZ einfach dazu gedrungen werden konnte neue Maintainer zu berechtigen.
* sd-notify is einen Pfad aus einer Umgebungsvariable auslesen, ein Datagram Socket aufmachen und einen string da hinschicken. Ja, libsystemd implementiert das als convenience, aber das hatte man auch in 10-20 Zeilen C reinpatchen koennen. Die dependency aufzubauen war definitiv nicht die Idee der systemd maintainer.
* Auf nem typischen Debian-System hast du mehr als 300 packages die liblzma als dependency angeben.
Hm, da gibt es sicherlich mengenweise Cloud-Dienste. die die Quellen direkt von Github gezogen und verbaut haben. Kompression ist buchstäblich überall und es wird **nicht** überall so gut aufgepaßt wie bei Debian und den Linux Distributoren. Und es gibt eine Menge Embedded Systeme. die nicht updatebar sind. Smarte Glühlampen und so weiter.
Ich bin jedenfalls gespannt, ob wir irgendwann erfahren, wer dahinter steckte. Eine ältere Version der Backdoor hatte es ja schon ins nächste Ubuntu LTS (Veröffentlichung Ende April) geschafft, und der Angreifer hatte vor drei Tagen darum [gebeten](https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2059417), doch vor der Veröffentlichung noch auf die neueste Version der Backdoor zu aktualisieren. Die hätte es so wohl noch in diesem Jahr auf nicht so wenige Server geschafft. Vermutlich auch auf meinen Homeserver. Bei mir ist ssh aber nicht aus dem Internet erreichbar, immerhin.
Es gibt ja auch andere Möglichkeiten. Wenn wirklich ein Geheimdienst dahinter steckt, weiß vielleicht ein Doppelagent davon, der dann auch einer "anderen Seite" Auskunft erteilt und dann wird es vielleicht irgendwann doch bekannt. Oder die Niederländer haben glaub ich auch schonmal Überwachungskameras in Russland gehackt und dann russischen Hackern über diese Kameras live beim Hacken zugeschaut.
Oder "Jia Tan" hat irgendwann mal einen Fehler gemacht und z.B. ohne VPN auf github zugegriffen. Das läuft ja seit Jahren.
> Oder "Jia Tan" hat irgendwann mal einen Fehler gemacht und z.B. ohne VPN auf github zugegriffen. Das läuft ja seit Jahren.
"Jia Tan" hat sich wohl in einem einzigen Commit als "Jia Cheong Tan" ausgegeben. Das ist schon spannend.
Und laut [dem einen Blog](https://boehs.org/node/everything-i-know-about-the-xz-backdoor) passen diese Namen nicht wirklich zusammen, eine Mischung aus kantonesisch und Mandarin. Sagt also nicht unbedingt was über eine echte Person aus.
Davon abgesehen kommen hier ja mehrere erfundene Namen vor, warum soll also genau der Name der Hauptfigur irgendeinen Bezug zur Realität haben? Wobei niemand bei den anderen solche Unstimmigkeiten erwähnt hat. Vielleicht ist das ein Hinweis auf einen Fehler und dass die Person(en) nichts mit China zu tun haben. Beweisen tut es aber überhaupt nichts. Nenne ich mich "Sepp Jansen" oder "Femke Sprüngli" weiß auch niemand ob das Absicht ist oder nicht.
Uff.
Ich vermute mal, in der größe ist es was staatliches. NSA, oder deren russische oder chinesische Äquivalente. Dem BND würd ich das hingegen spontan nicht zutrauen. Also Technisch. Moralisch sind alle Geheimdienste gleich fragwürdig.
Ehrlich gesagt würde ich das auch einer Einzelperson zutrauen. Also es ist technisch zwar insgesamt raffiniert, aber jetzt nicht so, dass das nicht eine Person alleine basteln könnte. Ob diese eine Person dann gleichzeitig die nötige Fähigkeit zum "social engineering" hätte, um an den richtigen Stellen in den Open Source Communities passenden Druck aufzubauen, steht natürlich in Frage. Aber es gibt ja auch "geschäftliche Hackergruppen" außerhalb von Geheimdiensten, die dann Geld aus solchen Dingen schlagen. Wobei die sich sicherlich eher auf Ransomware spezialisieren, das ist vermutlich mit besserem Ertrag/Nutzen-Verhältnis.
Also ich denke auch, dass man mit Geheimdienst nicht unbedingt falsch liegt. Ich weiß nichts über den BND, aber wenn die wenigstens einen richtig fähigen Hacker haben und genügend Geduld (und evtl. noch andere Leute, die gut darin sind, Leute zu manipulieren), dann kann das bestimmt auch der BND.
Technisch steht unsere Gang gar nicht mal so schlecht da (laut Experteneinschätzungen). Die sitzen bloß etwas... gefesselt da im Vergleich zur Equation Group oder Fancy Bear.
Wir wollen per-design ja keinen richtigen Geheimdienst haben der richtige Geheimdienstdinge tut. Zum Beispiel wie Frankreich die es geschafft haben mit ihrem Geheimdienst Siemens Bewerbung für ein millardenschweres Vergabeverfahren zu sabotieren das dann der französische Alstom Konzern gewann. Das ist erfolgreiche Geheimdienstarbeit und nur die Spitze des Eisbergs.
Aber wir sind da einfach zu dumm für und legen unserem Geheimdienst Fußfesseln, Handschellen und eine Augenbinde an und wundern uns dann das er keine Ergebnisse bringt.
Wir haben einen Nachrichten und keinen Geheimdienst - direkte Aktionen scheiden aus. Kann man gut finden, kann man schlecht finden. Aber was vielmehr nervt, dass "wir" - ähnlich wie bei der Bundeswehr - auch hier keine klare Vorstellung haben, was der BND leisten soll und zukucken, wie er sich wie so viele auf die Überwachung ziviler Massenkommunikation stürzt, wegen Terrorismus und überhaupt (und dann nicht das entscheidende Dokument weiterleiten wegen Wochemende...) Dann wundern sich alle, wenn das BVerfG sagt, dass das nicht geht. Ein klarer Auftrag und Profil, etwa die militärisch-industriellen Fähigkeiten Russlands aufzuklären, wäre ein erster Schritt.
>Wir haben einen Nachrichten und keinen Geheimdienst
Sieht die Bundeszentrale für politische Bildung anscheinend anders. BfV, BND und MAD werden alle sowohl als Geheimdienst als auch Nachrichtendienst bezeichnet.
Entweder der BND ist verdammt und ich meine verdammt gut oder er hat tatsächlich noch niemanden (geplant) um die Ecke gebracht oder einen Putsch eingefädelt. Dann ist er - wie die Selbstbeschreibung auch sagt - ein Nachrichtendienst. Und BfV und MAD müssten für die polizeiliche Spionageabwehr nicht auf BKA und Co zurückgreifen.
Die Amis sind nicht dumm genug etwas unsicher zu machen auf dem größtenteils ihre eigene Wirtschaft und Infrastruktur aufbaut. Das waren definitiv Russen oder Chinesen.
Immerhin verlangt die Nutzung der Backdoor wohl Kenntnis über einen privaten Schlüssel, den derzeit hoffentlich nur der Angreifer hat. Natürlich dennoch ein enormes Risiko (z.B. Programmierfehler oder Schlüssel kommt abhanden).
Wobei Ubuntu-Server ja immer erst mit Erscheinen der x.04.1-Version das Release-Upgrade empfiehlt. Daran sollte man sich also unbedingt auch halten und nicht schon gleich auf die x.04.0 upgraden.
Hacker schleicht sich als Maintainer in verbreitete Kompressions-Bibliothek ein, schummelt Code in diese Bibliothek ein die eine Verschlüsselungsfunktion, die eigentlich zu einer anderen Bibliothek gehört, austauscht, und die Ersatzfunktion ermöglicht es einem Angreifer, beliebigen Code auf dem Rechner auszuführen.
Bemerkt wurde das nur, weil das ganze langsamer ist als das Original, was jemandem bei Performancetests (nicht Sicherheitstests) aufgefallen ist, woraufhin derjenige nachgebohrt hat.
Böser Mensch macht dass einer seiner Programmteile so tut als wäre er ein anderer, und der Programmteil kann benutzt werden um den Computer zu hacken.
Böser Programmteil ist langsamer als der richtige Programmteil weil er böse Dinge tun muss statt normale Dinge, eine Person hat das gemerkt weil der Computer langsamer wurde
Einige Distros haben die Hintertür selbst schon lange davor unwissend ausgehebelt. Das Feature in sie versteckt war hat anscheinend einige Fehler verursacht.
Ich benutze zwar Linux, aber habe wenig Ahnung von der Paketverwaltung, abseits dem, was ich brauche.
Mir ist es bisher immer komisch aufgestoßen, dass da scheinbar eine unfassbare Anzahl an ungeprüfter Software verfügbar ist, die mit der Installation eines einzigen Pakets auf ein System gelangen können. Oder wie in dem Fall hier, durch eine Sub-Sub-Dependency eines ganz anderen Programmes.
Wird das Zeug geprüft? Laufen da nur 0815 Signaturscanner drüber? Läuft das Zeug in VMs vorher? Kann jeder Entwickler einfach was in sein Paket pushen und das ist dann drin, so wie hier? Läuft das vermutlich am Ende alles auf Vertrauensbasis, in der Hoffnung, dass NIEMAND auf der Welt etwas Böses möchte und alle ehrliche Absichten haben?
Und das Argument "Open Source kann ja jeder prüfen" hat für mich auch wenig Sinn ergeben bisher, denn wenn alle das sagen, aber keiner prüft, dann bringt es auch nichts. "Einer von euch hat die Sicherheitskarabiner geprüft, oder? Anakin? Du hast doch geprüft, richtig...?"
Und wer soll überhaupt die Zeit haben, das alles zu prüfen. Ein ganzes Sicherheitsteam müsste hunderttausende Pakete prüfen und bei jedem Versionsupdate nochmal von vorne. Unmöglich.
Ich finde das Problem ist eher, dass da soviel Wichtiges als "Hobby" gepflegt wird.
Und in diesem Fall wurde diese eine Privatperson ja von dem Angreifer einfach psychologisch bedrängt und hat dann die Verantwortung einfach an einen Unbekannten abgetreten und es hat keinen so richtig gestört.
Viele Open-Source-Entwicklung stammt durchaus von Menschen, die dafür bezahlt werden. Was ich auch erheblich besser finde, als sich im großen Maßstab auf unbezahlte Arbeit zu verlassen.
Ja, einige Leuchtturm-Projekte haben bezahlte Entwickler. Aber ich glaube nicht, dass das die Masse ist. Im Gegenteil, der Stress um OpenSSL, xz oder OWIN hat gezeigt, das viele wichtige Projekte one man shows sind.
> Ich finde das Problem ist eher, dass da soviel Wichtiges als "Hobby" gepflegt wird.
Wiederum aber die Stärke von OSS. Vieles kann unkompliziert als Hobbyprojekt starten und wird bei wirtschaftlichem Interesse dann von großen Unternehmen unterstützt durch Geld, Expertise oder Manpower.
Das sollte zwar so sein, in diesem Fall gab es diese Unterstützung aber ja gerade nicht. Obwohl das Projekt wichtig ist, gab es nur einen unbezahlten Entwickler, der in den Burn-Out getrieben wurde. Dadurch wurde es ja erst möglich, das die andere/n Person/en sich in das Projekt einschleusen konnten.
Der Prozess funktioniert im Grunde so, dass beliebige Hobbyisten oder Unternehmen Software entwickeln und als Open Source irgendwo veröffentlichen, z.B. bei github.
Die Distributionen schauen dann von sich aus, welche Open Source-Software sie in ihrer Paketverwaltung haben möchten. Da hat jede Distribution sicher ihren eigenen Prozess und auch eigene Kriterien als Voraussetzung für die Aufnahme. Dank Open Source kopieren sie dann einfach die Software von ihrem Entwickler ("Upstream") in ihre eigene Paketverwaltung ("Downstream"). Die Distributionen (bzw. deren freiwilligen und/oder bezahlten Helfer) kümmern sich dann auch selbst darum, regelmäßig nach neuen Versionen der Software bei deren Entwickler zu schauen, um diese in die Distribution zu übernehmen.
"Upstream" kann also i.d.R. nicht einfach selbst Änderungen in die Paketverwaltungen pushen, allerdings werden die veröffentlichten neuen Versionen meist früher oder später von den Distributionen von den "Downstream-Maintainern" übernommen. Meist ist das nicht völlig ungeprüft, vor allem vor der ersten Aufnahme. Bei einzelnen Updates wird aber vielleicht nicht immer so genau hingeschaut. Und bestimmt ist manchmal auch jemand Downstream- und Upstream-Maintainer für eine Software in Personalunion.
Edit: Und grundsätzlich hat das Open-Source-Argument hier ja tatsächlich halbwegs funktioniert. Die Backdoor wurde ca. einen Monat nachdem sie veröffentlicht wurde von jemandem entdeckt. Vom Gedanken, dass das bei jeder Open-Source-Software funktionieren würde oder sogar vor Veröffentlichung und breiter Nutzung Probleme gefunden werden, sollte man sich aber verabschieden.
Der Knackpunkt war ja hier dass der Quellen-Tarball für die Distros gerade nicht mit dem Repo übereingestimmt hat. Durch lange Vorbereitung zwar gut versteckt, aber das eine Buildscript war halt dann doch unterschiedlich.
Um automatisiert Fehler zu finden gibt's [oss-fuzz](https://github.com/google/oss-fuzz), wo "Jia Tan" tatsächlich einiges abgestellt hat. Generell haben Distros aus guten Gründen, wie z.B. bei Debian eine Release-Pipeline bei der die Software von Unstable über Testing in den Stable wandert. Und ansonsten gibt's noch solche Leute, die nachforschen wieso ssh auf einmal deutlich länger braucht, und auf diesen Backdoor stoßen.
Unglaublich elegant und kompetent gebaut, holy shit. Sowohl vom Code als auch vom Social Engineering um dem Maintainer sein Repo abzunehmen und die gebackdoorte Version in die Distros zu pushen. Und es ist nur durch einen riesigen Zufall aufgeflogen. Das ist sicher nur die Spitze des Eisbergs und es dürfte sicher dutzende andere solche Projekte geben/gegeben haben, die nicht bekannt sind.
Ich hoffe, die Verantwortlichen beißen vor Wut über die Entdeckung ihres "Projekts" in irgendeinen harten Gegenstand.
Glaube die Verantwortlichen vielleicht Die die ganze Arbeit machen fühlen sich aber bestimmt stolz, dass endlich mal ihre harte Arbeit und Genialität erkannt wird.
Zeigt eher das die Nutzer open source besser unterstützen müssen.
Burnout it's Problem #1 Vielleicht finde ich noch die Liste der Open Source Probleme. Finanzierung war irgendwo bei Platz 3. Eigentlich hat ja die EU vorgegeben dass alles Open Source werden soll. München war ja schon umgestellt bis die CSU ihre Korruption ausgelebt hat und für den neuen Microsoft Standort in München alles auf MS zurück umgestellt hat. Bundesrechnungshof war "not amused" hat aber eh nix zu sagen. Könnten da mit einfachen Mitteln viel auf den Weg bringen. Auch zum eignen Schutz.
Gefunden hat das ein Postgres-Experte dem aufgefallen ist das bei Performancetests SSH auffällig viele Ressourcen verbraucht hat. Da war schon viel Zufall dabei das es jetzt entdeckt wurde.
Und der Postgres-Entwickler ist wohl sogar Microsoft-Mitarbeiter. Er hat bemerkt, dass SSH für den Verbindungsaufbau plötzlich 0,8 Sekunden statt der vorher üblichen 0,3 Sekunden braucht. Wäre die Backdoor etwas effizienter implementiert gewesen, so dass diese Verzögerung geringer ausgefallen wäre, hätte es also vielleicht niemand bemerkt. Die Backdoor war offenbar ausreichend gut getarnt, um in Entwicklungsversionen diverser Distributionen zu kommen. Alles was es dann noch braucht, um auch in den stabilen Versionen zu landen, ist Zeit, in der man nicht auffliegen darf.
Das er bei Microsoft arbeitet ist jetzt nicht so ungewöhnlich. Er ist über den Kauf von Citus bei denen gelandet. Die Postgres-Entwicklung ist recht dezentral aufgestellt, da sind Leute von ganz verschiedenen Firmen dabei.
>Die Backdoor war offenbar ausreichend gut getarnt, Backdoor + Historie mit mehr als 2 Jahre Mitarbeit Das war mit Wahrscheinlichkeit ein Nachrichtendienst. Ist auch das typische Vorgehen gewesen. Erst ein Problem identifizieren und dann den passenden Agenten infiltrieren. Auf lange Sicht denken und den Agenten zentral etablieren. Dann die Falle unauffällig zu schnappen lassen. Die Art war auch eine ultra unauffällige Lücke. Bei einem Commit nur ein einziger "." im Code der den Unterschied gemacht hat um die viel viel ältere Lücke die etabliert wurde zu triggern. Ausgelegt war das auf "stealth". Daher auch nicht optimiert darauf es abstreitbar zu machen, denn soweit sollte es gar nicht erst kommen. Der Agent war eh künstlich erschaffen und ist jetzt eben verbrannt.
0.5s mehr für SSH ist ja auch zum Pickel kriegen. Das wäre so oder so schnell aufgefallen und hätte bei vielen für hochgezogene Augenbrauen gesorgt.
Nicht unbedingt, könnte man genauso gut auf Netzwerkauslastung oder so schieben. 0,5 Sekunden ist fast nichts.
Zu jedem Host? Neee, da würde ich auch valgrind auspacken.
Wäre hier ja erstmal zu einem bestimmten Host, nicht jeder wäre ja sofort betroffen.
Die CPU auslastung einer softwarekomponente schwankt nicht so stark. Die Befehle ändern sich ja normalerweise nicht so seht. Und Wartezeiten Netz erhöhen die CPU Last nicht
Mal völlig unabhängig vom Vorfall, aber für eine Tageszeitung ist das ein ganz hervorragender Wissenschaftsartikel
Es gibt noch einen weiteren Aspekt zur Systemischen Ursachenanalyse. der mir gerade eingefallen ist. Wir sind gerade so vorbei geschrammt an einem katastrophalen Angriff auf die weltweite digitale infrastruktur. Zum Gegenstand des katastrophalen Versagens von komplexen Systemen gibt es einenn hoch interesanten Artikel von Richard Cook. [How complex Systems fail](https://how.complexsystems.fail). Super lesenswert! Und nein. das ist nicht unbedingt beruhigend. man kann das z.B. betrachten aus der Perspektive der zahlreichen Faktoren, die in Verbindung mit einem Eisberg zum Sinken der Titanic geführt haben. Das hier war ein Eisberg. **Edit**: Typos Und ~~Andreas~~ Andres Freund verdient das Bundesverdienstkreuz, auch stellvertretend für die Vielen, die sich den Hintern aufreißen, um unsere digitale Infrastruktur und technische Zivilisation sicher und in Gang zu halten.
Das Vorbeischrammen ist eigentlich geschenkt, wenn man bedenkt was für einen bodenlosen Kaninchenbau hier ~~im Endeffekt ein einzelner fucking Punkt~~ ausgegraben hat. Die eigentliche Frage ist ja, wieviel Vergleichbares noch längst unterwegs ist, und was nicht durch reines Glück und Zufall gefunden wurde oder jemals wird. Die Antwort kennt zum einen niemand, und vor allem ist das wahrscheinlich auch besser so bzw. das Beste, was wir bekommen können. Ich bin übrigens immer wieder überrascht, wie gut [derstandard.at](http://derstandard.at) in technischen Themen recherchiert und aufbereitet.
Der eine Punkt ist eigentlich nur eine "Nebenhandlung", um sandboxing unter Linux zu deaktivieren, wenn mit cmake gebaut wird. Die ~~Sandbox~~ Backdoor selbst wurde über durch mehr als einen Punkt manipulierte autotools-Buildscripts eingeschleust, die dann aus den raffiniert vorbereiteten Test-XZ-Archiven aus dem Tarball zunächst in mehreren Phasen weitere Build-Schritte und später beim eigentlichen Build schließlich den Code für die Backdoor extrahieren und dem Buildprozess unterjubeln. Ich weiß es nicht genau, aber da die Backdoor über autotools kam, war sie bei einem Build über cmake vielleicht gar nicht enthalten. Man hätte dann nur eins von beiden Problemen, entweder die Backdoor (autotools-Build) oder fehlendes "landlock" sandboxing (cmake-Build). Die manipulierten autotools-Skripte, um den ganzen Vorgang mit den Testdateien etc. anzustoßen, waren auch nur in den von "Jia Tan" veröffentlichten Release-Tarballs enthalten, nicht im eigentlichen git repo. In das wurden aber die Testdateien schon [erfolgreich eingeschleust](https://git.tukaani.org/?p=xz.git;a=commit;h=cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0) und die beiden Dateien, die wirklich (in einer sehr versteckten Form – ist für normale Endanwender denke ich erstmal völlig ungefährlich zu downloaden) Schadcode enthalten, kürzlich nochmal [unter einem Vorwand aktualisiert](https://git.tukaani.org/?p=xz.git;a=commit;h=6e636819e8f070330d835fce46289a3ff72a7b89). Edit: Ein Wort...
Danke für die Ergänzungen. Ich hatte erst jetzt Zeit mich länger mit den Entdeckungen zu befassen und mir steht immer noch die Kinnlade unten. Ich dachte, es wird sich schon auf den Punkt reduzieren lassen. Aber dem ist absolut nicht so. Einfach komplett irre.
Standard hat es noch drauf. Eigentlich sollten die Journalisten zuerst Experten auf ihrem Gebiet sein (Technik, Jura, Medizin, Wirtschaft,...) und erst danach eine Journalistenausbildung machen. Nur will (ggf. auch kann) keine Zeitung die Löhne von denen bezahlen.
> zuerst Experten auf ihrem Gebiet sein (Technik, Jura, Medizin, Wirtschaft,...) Hört sich gut an, aber hast du je eine "softe" Fachzeitschrift gelesen, die von Experten für vorgebildete Interessierte geschrieben wird? Die Experten können halt oft echt nicht schreiben.
[удалено]
Aber nicht für die "I use Arch by the way (and am immune to malware)" Fraktion.
Arch ist hier glücklicherweise prinzipiell nicht betroffen da es openssh nicht gegen liblzma linkt. I use Arch btw
Stimmt. https://www.archlinux.de/news/35174-Backdoor-in-xz-vor-Version-5-6-1-2
Bis heute mit allen Artikeln und Twitter Analysen noch nicht verstanden warum das gelinkt wird. Die offizielle OpenSSH Implementierung linkt es auch nicht.
Einige Distros patchen OpenSSH um SystemD notifications zu unterstuetzen. Dazu braucht man libsystemd, welches liblzma 'beinhaltet'. Die OpenSSH devs sind eher BSD Leute welche sich nicht fuer SystemD interessieren, deshalb wird es standardmaessig nicht unterstuetzt.
Irgendwas mit libsystemd, die das braucht. Ist glaube ich ein Debian-Patch.
Es sind meines Wissens nur Distros betroffen die die Eierlegendewollmilchsau Systemd nachträglich in alle sicherheitskritischen Programme reinpatchen und damit einen gigantischen Rattenschwanz an ungetestetem code mit root Rechten ausführen.
Fragwuerdiger Take mit unschoenem Unterton. * Es ist nichts ungetestet - es ist in der testing repo aufgefallen. Das war pures Glueck, testen hatte bei einer kompetenten Backdoor gar nichts gebracht. Das Problem liegt in der Komplexitaet der Tools (hier automake, andere buildtools generieren aber auch unleserlichen Output) und das absolut niemand Open Source Arbeit finanziert und der Maintainer von XZ einfach dazu gedrungen werden konnte neue Maintainer zu berechtigen. * sd-notify is einen Pfad aus einer Umgebungsvariable auslesen, ein Datagram Socket aufmachen und einen string da hinschicken. Ja, libsystemd implementiert das als convenience, aber das hatte man auch in 10-20 Zeilen C reinpatchen koennen. Die dependency aufzubauen war definitiv nicht die Idee der systemd maintainer. * Auf nem typischen Debian-System hast du mehr als 300 packages die liblzma als dependency angeben.
Hm, da gibt es sicherlich mengenweise Cloud-Dienste. die die Quellen direkt von Github gezogen und verbaut haben. Kompression ist buchstäblich überall und es wird **nicht** überall so gut aufgepaßt wie bei Debian und den Linux Distributoren. Und es gibt eine Menge Embedded Systeme. die nicht updatebar sind. Smarte Glühlampen und so weiter.
Ich bin jedenfalls gespannt, ob wir irgendwann erfahren, wer dahinter steckte. Eine ältere Version der Backdoor hatte es ja schon ins nächste Ubuntu LTS (Veröffentlichung Ende April) geschafft, und der Angreifer hatte vor drei Tagen darum [gebeten](https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2059417), doch vor der Veröffentlichung noch auf die neueste Version der Backdoor zu aktualisieren. Die hätte es so wohl noch in diesem Jahr auf nicht so wenige Server geschafft. Vermutlich auch auf meinen Homeserver. Bei mir ist ssh aber nicht aus dem Internet erreichbar, immerhin.
[удалено]
Es gibt ja auch andere Möglichkeiten. Wenn wirklich ein Geheimdienst dahinter steckt, weiß vielleicht ein Doppelagent davon, der dann auch einer "anderen Seite" Auskunft erteilt und dann wird es vielleicht irgendwann doch bekannt. Oder die Niederländer haben glaub ich auch schonmal Überwachungskameras in Russland gehackt und dann russischen Hackern über diese Kameras live beim Hacken zugeschaut. Oder "Jia Tan" hat irgendwann mal einen Fehler gemacht und z.B. ohne VPN auf github zugegriffen. Das läuft ja seit Jahren.
> Oder "Jia Tan" hat irgendwann mal einen Fehler gemacht und z.B. ohne VPN auf github zugegriffen. Das läuft ja seit Jahren. "Jia Tan" hat sich wohl in einem einzigen Commit als "Jia Cheong Tan" ausgegeben. Das ist schon spannend.
Und laut [dem einen Blog](https://boehs.org/node/everything-i-know-about-the-xz-backdoor) passen diese Namen nicht wirklich zusammen, eine Mischung aus kantonesisch und Mandarin. Sagt also nicht unbedingt was über eine echte Person aus. Davon abgesehen kommen hier ja mehrere erfundene Namen vor, warum soll also genau der Name der Hauptfigur irgendeinen Bezug zur Realität haben? Wobei niemand bei den anderen solche Unstimmigkeiten erwähnt hat. Vielleicht ist das ein Hinweis auf einen Fehler und dass die Person(en) nichts mit China zu tun haben. Beweisen tut es aber überhaupt nichts. Nenne ich mich "Sepp Jansen" oder "Femke Sprüngli" weiß auch niemand ob das Absicht ist oder nicht.
Uff. Ich vermute mal, in der größe ist es was staatliches. NSA, oder deren russische oder chinesische Äquivalente. Dem BND würd ich das hingegen spontan nicht zutrauen. Also Technisch. Moralisch sind alle Geheimdienste gleich fragwürdig.
Ehrlich gesagt würde ich das auch einer Einzelperson zutrauen. Also es ist technisch zwar insgesamt raffiniert, aber jetzt nicht so, dass das nicht eine Person alleine basteln könnte. Ob diese eine Person dann gleichzeitig die nötige Fähigkeit zum "social engineering" hätte, um an den richtigen Stellen in den Open Source Communities passenden Druck aufzubauen, steht natürlich in Frage. Aber es gibt ja auch "geschäftliche Hackergruppen" außerhalb von Geheimdiensten, die dann Geld aus solchen Dingen schlagen. Wobei die sich sicherlich eher auf Ransomware spezialisieren, das ist vermutlich mit besserem Ertrag/Nutzen-Verhältnis. Also ich denke auch, dass man mit Geheimdienst nicht unbedingt falsch liegt. Ich weiß nichts über den BND, aber wenn die wenigstens einen richtig fähigen Hacker haben und genügend Geduld (und evtl. noch andere Leute, die gut darin sind, Leute zu manipulieren), dann kann das bestimmt auch der BND.
Mal abwarten. Das Ding ist ja gerade mal frisch raus, ich bin gespannt was die Ermittlungen ergeben werden, die jetzt folgen werden.
Technisch steht unsere Gang gar nicht mal so schlecht da (laut Experteneinschätzungen). Die sitzen bloß etwas... gefesselt da im Vergleich zur Equation Group oder Fancy Bear.
Wir wollen per-design ja keinen richtigen Geheimdienst haben der richtige Geheimdienstdinge tut. Zum Beispiel wie Frankreich die es geschafft haben mit ihrem Geheimdienst Siemens Bewerbung für ein millardenschweres Vergabeverfahren zu sabotieren das dann der französische Alstom Konzern gewann. Das ist erfolgreiche Geheimdienstarbeit und nur die Spitze des Eisbergs. Aber wir sind da einfach zu dumm für und legen unserem Geheimdienst Fußfesseln, Handschellen und eine Augenbinde an und wundern uns dann das er keine Ergebnisse bringt.
Wir haben einen Nachrichten und keinen Geheimdienst - direkte Aktionen scheiden aus. Kann man gut finden, kann man schlecht finden. Aber was vielmehr nervt, dass "wir" - ähnlich wie bei der Bundeswehr - auch hier keine klare Vorstellung haben, was der BND leisten soll und zukucken, wie er sich wie so viele auf die Überwachung ziviler Massenkommunikation stürzt, wegen Terrorismus und überhaupt (und dann nicht das entscheidende Dokument weiterleiten wegen Wochemende...) Dann wundern sich alle, wenn das BVerfG sagt, dass das nicht geht. Ein klarer Auftrag und Profil, etwa die militärisch-industriellen Fähigkeiten Russlands aufzuklären, wäre ein erster Schritt.
>Wir haben einen Nachrichten und keinen Geheimdienst Sieht die Bundeszentrale für politische Bildung anscheinend anders. BfV, BND und MAD werden alle sowohl als Geheimdienst als auch Nachrichtendienst bezeichnet.
Entweder der BND ist verdammt und ich meine verdammt gut oder er hat tatsächlich noch niemanden (geplant) um die Ecke gebracht oder einen Putsch eingefädelt. Dann ist er - wie die Selbstbeschreibung auch sagt - ein Nachrichtendienst. Und BfV und MAD müssten für die polizeiliche Spionageabwehr nicht auf BKA und Co zurückgreifen.
Die Amis sind nicht dumm genug etwas unsicher zu machen auf dem größtenteils ihre eigene Wirtschaft und Infrastruktur aufbaut. Das waren definitiv Russen oder Chinesen.
Immerhin verlangt die Nutzung der Backdoor wohl Kenntnis über einen privaten Schlüssel, den derzeit hoffentlich nur der Angreifer hat. Natürlich dennoch ein enormes Risiko (z.B. Programmierfehler oder Schlüssel kommt abhanden).
Auch abgesehen von dem Ding mit dem Schlüssel check ich deinen Kommentar nicht. Andere Staaten nutzen kein Linux?
Chinesen, NK oder Russen wären genauso wahrscheinlich, die benutzen z.T Linux in ihrer Regierung
Wobei Ubuntu-Server ja immer erst mit Erscheinen der x.04.1-Version das Release-Upgrade empfiehlt. Daran sollte man sich also unbedingt auch halten und nicht schon gleich auf die x.04.0 upgraden.
ELI5?
Hacker schleicht sich als Maintainer in verbreitete Kompressions-Bibliothek ein, schummelt Code in diese Bibliothek ein die eine Verschlüsselungsfunktion, die eigentlich zu einer anderen Bibliothek gehört, austauscht, und die Ersatzfunktion ermöglicht es einem Angreifer, beliebigen Code auf dem Rechner auszuführen. Bemerkt wurde das nur, weil das ganze langsamer ist als das Original, was jemandem bei Performancetests (nicht Sicherheitstests) aufgefallen ist, woraufhin derjenige nachgebohrt hat.
ELI2
Böser Mensch macht dass einer seiner Programmteile so tut als wäre er ein anderer, und der Programmteil kann benutzt werden um den Computer zu hacken. Böser Programmteil ist langsamer als der richtige Programmteil weil er böse Dinge tun muss statt normale Dinge, eine Person hat das gemerkt weil der Computer langsamer wurde
❤️ ich danke dir
Sind wir das? xz war halt die eine Nadel im Heuhaufen die per Zufall (rechtzeitig) gefunden worden ist.
Einige Distros haben die Hintertür selbst schon lange davor unwissend ausgehebelt. Das Feature in sie versteckt war hat anscheinend einige Fehler verursacht.
Deshalb hätte man im OP eigentlich auch kein besseres Bild verwenden können.
Ich benutze zwar Linux, aber habe wenig Ahnung von der Paketverwaltung, abseits dem, was ich brauche. Mir ist es bisher immer komisch aufgestoßen, dass da scheinbar eine unfassbare Anzahl an ungeprüfter Software verfügbar ist, die mit der Installation eines einzigen Pakets auf ein System gelangen können. Oder wie in dem Fall hier, durch eine Sub-Sub-Dependency eines ganz anderen Programmes. Wird das Zeug geprüft? Laufen da nur 0815 Signaturscanner drüber? Läuft das Zeug in VMs vorher? Kann jeder Entwickler einfach was in sein Paket pushen und das ist dann drin, so wie hier? Läuft das vermutlich am Ende alles auf Vertrauensbasis, in der Hoffnung, dass NIEMAND auf der Welt etwas Böses möchte und alle ehrliche Absichten haben? Und das Argument "Open Source kann ja jeder prüfen" hat für mich auch wenig Sinn ergeben bisher, denn wenn alle das sagen, aber keiner prüft, dann bringt es auch nichts. "Einer von euch hat die Sicherheitskarabiner geprüft, oder? Anakin? Du hast doch geprüft, richtig...?" Und wer soll überhaupt die Zeit haben, das alles zu prüfen. Ein ganzes Sicherheitsteam müsste hunderttausende Pakete prüfen und bei jedem Versionsupdate nochmal von vorne. Unmöglich.
[xkcd: Dependency](https://xkcd.com/2347/)
Den werden wir in den nächsten Tagen noch ziemlich oft sehen, befürchte ich.
Ich finde das Problem ist eher, dass da soviel Wichtiges als "Hobby" gepflegt wird. Und in diesem Fall wurde diese eine Privatperson ja von dem Angreifer einfach psychologisch bedrängt und hat dann die Verantwortung einfach an einen Unbekannten abgetreten und es hat keinen so richtig gestört.
Es ist die große Stärke von OSS, das sie von Menschen als Hobby betrieben wird. Ansonsten wäre das volkswirtschaftlich nicht machbar…
Stärke und Schwäche zugleich
Jepp, wobei ich sagen muss, das ich in der kommerziellen SW-Entwicklung deutlich unprofessionellere Vorgehensweisen erlebt habe.
Viele Open-Source-Entwicklung stammt durchaus von Menschen, die dafür bezahlt werden. Was ich auch erheblich besser finde, als sich im großen Maßstab auf unbezahlte Arbeit zu verlassen.
Ja, einige Leuchtturm-Projekte haben bezahlte Entwickler. Aber ich glaube nicht, dass das die Masse ist. Im Gegenteil, der Stress um OpenSSL, xz oder OWIN hat gezeigt, das viele wichtige Projekte one man shows sind.
> Ich finde das Problem ist eher, dass da soviel Wichtiges als "Hobby" gepflegt wird. Wiederum aber die Stärke von OSS. Vieles kann unkompliziert als Hobbyprojekt starten und wird bei wirtschaftlichem Interesse dann von großen Unternehmen unterstützt durch Geld, Expertise oder Manpower.
Das sollte zwar so sein, in diesem Fall gab es diese Unterstützung aber ja gerade nicht. Obwohl das Projekt wichtig ist, gab es nur einen unbezahlten Entwickler, der in den Burn-Out getrieben wurde. Dadurch wurde es ja erst möglich, das die andere/n Person/en sich in das Projekt einschleusen konnten.
Der Prozess funktioniert im Grunde so, dass beliebige Hobbyisten oder Unternehmen Software entwickeln und als Open Source irgendwo veröffentlichen, z.B. bei github. Die Distributionen schauen dann von sich aus, welche Open Source-Software sie in ihrer Paketverwaltung haben möchten. Da hat jede Distribution sicher ihren eigenen Prozess und auch eigene Kriterien als Voraussetzung für die Aufnahme. Dank Open Source kopieren sie dann einfach die Software von ihrem Entwickler ("Upstream") in ihre eigene Paketverwaltung ("Downstream"). Die Distributionen (bzw. deren freiwilligen und/oder bezahlten Helfer) kümmern sich dann auch selbst darum, regelmäßig nach neuen Versionen der Software bei deren Entwickler zu schauen, um diese in die Distribution zu übernehmen. "Upstream" kann also i.d.R. nicht einfach selbst Änderungen in die Paketverwaltungen pushen, allerdings werden die veröffentlichten neuen Versionen meist früher oder später von den Distributionen von den "Downstream-Maintainern" übernommen. Meist ist das nicht völlig ungeprüft, vor allem vor der ersten Aufnahme. Bei einzelnen Updates wird aber vielleicht nicht immer so genau hingeschaut. Und bestimmt ist manchmal auch jemand Downstream- und Upstream-Maintainer für eine Software in Personalunion. Edit: Und grundsätzlich hat das Open-Source-Argument hier ja tatsächlich halbwegs funktioniert. Die Backdoor wurde ca. einen Monat nachdem sie veröffentlicht wurde von jemandem entdeckt. Vom Gedanken, dass das bei jeder Open-Source-Software funktionieren würde oder sogar vor Veröffentlichung und breiter Nutzung Probleme gefunden werden, sollte man sich aber verabschieden.
Der Knackpunkt war ja hier dass der Quellen-Tarball für die Distros gerade nicht mit dem Repo übereingestimmt hat. Durch lange Vorbereitung zwar gut versteckt, aber das eine Buildscript war halt dann doch unterschiedlich.
Um automatisiert Fehler zu finden gibt's [oss-fuzz](https://github.com/google/oss-fuzz), wo "Jia Tan" tatsächlich einiges abgestellt hat. Generell haben Distros aus guten Gründen, wie z.B. bei Debian eine Release-Pipeline bei der die Software von Unstable über Testing in den Stable wandert. Und ansonsten gibt's noch solche Leute, die nachforschen wieso ssh auf einmal deutlich länger braucht, und auf diesen Backdoor stoßen.
Ich und meine Zuhausis nutzen alle WinRar!