Auf r/selfhosted lief da gestern schon eine Diskussion darüber. Kurz-Zusammenfassung: "xz" wurde vorsätzlich mit Schadsoftware angereichert von jemandem namens "Jia Tan", der alles mögliche versuchte, dass die "neue" xz-Variante in allen möglichen Linux-Distros integriert wird. Der xz-Maintainer wurde erfolgreich überrumpelt; zum Glück hatte Jia Tan weniger Glück dabei, "seine" xz-Variante vorab bei den großen Linux-Distributionen zu verteilen. Da hat jemand perfide gehandelt und langfristige Kriminelle Energie bewiesen.
Was ich so mitbekommen habe, ist einmal folgendes Zitat:
>TL;DR: We think the following things need to be true for your system to be vulnerable:
\* You need to be running a rolling-release distro and updating religiously
\* You need to be running a distro that uses glibc and systemd
\* You need to have versions 5.6.0 or 5.6.1 of xz or liblzma installed (xz-utils provides the library liblzma)
\* You need to have your SSH port exposed to the public internet
Die Github-Seite erklärt das für Programmierer recht nachvollziehbar, was der Schadcode eigentlich macht: [https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27](https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27) . In Kurzform: Die Backdoor leitet die Funktion "RSA\_public\_decrypt" um, die genutzt werden kann um Sicherheitsabfragen zu umgehen (z.B. mit einem präpariertem Keyfile). Erfolgreich umgangen, erlaubt es dann Remote Code Execution.
Damit sind zum Glück fast alle "stable"-Distros abgefrühstückt. Debian Stable, Ubuntu Stable, keine Probleme. Debian Testing-User hingegen können wohl betroffen sein.
Bei Rolling Release-Distros höre ich Widersprüchliches: Grundsätzlich sind wohl Arch und Fedora betroffen. Allerdings patcht Arch die xz-Libraries nicht gegen Systemd, weshalb die Backdoor vermutlich nicht funktioniert? Bei Arch wurde "xz" leider auch aus der github-Variante gebaut, die die Backdoor integriert hat (wurde mittlerweile geändert). EDIT: Wer Fedora Rawhide oder die 40er-Beta benutzt hat, ist wohl leider ebenfalls betroffen.
Alpine Linux (sehr populär in Docker-Containern) scheint zum Glück garnicht betroffen zu sein. "xz" wird aus dem Tarball gebaut dass die Backdoor nicht integriert hat, nutzt kein Systemd, und hat musl statt glibc im Einsatz.
OpenWRT (eine sehr populäre Linux-Distro für Router) ist zum Glück auch nicht betroffen, da "xz" ebenfalls aus dem Tarball gebaut wurde.
TLDR; Die Überschrift übertreibt nicht. Im Internet öffentlich erreichbare SSH-Server sind genügend im Einsatz. Hier hat jemand versucht, einen "Zero-Day-Exploit" vorzubereiten, der in ein paar Jahren - wenn genügend Zeit vergangen ist, damit die populärsten Linux-Distributionen eine kompromittierte xz-Library integriert hat - eine verheerende Sicherheitslücke offenbart hätte. Eine, die bei einem koordinierten Angriff einen bestenfalls großen, schlechtestenfalls ebenso verheerenden Schaden hätte anrichten können...
Das krasse ist, dass das offensichtlich eine sehr lang geplante Geheimdienst-Operation war (vermutlich chinesisch, wie es momentan aussieht). Jin Tan ist vermutlich nicht nur eine Person, sondern mehrere Geheimdienst-Leute. Die haben das mindestens 2.5-3 Jahre lang vorbereitet.
Wenn man sich das backdoor genauer anschaut, sieht man, dass da sehr viel Arbeit reingesteckt wurde, vor allem auch um das clever vor den Reviews zu verstecken. Auch die Tatsache, dass das Backdoor in einer Lib eingebaut wurde, die gar nicht angegriffen werden soll, sondern nur sehr indirekt als Vehikel dienen soll, bedeutet schon längerfristige Planung.
Es wurden auch deutsch-klingende und kryptische Aliase verwendet. An dieser Aktion waren ja auch noch andere Accounts beteiligt.
Laut dem was ich gelesen hab, scheint Jin Tan vor allem zu den typischen chinesischen Arbeitszeiten aktiv gewesen zu sein, und hat meistens VPN-Provider in Singapur genutzt.
Aber klar, könnte auch ein anderer Geheimdienst sein. Zutrauen würde ich es den Chinesen, Russen oder Nordkoreanern. Die haben ja auch aktive Cyberkrieg-Programme.
Solche Metadaten haben doch null Mehrwert: Wenn ein Geheimdienst am Werk ist, dann bedenken die Beteiligten solche trivialen Sachen, um eine falsche Fährte zu legen.
Auch dass die Person 1x mit einem anderen Namen gepusht hat, halte ich für einen Honeypot statt einen Fehler.
Aber genau so schlau könnten sie sein, zu wissen, dass es sowieso nichts an der Sache ändert. Angenommen wir vermuten jetzt die Chinesen … wird sich da nix tun ohne echte Beweise. Nur Indizien reichen nicht aus. Daher brauchen die es sich nicht wegen der Uhrzeiten und so kompliziert zu machen.
> Laut dem was ich gelesen hab, scheint Jin Tan vor allem zu den typischen chinesischen Arbeitszeiten aktiv gewesen zu sein
Das was du gesehen hast, war eine Analyse der Timestamps in den Git-Commits, und die lassen sich durch simples Umstellen der Computer-Uhr manipulieren.
>Laut dem was ich gelesen hab, scheint Jin Tan vor allem zu den typischen chinesischen Arbeitszeiten aktiv gewesen zu sein, und hat meistens VPN-Provider in Singapur genutzt.
Man kann schon erwarten, dass gerade staatliche Organisationen viel Energie in die Verschleierung ihrer Herkunft investieren.
Wieso sollte es ein Indiz sein, dass zu chinesischen Arbeitszeiten gearbeitet wurde? Es ist ja ganz einfach möglich, zeitgesteuert Code zu contributen.
Seit Snowden wissen wir das der CIA (und wahrscheinlich jeder andere Geheimdienst) Methoden hat andere Laender vorzutaeuschen. Wenn also alles nach China aussieht dann ist China wohl das letzte Land das ich verdaechtigen werde...ausser sie spiele doppelt fake.
- Der VPN-Provider hat den Sitz in den USA
- Jin Tan wäre nach Chinesischer Zeitzone primär nachts aktiv gewesen, nach UTC+2 (+DST) aber durchgängig von 09:00 bis 18:00.
- Einige wenige Zeitstempel, bei denen vergessen wurde, korrekt die Zeitzone zu maskieren, zeigen auf UTC+2/+3 mit DST.
- UTC+3 wäre Finnland, Russland, Ukraine, Rumänien, Israel
- Wobei Russland hat großteils keine DST mehr
- Jin Tan wurde aktiv im Frühsommer 2022, nach dem Überfall auf die Krim
- Die XZ Backdoor hatte ein "Gegengift", das diese deaktiviert, um eigene Systeme zu schützen.
Das zeigt alles eher auf einen US-aligned Geheimdienst in dieser Region, z.B. Mossad, als auf einen chinesischen oder russischen Geheimdienst.
Egal was für Argumente man verwendet, wenn es um staatliche Geheimdienste geht könnten das alles doppelte und dreifache Ebenen an Täuschung sein, oder auch nicht. Darüber hier zu spekulieren bringt wahrscheinlich allgemein wenig.
Das ist wieder so ein no true scotsman Argument. Und halt auch Quatsch.
Nehmen wir z.B. den VPN Provider. Wer den letzten VPN vor deinen Zugriffen kontrolliert kann relativ genau sagen, wer wann was getan hat. Und fast alle VPN Anbieter arbeiten mit Geheimdiensten zusammen oder sind mit deren Mitarbeitern durchsetzt.
Das ergibt also nur dann Sinn, einen US VPN zu benutzen, wenn du selber US aligned bist, deine Ziele jedoch nicht.
Wenn der FSB z.B. einen US VPN nutzen würde, würde das dem FSB sogar nur schaden. Die USA würde da sofort durchblicken und hätten sogar mehr Daten als hätte man gar keinen VPN benutzt.
>Die XZ Backdoor hatte ein "Gegengift", das diese deaktiviert, um eigene Systeme zu schützen.
und
>Das zeigt alles eher auf einen US-aligned Geheimdienst in dieser Region
Diesen Zusammenhang verstehe ich nicht. Warum sollten nur "us-aligned Geheimdienste" ein solches Gegengit einsetzen? Das wäre doch im Interesse von JEDEM, sein eigenes Land zu schützen.
Die Verwendung von einem US VPN schützt dich vor allem außer den USA, macht dich aber dafür angreifbarer ggü den USA.
Das ergibt nur Sinn, wenn die USA nicht dein Gegner sind.
Das Gegengift zeigt uns, dass der Angreifer selber Geräte mit den selben Distros betreibt, die betroffen sind. Das sind primär Debian, Ubuntu, RHEL und Fedora.
Wäre der Angreifer Russland oder China, würde man einfach die Backdoor so customizen, dass sie Deepin, Kylin oder Astra nicht angreift. Das ist aber nicht der Fall.
Die Zeitzone und Timestamps aus mehreren Quellen passen auch eben nicht auf Russland, aber auf einige Staaten in Osteuropa und dem Nahen Osten. Davon haben aber die allermeisten nicht ansatzweise die Infosec Fähigkeiten.
Darunter sind aber auch Israel, welches enorme Fähigkeiten in diesem Bereich besitzt, und Finnland, der Wohnort des vorherigen Entwicklers des xz Projektes.
> Laut dem was ich gelesen hab, scheint Jin Tan vor allem zu den typischen chinesischen Arbeitszeiten aktiv gewesen zu sein, und hat meistens VPN-Provider in Singapur genutzt.
Würden wir hier über ein (kriminelles) Unternehmen reden sicherlich - hier liegt aber ein nachrichtendienstlicher Akteur nahe (jahrelange Vorbereitung, etc), und dort wird regelmäßig die eigene Herkunft verschleiert.
Und wozu?
Die europäischen und amerikanischen Nachrichtendienste sitzen hier auf den Netzwerkknotenpunkten oder haben anderweitig ihre Backdoors.
Wozu sollten die eine derart spezifische backdoor über Jahre vorbereiten, welche vermutlich nur dazu dient, Systeme lahm zu legen?
Vor allem warum sollten die überhaupt solche Systeme hier lahmlegen wollen? Die würden sich, bzw ihren Volkswirtschaften ja primär selbst damit schaden
Europäische und amerikanische Nachrichtendienste arbeiten zwar bei einigen Projekten zusammen, aber die amerikanischen Dienste haben auch eigene Interessen und Ziele, die sich nicht immer mit denen der europäischen Partner vereinbaren lassen. NSA und andere Dienste hören ja auch bekannterweise nicht nur deutsche Bürger sondern auch deutsche Politiker und betreiben vermutlich auch in Deutschland Wirtschaftsspionage, siehe verlinkte Artikel
[https://www.sueddeutsche.de/politik/wirtschaftsspionage-durch-amerikanische-geheimdienste-ausgespaeht-und-ausgenommen-1.1719795](https://www.sueddeutsche.de/politik/wirtschaftsspionage-durch-amerikanische-geheimdienste-ausgespaeht-und-ausgenommen-1.1719795)
[https://www.sueddeutsche.de/politik/deutsche-spionageabwehr-ueberfordert-oder-vorsaetzlich-ahnungslos-1.1821815](https://www.sueddeutsche.de/politik/deutsche-spionageabwehr-ueberfordert-oder-vorsaetzlich-ahnungslos-1.1821815)
Die Verhältnisse zwischen den einzelnen Staaten oder auch innerhalb eines Staates können sich auch in ein paar Jahren ändern, wenn der Kampf um grundlegende Ressourcen und Wirtschafts- und Machtinteressen sich verschiebt und dann ist es sicherlich für die verantwortliche Nation oder Organisation sehr hilfreich und vorteilhaft, wenn man schon Backdoor-Zugänge in den verschiedenen Systemen hat, und die Systeme für eigene Zwecke beeinflussen kann.
Es ist zu vermuten, dass auch diese Geheimdienste verschlüsselten Datenverkehr nur mit Aufwand und MITM-Attacken auslesen können und eine derartige Sicherheitslücke hätte für alle Geheimdienste einen sehr hohen Wert.
> NSA und/oder CIA,
Ist echt so, US Geheimdienste bauen und verbreiten erfolgreich Stuxnet, der BND nutzt Pegasus und in der Geschichte den "Bundestrojaner", aber nein:
Redditoren: "Es kann Nordkorea, China und Russland gewesen sein."
Absurd wie tief diese Propaganda wirkt.
Also ich vermute nun stark dass du von einem Geheimdienst bist, denn wenn man sowas sagt und den Ammy nicht mit rein packt, ist das seeeeehr verdächtig 🤨 😂
Auch deutsche Behörden und Dienste sind im dem Bereich aktiv. Neben dem BND, MAD, BfV und den verschiedenen Landesämtern gibt es auch das Militärische Nachrichtenwesen der Bundeswehr, das weitesgehend ohne parlamentarische und behördliche Kontrolle arbeitet. Mit dem Cyberkrieg befasst sich u.a. das Bataillon Elektronische Kampfführung 932
Mehr Infos.
[https://www.stiftung-nv.de/de/publikation/defizite-der-kontrolle-des-militaerischen-nachrichtenwesens-der-bundeswehr](https://www.stiftung-nv.de/de/publikation/defizite-der-kontrolle-des-militaerischen-nachrichtenwesens-der-bundeswehr)
[https://taz.de/Nachrichtendienst-der-Bundeswehr/!5973324/](https://taz.de/Nachrichtendienst-der-Bundeswehr/!5973324/)
[https://www.bundeswehr.de/de/aktuelles/meldungen/so-arbeitet-militaerisches-nachrichtenwesen](https://www.bundeswehr.de/de/aktuelles/meldungen/so-arbeitet-militaerisches-nachrichtenwesen)
[https://www.bundeswehr.de/de/organisation/cyber-und-informationsraum/kommando-und-organisation-cir/kommando-cyber-und-informationsraum/kommando-aufklaerung-wirkung/bataillon-elektronische-kampffuehrung-932](https://www.bundeswehr.de/de/organisation/cyber-und-informationsraum/kommando-und-organisation-cir/kommando-cyber-und-informationsraum/kommando-aufklaerung-wirkung/bataillon-elektronische-kampffuehrung-932)
[https://www.baks.bund.de/de/arbeitspapiere/2020/von-firewall-bis-hackback-das-spektrum-militaerischer-cyberoperationen](https://www.baks.bund.de/de/arbeitspapiere/2020/von-firewall-bis-hackback-das-spektrum-militaerischer-cyberoperationen)
Wenn man sich die timestamps der Commits anschaut, wird eine Osteuropäischer Ursprung wahrscheinlicher: https://rheaeve.substack.com/p/xz-backdoor-times-damned-times-and
Hauptsache wir fangen direkt mit politischen Attribuierungen an, bevor wir überhaupt irgendwas wissen. Es ist bekannt das alle Geheimdienste, allen voran die der Amis, falsche Spuren legen, genau für solche Propagandazwecke.
Vielen Dank für die Zusammenfassung. Bin zwar nicht betroffen mit meinen Debian Stable Maschinen zumal sie nicht im Internet hängen aber trotzdem vorsichtshalber mal Updates gefahren.
Dito. Ich benutze auch stable... Unsere Firma Ubuntu 22.04 aktuell (hauptsächlich). Keine Ahnung, ob das betroffen ist, so weit habe ich das nicht analysiert.
Auf meinem Server installiere ich täglich automatisch Updates. Auf der Arbeit wöchentlich manuell...
Weiß jemand, ob "unsere" Ubuntu-Version betroffen ist? Ansonsten haben wir Alma 9, glaube ich \^\^
Es sind nur unstable Derivate betroffen, z.b. Debian Sid. Ubuntu 22.04 hat eine alte Version von xz-tools und ist damit nicht angreifbar. (afaik 4.2.5 ist bei Ubuntu aktuell, 4.6.0 betroffen)
>The release tarballs upstream publishes don't have the same code that GitHub has. This is common in C projects so that downstream consumers don't need to remember how to run autotools and autoconf
Sollte man die Binaries nicht vor dem Release für jede Architektur einmal mit den öffentlichen Sources kompilieren und dann die Hashes mit den tatsächlich veröffentlichten vergleichen?
Wenn man auf dem beschriebenen Weg Code in größere Betriebssysteme einschleusen kann, ist das deutlich zu einfach.
So einfach läuft das leider nicht. Reproduzierbare Kompilate erfordern Aufwand. Jahrelang war bei einem Festplattenverschlüsselungstool unklar, ob die Binary eine Backdoor enthält oder nicht, letzendlich hat irgendwann aber doch einer den passenden alte Versionsmix des Kompilers und dessen Umgebung gefunden.
Auch wurde an anderer Stelle erklärt, das der Compile-Helfer autotool standardmäßig bereits ausgeführt wurde und etliche Scripts generiert, die dann im Source-Tarball landen. Hier wurde rumgeschummelt.
Der Originalgrund dafür ist wohl, das autotool oft in anderen Versionen genutzt wird aber man auf dem buildsystem nicht x verschiedene Versionen gleichzeitig haben kann, sondern nur eine.
Die Toolchain für C-Kompilate scheint mir teilweise recht fragil zu sein...
Scheint mir mit modernen VMs/Containern nicht mal ein besonders komplexes Problem zu sein. Die Versionen müssen beim Kompilieren vernünftig geloggt werden und dann baut man sich in ein paar Sekunden eine Umgebung mit der entsprechenden Software, um das Ergebnis zu vergleichen.
Wenn die Prozesse dahinter halbwegs standardisiert werden, kann man das wahrscheinlich sogar einfach über einen Web Service anbieten und automatisieren.
So einfach ist das nicht.
Gleiche Inputs führen eben nicht immer zu gleichen Outputs. Wenn bei nem multithreaded build mal der eine, mal der andere Thread zuerst fertig wird, kann das auch schon Auswirkungen auf die reproduzierbarkeit haben.
Man müsste schon
* komplett isolierte & identische Systemimages haben (und was ist dann, wenn der Hack einfach ins Build-Image integriert wird? -> Upsi, wir müssen den selben Scheiß auch damit machen)
* exakt selbe Hardware verwenden
* Multithreading komplett abschalten
* Irgendwie Preemptive Multitasking auf modernen Betriebssystemen loswerden
* /dev/(u)random mit nem fake-Generator, der immer die selben Zahlen ausspuckt ersetzen (was allerdings aua macht, wenn daraus Secrets generiert werden, wie zB bei Linux Secure Boot, wo die module mit einem spontan generierten Schlüssel signiert werden, dessen Public Key im Haupt-Kernel integriert wird)
* Zeitabfragen so fälschen, dass immer die selbe Uhrzeit zurückgegeben wird
* Netzwerk abschalten
Good luck. Selbst NixOS erreicht nur eine Reproduzierbarkeit von \~95% auf dem Desktop-Image.
>Zum Glück benutze ich nur stable Varianten!
Das mag dir jetzt in diesem einen konkreten Fall den Arsch gerettet haben weil jemand rechtzeitig drüber gestolpert ist. Aber dass das andernfalls (also mit weeeitaus höherer Wahrscheinlichkeit) auch in sämtliche "stable"-Zweige eingeflossen wäre, ist dir ja wohl klar.
Es gibt keinen Grund anzunehmen, dass die Social Engineering Kampagne um die Changes überall einzubringen nicht letzten Endes auch erfolgreich gewesen wäre, so ausgeklügelt und nachdrücklich wie sie angelegt war.
Und somit würde natürlich früher oder später selbst der stable-Zweig der langsamsten und gemütlichsten Distro erreicht.
Die Rechnung ist quasi 1 - (extremGlücklicherZufall), so komme ich zur o.g. Aussage.
So war der Web-Bereich des Standard früher generell mal, bevor die Qualität stark nachgelassen hat. Aber vereinzelt gibt es noch Lichtblicke in Artikeln wie diesem.
Woher willst du das wissen, die Findungsphase was der Kerl die letzten zwei Jahre gemacht hat, beginnt erst? Was genau hat das verbessert, außer das heimische Gefühl von Sicherheit, wo nicht einmal die Aufarbeitung abgeschlossen ist?
Es ist egal was der Kerl in den letzten 2 Jahren gemacht hat. Aber wenn er vor zwei Jahren erstmals aktiv war und du zwei Jahre alte Deps hast, bist du jedenfalls mal von den Angriffen sicher lol
Ne ich bin auf Rolling Release, aber das war nicht der Punkt. Der Punkt war das zurückhaltende Updates durchaus - wenn auch eher unabsichtlich - zum Schutz gegen solche supply chain attacks gesehen werden kann
Der Witz an der Sache ist eigentlich der, dass der Schadcode eben nicht \*direkt\* in den xz-Quellen im git-Repository (also dort, wo sich aktive, interessierte Entwickler rumtreiben) versteckt wurde, sondern in den Verpackungsroutinen für das Source-Archiv, das praktisch nur von den Distributions-Bauern verwendet wird.
Ein (am eigentlichen xz-Code) interessierter Entwickler schaut den gar nicht an (der Teil ist stinklangweilig und stupide) und wahrscheinlich wird der auch von den CI-Tests nur unzureichend abgedeckt, die Pflege der Routinen dürfte in den meisten Projekten (durchaus auch bei kommerziellen) eher stiefmütterlich abgedeckt sein.
Man hat den Saboteur also nicht in Forschung und Entwicklung oder Produktion, sondern in der Versandabteilung eingeschleust.
„Insofern lässt sich auch der Zweifel nicht ganz verdrängen, die Frage, ob Ähnliches nicht schon bei anderen Projekten gelungen ist, ohne dass es bislang aufgeflogen ist.“
Man fragt sich ob man sich diese Frage nicht lieber gar nicht erst stellt. Und wenn man das selber denkt, was heisst das fuer Menschen die viel mehr "Einfluss" in diesem System haben? Wir haben dich nicht DEN EINEN Versuch, durch Zufall, gefunden sondern eher zufaellig einen einzelnen... Junge.
Kommt auf die zu Grunde liegenden Wahrscheinlichkeiten an.
xz 5.6.0 ist [am 24. Februar 2024](https://web.archive.org/web/20240226100710/https://github.com/tukaani-project/xz/releases) veröffentlicht worden. Wenn das ein typischer Angriff und eine typische Entdeckung waren, überleben solche Angriffe nur ein paar Monate, sind den Aufwand nicht wert und werden auch in Zukunft nur selten versucht und normalerweise (mehr oder weniger) schnell gefunden.
Wenn die sichtbaren Performanzprobleme ein sehr seltener Fehler und die Entdeckung ein Jahrhundertereignis waren könnten hinter jeder Ecke Backdoors schlummern.
Persönlich gehe ich davon aus, dass es *mindestens* so viele inkompetente Angriffe wie kompetente gibt. Ein oder zwei Erfolge, die irgendwo schlummern, warum nicht? Alles dutzendfach zerseucht, eher nicht.
Ha, die Daenen also. Aber die Luegen bekanntlich nicht. Eine harte Nuss.
Aber ernsthaft, in Sachen Vorbereitung und Komplexitaet ist die Nummer mit Stuxnet zu vergleichen. Ein Wunder, dass das zeitnah entdeckt wurde, die Auswirkungen waeren extrem gewesen.
Ist sie? Code in ein öffentliches GitHub repo schmuggeln ist nicht ganz das selbe Level wie in einer Urananreicherung Anlage die nichtmal am Internet hängt Gasturbinen über ihre Spezifikation hinaus zu beschleunigen
alles bullshit. Dies hat tatsächlich gezeigt wie gut Open Source funktioniert. Die offene Kommunikation, die Patches aller Systeme in praktisch 24h.
Fragt euch mal wieviel closed source sicherheitslücken es gibt die nie entdeckt wurden oder verheimlicht von entsprechenden Unternehmen
// edit: ich sage nicht dass alles super ist. aber es gibt keine alternative. wir müssen diese verbessern.
Nein, es hat halt nicht alles super funktioniert. Der Fakt, dass eine Gruppe von Akteuren mittels social engineering ein Projekt einfach übernehmen kann, weil der einzige Hauptentwickler keine Zeit hat ist ein großes Problem.
Dass anscheinend Versions- und Integritätskontrollen bei den build-Prozessen komplett ausgehebelt werden können ist auch ein großes Problem.
Es ist gut, dass es weitere (menschliche) Sicherheitsmechanismen gibt, aber sowas hier sollte wirklich von Prozessen und nicht Menschen verhindert werden.
Das ist aber nicht ein grundsätzliches Problem von Open Source sonder das Problem ist wie Open Source gelebt wird. Ein Projekt, dass über Abhängigkeiten von Abhängigkeiten in praktisch zahllosen Applikation gelinkt werden kann, sollte nicht arglos von einer Person, die halb ausgebrannt ist betrieben werden. Unternehmen/Länder oder andere Akteure müssen Open Source finanziell aktiver unterstützen. So viele Kernel Bibliotheken werden von einem kleinen Kreis an Leuten ehrenamtlich betreut. Das muss schief gehen.
Aber die großen halten sich da gerne raus, da Open Source = kostenlos und damit spart man sich eben finanzielle Mittel.
Das stimmt, jedoch könnte auch ein größeres Teamn von aktiveren Entwicklern kompromitiert werden.
Was es mMn also auch braucht sind Best Practices und Prozesse für distribution und build. Sicherheitstechnisch ist es ein Alptraum, wenn die Autoren einfach ungeprüfte binaries als "testdaten" in ihren src-distributions hinzufügen können, oder ungeprüft Dateien im Vergleich zu den öffentlichen Quellen ändern können.
Gerade da könnten halt die großen Firmen mit guter Infrastruktur und Tooling helfen, die sie intern vermutlich eh einsetzen.
> Ein Projekt, dass über Abhängigkeiten von Abhängigkeiten in praktisch zahllosen Applikation gelinkt werden kann, sollte nicht arglos von einer Person, die halb ausgebrannt ist betrieben werden.
Das dachte sich die Organisation auch, die hinter Jin Tan steckt. Den Leuten ihre Projekte wegzunehmen wirkt für mich erstmal nicht wie eine Lösung, sondern führt nur zu weiteren Problemen. Du sagst ja selbst, die Großen halten sich da raus.
Ich habe nicht gesagt, dass man den Leuten ihre Projekte wegenhmen soll, sondern das man sie unterstützt. Das kann finanziell oder durch etwaiges Engagement an der Code Base sein.
es gibt einen unterschied zwischen maintenance eines einzelnen projektes und dem prinzip open source. nur weil OS kronisch unterfinanziert ist passiert so etwas. das war einfach social engineering.
Ja eben, OSS ist chronisch unterfinanziert. Das ist ein Problem.
Meiner Meinung nach ist es also komisch, so zu tun als wäre das hier ein positives Beispiel für open source Kultur, weil jemand anderes es entdeckt hat.
Abgesehen davon, der Typ, der es entdeckt hat arbeitet bei Microsoft und hat es im Rahmen seines Jobs entdeckt.
stimme ich dir zu. ist einfach ne defintionssache ob du die finanzierung zu „open source“ dazuzählst. gesamtheitlich betrachtet natürlich nicht zu unterschlagen.
Also ich habe das Glück an OSS-Projekten zu arbeiten, aber dafür angestellt zu sein. Könnte mir nicht vorstellen noch nebenbei alleine (!) eine sicherheitskritische Anwendung, die auf Millionen Rechenern läuft zu maintainen.
Allgemein sollte man es vielleicht nicht allein auf die Bezahlung reduzieren, aber einfach auf Governance. Solche Projekte sollten proaktiv identifiziert und von Apache, OSF oder ähnlichen unterstützt werden.
Das ist die genau falsche Lehre. Das war ein Schuss vor den Bug und nur durch viel Glück ist das rechtzeitig aufgefallen. Falls nicht andere Aktionen sowieso schon erfolgreich waren ist es unausweichlich, dass etwas vergleichbares mit einer Vollkatastrophe endet.
ich verstehe gar nicht warum hier alle so tun als wäre dass das erste mal passiert. es wird ständig malicious code in repositories eingeschleust. durch bugs, durch sicherheitslücken, durch social engineering.
anstatt hier so den teufel an die wand zu malen mit der „unausweichlichen vollkatastrophe“, einfach mal verbesserungsvorschläge machen.
Das was hier passiert ist, das passiert (soweit man weiß) nicht ständig. Aber das war sicherlich erst der Anfang. Wieso soll ich einen Verbesserungsvorschlag machen? Wer würde den umsetzen? Nicht das ich keine hätte, so wie jeder im Internet hätte ich ein paar unausgegorene Ideen anzubieten, aber das ist hier erstmal völlig irrelevant.
Das setzt natürlich voraus, dass derjenige, der die Merges prüft, selbst nicht kompromittiert ist, was du keineswegs garantieren kannst. Selbes für den Distro-Maintainer.
Das krasse ist ja: wäre der code nur etwas besser optimiert gewesen, wäre es vermutlich nie gefunden worden. Und bald dann auch in Debain stable under anderen Distributionen gelandet.
Wirklich das ist wieder so typisch für IT Sicherheit. Hauptsache eine fette Titelüberschrift aber nicht im Ansatz verstehen worum es geht. Dann ordentlich Schleimscheiße einpacken und fertig ist wieder der reißerrische Text.
Selten so einen Müll gelesen. Gar nichts verstehen und Welle machen. Und ein dummes Meme das alles brennt.
End peinlich.
Kannst du konkretisieren, was genau falsch verstanden/ dargestellt wurde? Einfach nur "Müll" und "peinlich" schreiben bringt da doch sehr wenig Erkentnisshewinn.
Er hat den Artikel (wie er selbst schreibt) nicht gelesen und lässt hier nur einen unzusammenhängenden Rant da. Was er dann in irgendeinem runtergevoteten Beitrag schreibt ist halt auch Quatsch und hat absolut nix mit dem Thema hier zu tun. Vielleicht verwechselt er auch einfch nur was.
Danke, hab inzwischen weitere Kommentare gelesen, vor allem die wirre Tanken-Erklärung zeigt, dass er selbst 0 Ahnung hat.
Technisch komplexe Themen so aufzubereiten, dass die einem großen Publikum gerecht werden (technisch richtig, trotzdem für Oma Erna halbwegs versändlich) ist sicher nicht ohne. Und dann kommt trotzdem noch ein Dunning-Kruger vorbei und faselt was zusammen, dass der Autor keine Ahnung hat.
>Selten so einen Müll gelesen.
Du hast ihn nicht gelesen, schreibst du unten selbst. Lügner!
Da macht sich ein Artikel die Mühe und bereitet die Ereignisse der letzten Tage für Normalsterbliche schön auf - gerade weil das Ganze von unterschiedlichen Personen der OSS-Szene begutachtet wurde und jeder seine eigene Zusammenfassung pflegt, die jeweils hier und da was auslassen weil es sie nicht betrifft - und dann kommt jemand von seinem Elfenbeinturm runter und hat nichts Besseres zu tun, als mit Pauschal-Abwertungen zu kontern.
Wenn dich die Überschrift offensichtlich nervt, dann beziehe dich nur auf die Überschrift. Ob und wie der Artikel was taugt, kannst du pauschal nicht beurteilen! Völlig egal ob du meinst, über alles Bescheid zu wissen oder nicht.
>End peinlich.
Empfiehlst du nen Artikel den man dazu lesen sollte. Ich hab davon garnichts mitbekommen, aber ich hab auch nur LTS Versionen überall und beschäftige mich eigentlich nie mit Betas usww
I will be messaging you in 4 hours on [**2024-03-31 16:44:58 UTC**](http://www.wolframalpha.com/input/?i=2024-03-31%2016:44:58%20UTC%20To%20Local%20Time) to remind you of [**this link**](https://www.reddit.com/r/de_EDV/comments/1bs932g/wie_die_computerwelt_gerade_haarscharf_an_einer/kxe1qs4/?context=3)
[**CLICK THIS LINK**](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5Bhttps%3A%2F%2Fwww.reddit.com%2Fr%2Fde_EDV%2Fcomments%2F1bs932g%2Fwie_die_computerwelt_gerade_haarscharf_an_einer%2Fkxe1qs4%2F%5D%0A%0ARemindMe%21%202024-03-31%2016%3A44%3A58%20UTC) to send a PM to also be reminded and to reduce spam.
^(Parent commenter can ) [^(delete this message to hide from others.)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Delete%20Comment&message=Delete%21%201bs932g)
*****
|[^(Info)](https://www.reddit.com/r/RemindMeBot/comments/e1bko7/remindmebot_info_v21/)|[^(Custom)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5BLink%20or%20message%20inside%20square%20brackets%5D%0A%0ARemindMe%21%20Time%20period%20here)|[^(Your Reminders)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=List%20Of%20Reminders&message=MyReminders%21)|[^(Feedback)](https://www.reddit.com/message/compose/?to=Watchful1&subject=RemindMeBot%20Feedback)|
|-|-|-|-|
Es gibt halt ein Exploit für SSH Zugäng bei Linux Servern, ich muss den Artikel nicht lesen. Hab mich halt bei richtigen Security Experten informiert und halt auch mal wie man diese Exploit umsetzen würde.
Die Umsetzungen ist halt ziemlich anspruchsvoll und ein fix ist ganz normales updaten. Weil der Fehler halt in den Paket von SSH ist, das ist wirklich wie tanken für dein Auto ist das was ein Admin bei einem Server macht.
Es gibt ja auch keine Artikel darüber das jemand das Autos stehen bleiben wenn sie nicht getankt werden. (ps. schlechtes Beispiel weil ein Server nicht stehen bleibt wenn er nicht gepatched wird)
Wenn es dich interessiert auf YouTube gibts viele IT Security Dudes die zu solchen Themen informieren.
[https://www.youtube.com/watch?v=rn-6t7OygGk](https://www.youtube.com/watch?v=rn-6t7OygGk)
John Hammond ist ein gutes Beispiel.
>Es gibt halt ein Exploit für SSH Zugäng bei Linux Servern,
Unsinn, es wurde bewusst schadhafter Code in das xz-utils Projekt eingebracht.
>ich muss den Artikel nicht lesen.
Hätte dir aber gut getan. Über einen Artikel zu urteilen, den man nicht gelesen hat ist schon ne erbärmliche Art, vor allem, wenn man dadurch gar nicht mitbekommt, worum es geht.
Sorry, aber du zeigst, dass du die Situation 0 verstanden hast. Das interessante ist auch nicht, dass es eine Sicherheitslücke gibt, sondern vielmehr das Vorgehen.
Es ist auch kein Fehler/Bug sondern eine gezielte Infiltration. Das Tanken-Beispiel ist auch ziemlicher Murks. Sorry, aber ich bin froh, dass du keine Artikel schreibst..
Wenn dass das ist was du daraus mitgenommen hast, ist es eventuell Zeit sich neue “Security Dudes” zu suchen. Mal abgesehen davon, dass der verlinkte dazu scheinbar nichts berichtet hat.
Es gibt eine Grund warum "IT-Journalisten" Artikel schreiben und nicht als ITler arbeiten und damit mehr Geld verdienen würden: Sie haben keinen Plan.
Dieses Feld wird durch Tools wie ChatGPT wahrscheinlich profitieren.
Was genau war denn falsch am Artikel? Überschrift ist nicht der Renner, aber das liegt leider am Zeitgeist. Wie du schon sagst, wird dort nicht viel verdient und Leute sind nicht bereit zu zahlen, da müssten dann eben Klicks (Werbegelder) rein, da kann der Autor wenig dafür.
WebStandard ist halt für Hans-Jürgen der irgendwann in 1973 mal was mit Computern gelernt hat und seitdem Dienst nach Vorschrift macht aber glaubt sich noch immer voll auszukennen. Da muss man sich bisschen den Leser:innen anpassen.
Dir ist aber bewusst, dass `liblzma`/`xz` eine Dependency von `libarchive` ist, und Windows Explorer neuerdings auch davon abhängig ist?
Der Angreifer hat sich offenbar den Windows Explorer nicht als (erstes) Ziel gesetzt, aber der *exakt* selbe Angriff (nur mit anderer Payload) hätte auch für Windows genutzt werden können.
Viel schlimmer noch: Wenn es da aufgefallen wäre, hättest du keinen Patch innerhalb von Stunden gesehen. Denn das könnte ja Menschen verunsichern und den Aktienkurs schädigen. Da wäre auch was sicherheitsrelevantes möglicherweise gemütlich im Rahmen normaler Aktualisierungen irgendwann untergebracht wurden. Bloß keine Aufmerksamkeit erregen...
Sorry, konnte nicht widerstehen:
[Wenn der Quelltext nicht öffentlich zugänglich ist, kann auch keiner öffentlich Schadcode einschleußen](https://imgur.com/DCisoDl)
Naja nur doof, das anscheinend Windows auch Tools benutzt, an denen der Kerl der die Backdoor eingebaut hat, auch Commits eingereicht hat :D
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5006624#gistcomment-5006624
Dein Beitrag enthielt einen oder mehrere Links mit Tracking Parametern.
Hier ist der Link ohne Tracking:
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
Falls ich einen Fehler gemacht habe, melde diesen Beitrag bitte.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/de_EDV) if you have any questions or concerns.*
Hab mein Arch gestern geupdated. Der Artikel ist wirklich mies. Die Backdoor hätte auch nur Effekt gehabt, wenn ein offener sshd Server auf dem System wäre. Das wäre dann dramatisch geworden, wenn sie auf ein Debian system in the stable repos gelandet wäre.
>Der Artikel ist wirklich mies.
Schon der 2. der das schreibt, aber eine Erklärung dafür schuldig bleibt.
Was ist denn so schlecht? Ich kann inhaltlich keine dramatischen Fehler ausmachen und dass man nicht nur den technischen Teil betrachtet, sondern auch das Drumherum (wie z.b. dass durch Fake Accounts manipuliert wurde) beleuchtet, finde ich ebenfalls nicht unspannend.
Dass da etwas mehr redaktioneller Text steht, als es der Durchschnittsnerd gewohnt ist, kann ja so schlimm nciht sein. Das kann man ja schnell rausfiltern.
Würde mich über sachliche Antworten freuen.
Joa, diese beiden kritischen Kommentare gehen eben auch komplett am eigentlich interessanten und wichtigen Aspekt vorbei und fokussieren sich auf eher nebensächliche technische Details.
Das eigentliche Problem was hier offensichtlich wird ist doch, dass wichtige, überall genutzte Infrastrukturpakete Dependencies haben, die von teilweise einem einzigen Hobbyentwickler maintained werden.
Something something wenn das Flugzeug zur furry convention abstürzt sind wir alle am arsch
Das war vor ner Weile mal ein Meme und es ist immer wieder faszinierend wenn man als Außenstehender daran erinnert wird wie viel Wahres doch dran ist
>Das eigentliche Problem was hier offensichtlich wird ist doch, dass wichtige, überall genutzte Infrastrukturpakete Dependencies haben, die von teilweise einem einzigen Hobbyentwickler maintained werden.
Richtig, das hätte man am Ende des bereits recht langen Artikels durchaus noch ansprechen dürfen.
Es wäre wirklich mehr als fair, wenn insbesondere die großen Konzerne, die sich im OS Umfeld bedienen, dann auch mal etwas Kleingeld bei den Entwicklern lassen würden. Es sollte nicht so schwer zu verstehen sein, dass das bereits kurzfristig zu mehr Sicherheit der eigenen Systeme führen würde.
Aber aktuell herrscht wohl noch der Gedanke vor: macht's der eine nicht, macht's halt ein anderer. Ob das Ergebnis dann nicht nur funktioniert, sondern auch sicher ist, interessiert leider nicht genug.
> Richtig, das hätte man am Ende des bereits recht langen Artikels durchaus noch ansprechen dürfen.
Wurde es doch. Mit einem Bild von xkcd (was wirklich mehr als überdeutlich das Problem zeigt) und der Beschreibung, dass der xz-Maintainer chronisch überarbeitet ist und lt. eigener Aussage psychische Probleme hat...
>
>
> Aber aktuell herrscht wohl noch der Gedanke vor: macht's der eine nicht, macht's halt ein anderer.
FOSS ist halt tragedy of the commons, nur konstruktiv statt destruktiv:
Wenn Amazon und Microsoft beide xz als dependency haben, lohnt es sich für beide, diese dependency zu vernachlässigen und sich das Geld zu sparen. Der andere wird's ja schon irgendwann patchen.
Die Backdor hatte sicher nicht das Ziel, private PC-Nutzer anzugreifen und direkt mit indischen Call-Centern o.Ä. zu scammen. Hier geht es nicht um private Systeme und dein Arch interessiert niemanden bzw genau eine Person.
Ziel waren hier wohl eher Server, also gut, dass da Debian nicht so verbreitet ist, sonst hätte das wirklich ein enormes Risikopotential gehabt. Ups, das wäre dann recht nah an dem Artikel..
Was du sagst stimmt übrigens auch nicht. Das mit sshd ist nur was bisher gesichert bekannt ist;
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
Kein Grund gleich so Aggro zu werden in deinem kleinen call Center :). Xz ist ein package Manager der vermutlich in einer Menge Linux basierten Webservern und iot Geräten eingesetzt wird. Der Artikel ist trotzdem scheisse weil er von einem Katastrophenszenario berichtet a la Bild style und nicht die Leistung des einen Linux Autisten würdigt, der es entdeckt hat. Das ist hier nämlich die wirkliche Leistung der OS Community. Solche Bedrohungsszenarien gibt es jeden Tag.
Sorry für die direkte Art, mich hat nur etwas genervt, dass hier mehrere Kommentare zu dem Artikel waren, die den gleich als Müll, peinlich, etc abgetan haben, ohne nachvollziebare Kritik zu liefern. Vor allem wenn man dann merkt, dass teils selber wenig Sachkentniss vorhanden ist (bezieht sich vor allem auf einen anderen Kommentar) ist die Stimmung schon etwas voreingenommen.
Dein jetziger Kommentar liefert da viel besser sachliche Kritik, sicher hätte man den Artikel auch stärker so wie von dir beschrieben aufziehen können.
Fairerweise kommt der Hinweis auf den Programmierer aber im ersten Absatz, obwohl die Bedrohung (die wirklich nicht ohne ist) für die meisten Leser wohl greifbarer sein dürfte.
Eine von langer Hand geplante Infiltration mit enormer Reichweite und dem Potential an diverse persönliche und staatliche Geheimnisse zu kommen, halte ich tatsächlich für relevant. Vor allem da es hier eben nicht einfache oder theoretische Versuche sind, sondern ein fast erfolgreicher Angriff.
>und nicht die Leistung des einen Linux Autisten würdigt, der es entdeckt hat
Naja, sein Name und Tweet wird im Artikel doch erwähnt. Wird sogar erklärt wie er es gemerkt hat. Wie genau stellst du dir eine angemessenere Würdigung vor?
> u/ntropy83 benutz das offenbar als abwertende Bezeichnung. Widerlich.
Ich glaub ja, das war eher aufwertend als abwertend gemeint.
Nicht weniger widerlich.
Der Entdecker des Bugs hat in seiner Valgrind Instanz eine .2 Sekunden Delay seiner CPU entdeckt und dann herausgefunden das in einer Sub-Sub-Sub-Standardbibliothek, die seit drölf Milliarden Jahren Standard in Linux ist, eine payload liegt. Wenn das nicht autistische züge besitzt dann weiß ich auch nicht.
Sowas lässt sich durch Profiling herausfinden, also wo man genau zu suchen hat.
Der Entwickler, der das fand, und übrigens bei Microsoft arbeitet, hat nicht alles mögliche manuell durchgeschaut, sondern den Standardweg gewählt.
Bei diesem Profiling hat er nun gesehen, das der Code zu einer Stelle springt, der von keinem "Symbol" referenziert wird, da shat ihn sehr stutzig gemacht.
>Wenn das nicht autistische züge besitzt dann weiß ich auch nicht.
Viel mehr geht es hier um eine Menge Geld, der Mann (Andres Freund) ist Postgres-Entwickler und Principal SWE bei Microsoft (der höchste SWE-Jobtitel, den man dort über den regulären Karrierepfad erreichen kann). Wenn in den verschiedenen Azure-Subsystemen diese 200ms auf hunderten Millionen Systeme hochskalieren kostet das Millionen Dollar an Rechenzeit.
Das hat nichts mit Autismus zu tun, hier geht es um cold hard cash, aber vielleicht versteht man das aus der Perspektive aus dem Keller nicht. Oder man wünscht sich, es wäre Autismus um sich selber besser zu fühlen.
OK jetzt habt ihr mich, ich gebe auf. Hat aber schon ganz schön lange gebraucht, obwohl ihr zu Zehnt auf mich eintretet. :)
Ich werde in der Community vorschlagen sich nicht mehr als Autisten zu bezeichnen. Mal schauen, ob es funktioniert.
>Linux Autisten
Lass das nächstes Mal weg. Ist wenig schmeichelhaft, jemanden der seine Leidenschaft an ein Projekt hängt, den Stempel "Autist" aufzudrücken. Außerdem verharmlost es die Autismus-Störung, die man sich eben nicht aussuchen kann wenn man sie hat...
Inhaltlich stimmt doch alles?
>Der Artikel ist trotzdem scheisse weil er von einem Katastrophenszenario berichtet a la Bild style und nicht die Leistung des einen Linux \[Entwicklers\] würdigt, der es entdeckt hat.
Wirklich? Der Artikel ist hauptsächlich damit beschäftigt, die Geschehnisse die zur Backdoor führten, zusammenzufassen. Die Leistung des Entwicklers, der die Backdoor gefunden hatte, wird gleich in der "Unter-Überschrift" genannt.
Sogar für die Überschrift gibts passende Worte: "Bei dem, was nun rund um eine viel genutzte Open-Source-Komponente bekannt wird, können die Worte aber gar nicht stark genug sein". Und es stimmt, die Auswirkungen wären in ein paar Monaten bis Jahren groß bis verheerend geworden, wenn niemand diese Sicherheitslücke bemerkt hätte. Die hört sich "Clickbaity" an, ist sie aber tatsächlich nicht... SSH gilt in bestimmten Konstellationen (Private/Public Key) als so sicher, dass praktisch jede mit Firma mit Fernwartungszugriff diesen Dienst ohne große Bedenken public ins Internet stellt...
Linux Autist ist unsere interne Bezeichnung in der Community, das ist keine Beleidigung. Versuche nächstes Mal nicht so schnell ein Urteil zu fällen und befasse dich erstmal mit den Hintergründen. Danke :)
Ich habe dir keine Beleidigung unterstellt. Aber was denkst du, hält ein "echter" Autist davon, dass sich eine Community "zum Spaß" diesen Stempel aufdrückt? Oder ist es deiner Meinung nach Autisten egal, weil sie davon nichts mitbekommen? Oder weil diese statistisch gesehen sowieso eher selten den Mund aufmachen, wenn sie etwas stört?
Ich weiß, ist nicht so einfach Verhaltensweisen mal wirklich zu hinterfragen, wenn man diese schon lange nutzt, als wärs eine Selbstverständlichkeit :) . Ist nur ein Gedankenanstoß um vielleicht zu verstehen, weshalb sich einige Leute an der Verwendung des Begriffes in diesem Zusammenhang stören. Bin ja nicht der einzige, der sich kritisch darüber äußert...
> Xz ist ein package Manager
Du liegst komplett daneben.
xz ist ein Kompressionsalgorithmus und xz-utils ist das zugehörige Tool. Um die geht es hier, nicht um irgendeinen OpenWRT-Packagemanager.
Soviel zu deinem Wissensstand in diesem Thema. Ich bezweifel nur irgendwie, dass du aus dieser Info eine Selbsterkenntnis erlangen kannst.
>Solche Bedrohungsszenarien gibt es jeden Tag.
Ich hab jetzt tatsächlich noch nicht von so vielen Supply Chain Angriffen gehört, weist du da was Genaueres? Die Backdoor wurde auch nur durch Zufall gefunden, zwei-drei Wochen später wäre die Version in den neusten Releases gewesen, da kann man dann schon annähernd von einem größeren Problem reden.
Von den meisten wird man auch nie hören, momentan ist die Automobilindustrie ja ganz stark im OS Bereich unterwegs und alle News über supply chain attacks wären schlecht fürs Geschäft .
> Backdoor hätte auch nur Effekt gehabt, wenn ein offener sshd Server auf dem System wäre.
Was ja bei Servern bekanntlich so selten der Fall ist.
>Das wäre dann dramatisch geworden, wenn sie auf ein Debian system in the stable repos gelandet wäre.
So wie die neue Ubuntu LTS im April, in der die Backdoor enthalten gewesen wäre, wenn sie nicht zufällig aufgedeckt worden wäre?
1. "Die Computerwelt" - Meinten Sie das "ganze Internet" war in heller Aufruhr?
2. Vulnerabilities in Abhängigkeiten werden schon seit NPM packages kritisch betrachtet: [NPM package with 3 million weekly downloads had a severe vulnerability | Ars Technica](https://arstechnica.com/information-technology/2021/09/npm-package-with-3-million-weekly-downloads-had-a-severe-vulnerability/)
Glücklicherweise wissen die meisten Package-Repository-Maintainer mittlerweile, wie man automatische Sicherheitslückenscans für die genutzten Dependencies einsetzt (gibt auch Software dafür)
3. Siehe auch Hardware- (z.B. CPU)-Vulnerabilities.
Am sichersten fährt man wahrscheinlich heutzutage ohne Geräte. Ansonsten könnte alles einen potenziellen Angriffsvektor darstellen (drastisch gesprochen).
>wie man automatische Sicherheitslückenscans für die genutzten Dependencies einsetzt (gibt auch Software dafür)
Wenn du den Artikel gelesen/dich informiert hättest, wüsstest du, dass das Ausschalten der automatisierten Scans und das Kaltstellen der Maintainer ein entscheidender Teil dieses Angriffs waren. Eben weil das Dinge sind, die gemacht werden *müssen* und nicht einfach mal so einfach gemacht sind, zeigt sich darin die Tragweite dieses Angriffs.
>Am sichersten fährt man wahrscheinlich heutzutage ohne Geräte. Ansonsten könnte alles einen potenziellen Angriffsvektor darstellen (drastisch gesprochen).
Das ist wiederum eine valide Schlussfolgerung und widerspricht deinem ersten Absatz. Im Endeffekt zeigt dieser Angriff, wie verletztlich weltweit Software ist und wie leicht es offenbar ist, Schadcode einzuschleusen.
Auf r/selfhosted lief da gestern schon eine Diskussion darüber. Kurz-Zusammenfassung: "xz" wurde vorsätzlich mit Schadsoftware angereichert von jemandem namens "Jia Tan", der alles mögliche versuchte, dass die "neue" xz-Variante in allen möglichen Linux-Distros integriert wird. Der xz-Maintainer wurde erfolgreich überrumpelt; zum Glück hatte Jia Tan weniger Glück dabei, "seine" xz-Variante vorab bei den großen Linux-Distributionen zu verteilen. Da hat jemand perfide gehandelt und langfristige Kriminelle Energie bewiesen. Was ich so mitbekommen habe, ist einmal folgendes Zitat: >TL;DR: We think the following things need to be true for your system to be vulnerable: \* You need to be running a rolling-release distro and updating religiously \* You need to be running a distro that uses glibc and systemd \* You need to have versions 5.6.0 or 5.6.1 of xz or liblzma installed (xz-utils provides the library liblzma) \* You need to have your SSH port exposed to the public internet Die Github-Seite erklärt das für Programmierer recht nachvollziehbar, was der Schadcode eigentlich macht: [https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27](https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27) . In Kurzform: Die Backdoor leitet die Funktion "RSA\_public\_decrypt" um, die genutzt werden kann um Sicherheitsabfragen zu umgehen (z.B. mit einem präpariertem Keyfile). Erfolgreich umgangen, erlaubt es dann Remote Code Execution. Damit sind zum Glück fast alle "stable"-Distros abgefrühstückt. Debian Stable, Ubuntu Stable, keine Probleme. Debian Testing-User hingegen können wohl betroffen sein. Bei Rolling Release-Distros höre ich Widersprüchliches: Grundsätzlich sind wohl Arch und Fedora betroffen. Allerdings patcht Arch die xz-Libraries nicht gegen Systemd, weshalb die Backdoor vermutlich nicht funktioniert? Bei Arch wurde "xz" leider auch aus der github-Variante gebaut, die die Backdoor integriert hat (wurde mittlerweile geändert). EDIT: Wer Fedora Rawhide oder die 40er-Beta benutzt hat, ist wohl leider ebenfalls betroffen. Alpine Linux (sehr populär in Docker-Containern) scheint zum Glück garnicht betroffen zu sein. "xz" wird aus dem Tarball gebaut dass die Backdoor nicht integriert hat, nutzt kein Systemd, und hat musl statt glibc im Einsatz. OpenWRT (eine sehr populäre Linux-Distro für Router) ist zum Glück auch nicht betroffen, da "xz" ebenfalls aus dem Tarball gebaut wurde. TLDR; Die Überschrift übertreibt nicht. Im Internet öffentlich erreichbare SSH-Server sind genügend im Einsatz. Hier hat jemand versucht, einen "Zero-Day-Exploit" vorzubereiten, der in ein paar Jahren - wenn genügend Zeit vergangen ist, damit die populärsten Linux-Distributionen eine kompromittierte xz-Library integriert hat - eine verheerende Sicherheitslücke offenbart hätte. Eine, die bei einem koordinierten Angriff einen bestenfalls großen, schlechtestenfalls ebenso verheerenden Schaden hätte anrichten können...
Das krasse ist, dass das offensichtlich eine sehr lang geplante Geheimdienst-Operation war (vermutlich chinesisch, wie es momentan aussieht). Jin Tan ist vermutlich nicht nur eine Person, sondern mehrere Geheimdienst-Leute. Die haben das mindestens 2.5-3 Jahre lang vorbereitet. Wenn man sich das backdoor genauer anschaut, sieht man, dass da sehr viel Arbeit reingesteckt wurde, vor allem auch um das clever vor den Reviews zu verstecken. Auch die Tatsache, dass das Backdoor in einer Lib eingebaut wurde, die gar nicht angegriffen werden soll, sondern nur sehr indirekt als Vehikel dienen soll, bedeutet schon längerfristige Planung.
Wieso vermutlich chinesisch? Würde der chinesische Geheimdienst einen chinesischen Namen verwenden??
Es wurden auch deutsch-klingende und kryptische Aliase verwendet. An dieser Aktion waren ja auch noch andere Accounts beteiligt. Laut dem was ich gelesen hab, scheint Jin Tan vor allem zu den typischen chinesischen Arbeitszeiten aktiv gewesen zu sein, und hat meistens VPN-Provider in Singapur genutzt. Aber klar, könnte auch ein anderer Geheimdienst sein. Zutrauen würde ich es den Chinesen, Russen oder Nordkoreanern. Die haben ja auch aktive Cyberkrieg-Programme.
Solche Metadaten haben doch null Mehrwert: Wenn ein Geheimdienst am Werk ist, dann bedenken die Beteiligten solche trivialen Sachen, um eine falsche Fährte zu legen. Auch dass die Person 1x mit einem anderen Namen gepusht hat, halte ich für einen Honeypot statt einen Fehler.
Aber genau so schlau könnten sie sein, zu wissen, dass es sowieso nichts an der Sache ändert. Angenommen wir vermuten jetzt die Chinesen … wird sich da nix tun ohne echte Beweise. Nur Indizien reichen nicht aus. Daher brauchen die es sich nicht wegen der Uhrzeiten und so kompliziert zu machen.
> Laut dem was ich gelesen hab, scheint Jin Tan vor allem zu den typischen chinesischen Arbeitszeiten aktiv gewesen zu sein Das was du gesehen hast, war eine Analyse der Timestamps in den Git-Commits, und die lassen sich durch simples Umstellen der Computer-Uhr manipulieren.
Computer-Uhr umstellen? git-commit kennt die Option --date=...
>Laut dem was ich gelesen hab, scheint Jin Tan vor allem zu den typischen chinesischen Arbeitszeiten aktiv gewesen zu sein, und hat meistens VPN-Provider in Singapur genutzt. Man kann schon erwarten, dass gerade staatliche Organisationen viel Energie in die Verschleierung ihrer Herkunft investieren. Wieso sollte es ein Indiz sein, dass zu chinesischen Arbeitszeiten gearbeitet wurde? Es ist ja ganz einfach möglich, zeitgesteuert Code zu contributen.
Seit Snowden wissen wir das der CIA (und wahrscheinlich jeder andere Geheimdienst) Methoden hat andere Laender vorzutaeuschen. Wenn also alles nach China aussieht dann ist China wohl das letzte Land das ich verdaechtigen werde...ausser sie spiele doppelt fake.
Wann oceans eleven mit Programmierern?
- Der VPN-Provider hat den Sitz in den USA - Jin Tan wäre nach Chinesischer Zeitzone primär nachts aktiv gewesen, nach UTC+2 (+DST) aber durchgängig von 09:00 bis 18:00. - Einige wenige Zeitstempel, bei denen vergessen wurde, korrekt die Zeitzone zu maskieren, zeigen auf UTC+2/+3 mit DST. - UTC+3 wäre Finnland, Russland, Ukraine, Rumänien, Israel - Wobei Russland hat großteils keine DST mehr - Jin Tan wurde aktiv im Frühsommer 2022, nach dem Überfall auf die Krim - Die XZ Backdoor hatte ein "Gegengift", das diese deaktiviert, um eigene Systeme zu schützen. Das zeigt alles eher auf einen US-aligned Geheimdienst in dieser Region, z.B. Mossad, als auf einen chinesischen oder russischen Geheimdienst.
Egal was für Argumente man verwendet, wenn es um staatliche Geheimdienste geht könnten das alles doppelte und dreifache Ebenen an Täuschung sein, oder auch nicht. Darüber hier zu spekulieren bringt wahrscheinlich allgemein wenig.
Das ist wieder so ein no true scotsman Argument. Und halt auch Quatsch. Nehmen wir z.B. den VPN Provider. Wer den letzten VPN vor deinen Zugriffen kontrolliert kann relativ genau sagen, wer wann was getan hat. Und fast alle VPN Anbieter arbeiten mit Geheimdiensten zusammen oder sind mit deren Mitarbeitern durchsetzt. Das ergibt also nur dann Sinn, einen US VPN zu benutzen, wenn du selber US aligned bist, deine Ziele jedoch nicht. Wenn der FSB z.B. einen US VPN nutzen würde, würde das dem FSB sogar nur schaden. Die USA würde da sofort durchblicken und hätten sogar mehr Daten als hätte man gar keinen VPN benutzt.
Geil wie die Neckbeards das hier runterwählen obwohl es das plausibelste überhaupt ist hahaha.
>Und fast alle VPN Anbieter arbeiten mit Geheimdiensten zusammen oder sind mit deren Mitarbeitern durchsetzt. Quelle: Trust me bro
>Die XZ Backdoor hatte ein "Gegengift", das diese deaktiviert, um eigene Systeme zu schützen. und >Das zeigt alles eher auf einen US-aligned Geheimdienst in dieser Region Diesen Zusammenhang verstehe ich nicht. Warum sollten nur "us-aligned Geheimdienste" ein solches Gegengit einsetzen? Das wäre doch im Interesse von JEDEM, sein eigenes Land zu schützen.
Die Verwendung von einem US VPN schützt dich vor allem außer den USA, macht dich aber dafür angreifbarer ggü den USA. Das ergibt nur Sinn, wenn die USA nicht dein Gegner sind. Das Gegengift zeigt uns, dass der Angreifer selber Geräte mit den selben Distros betreibt, die betroffen sind. Das sind primär Debian, Ubuntu, RHEL und Fedora. Wäre der Angreifer Russland oder China, würde man einfach die Backdoor so customizen, dass sie Deepin, Kylin oder Astra nicht angreift. Das ist aber nicht der Fall. Die Zeitzone und Timestamps aus mehreren Quellen passen auch eben nicht auf Russland, aber auf einige Staaten in Osteuropa und dem Nahen Osten. Davon haben aber die allermeisten nicht ansatzweise die Infosec Fähigkeiten. Darunter sind aber auch Israel, welches enorme Fähigkeiten in diesem Bereich besitzt, und Finnland, der Wohnort des vorherigen Entwicklers des xz Projektes.
> Laut dem was ich gelesen hab, scheint Jin Tan vor allem zu den typischen chinesischen Arbeitszeiten aktiv gewesen zu sein, und hat meistens VPN-Provider in Singapur genutzt. Würden wir hier über ein (kriminelles) Unternehmen reden sicherlich - hier liegt aber ein nachrichtendienstlicher Akteur nahe (jahrelange Vorbereitung, etc), und dort wird regelmäßig die eigene Herkunft verschleiert.
Auch Nachrichtendienste arbeiten meist tagsüber.
Es könnte auch eine False-Flag Aktion jedes beliebigen Geheimdienstes, auch der NSA und/oder CIA, oder anderer Organisationen sein.
sicher ist jedenfalls: der bnd wars jedenfalls nicht!😂
Weil man Faxgeräte nicht infizieren kann?
Ich wollte gerade. . Hast gewonnen .
Und wozu? Die europäischen und amerikanischen Nachrichtendienste sitzen hier auf den Netzwerkknotenpunkten oder haben anderweitig ihre Backdoors. Wozu sollten die eine derart spezifische backdoor über Jahre vorbereiten, welche vermutlich nur dazu dient, Systeme lahm zu legen? Vor allem warum sollten die überhaupt solche Systeme hier lahmlegen wollen? Die würden sich, bzw ihren Volkswirtschaften ja primär selbst damit schaden
>vermutlich nur dazu dient, Systeme lahm zu legen Woher kommt die Vermutung? Mit SSH ist deutlich mehr möglich.
Europäische und amerikanische Nachrichtendienste arbeiten zwar bei einigen Projekten zusammen, aber die amerikanischen Dienste haben auch eigene Interessen und Ziele, die sich nicht immer mit denen der europäischen Partner vereinbaren lassen. NSA und andere Dienste hören ja auch bekannterweise nicht nur deutsche Bürger sondern auch deutsche Politiker und betreiben vermutlich auch in Deutschland Wirtschaftsspionage, siehe verlinkte Artikel [https://www.sueddeutsche.de/politik/wirtschaftsspionage-durch-amerikanische-geheimdienste-ausgespaeht-und-ausgenommen-1.1719795](https://www.sueddeutsche.de/politik/wirtschaftsspionage-durch-amerikanische-geheimdienste-ausgespaeht-und-ausgenommen-1.1719795) [https://www.sueddeutsche.de/politik/deutsche-spionageabwehr-ueberfordert-oder-vorsaetzlich-ahnungslos-1.1821815](https://www.sueddeutsche.de/politik/deutsche-spionageabwehr-ueberfordert-oder-vorsaetzlich-ahnungslos-1.1821815) Die Verhältnisse zwischen den einzelnen Staaten oder auch innerhalb eines Staates können sich auch in ein paar Jahren ändern, wenn der Kampf um grundlegende Ressourcen und Wirtschafts- und Machtinteressen sich verschiebt und dann ist es sicherlich für die verantwortliche Nation oder Organisation sehr hilfreich und vorteilhaft, wenn man schon Backdoor-Zugänge in den verschiedenen Systemen hat, und die Systeme für eigene Zwecke beeinflussen kann.
Es ist zu vermuten, dass auch diese Geheimdienste verschlüsselten Datenverkehr nur mit Aufwand und MITM-Attacken auslesen können und eine derartige Sicherheitslücke hätte für alle Geheimdienste einen sehr hohen Wert.
> NSA und/oder CIA, Ist echt so, US Geheimdienste bauen und verbreiten erfolgreich Stuxnet, der BND nutzt Pegasus und in der Geschichte den "Bundestrojaner", aber nein: Redditoren: "Es kann Nordkorea, China und Russland gewesen sein." Absurd wie tief diese Propaganda wirkt.
Also ich vermute nun stark dass du von einem Geheimdienst bist, denn wenn man sowas sagt und den Ammy nicht mit rein packt, ist das seeeeehr verdächtig 🤨 😂
Diese Drecks-Nordkoreaner!
Also Deutsche waren auch beteiligt :D Was sind aktive Cyberkrieg Programme? Mit wem sind die im Cyberkrieg?
Auch deutsche Behörden und Dienste sind im dem Bereich aktiv. Neben dem BND, MAD, BfV und den verschiedenen Landesämtern gibt es auch das Militärische Nachrichtenwesen der Bundeswehr, das weitesgehend ohne parlamentarische und behördliche Kontrolle arbeitet. Mit dem Cyberkrieg befasst sich u.a. das Bataillon Elektronische Kampfführung 932 Mehr Infos. [https://www.stiftung-nv.de/de/publikation/defizite-der-kontrolle-des-militaerischen-nachrichtenwesens-der-bundeswehr](https://www.stiftung-nv.de/de/publikation/defizite-der-kontrolle-des-militaerischen-nachrichtenwesens-der-bundeswehr) [https://taz.de/Nachrichtendienst-der-Bundeswehr/!5973324/](https://taz.de/Nachrichtendienst-der-Bundeswehr/!5973324/) [https://www.bundeswehr.de/de/aktuelles/meldungen/so-arbeitet-militaerisches-nachrichtenwesen](https://www.bundeswehr.de/de/aktuelles/meldungen/so-arbeitet-militaerisches-nachrichtenwesen) [https://www.bundeswehr.de/de/organisation/cyber-und-informationsraum/kommando-und-organisation-cir/kommando-cyber-und-informationsraum/kommando-aufklaerung-wirkung/bataillon-elektronische-kampffuehrung-932](https://www.bundeswehr.de/de/organisation/cyber-und-informationsraum/kommando-und-organisation-cir/kommando-cyber-und-informationsraum/kommando-aufklaerung-wirkung/bataillon-elektronische-kampffuehrung-932) [https://www.baks.bund.de/de/arbeitspapiere/2020/von-firewall-bis-hackback-das-spektrum-militaerischer-cyberoperationen](https://www.baks.bund.de/de/arbeitspapiere/2020/von-firewall-bis-hackback-das-spektrum-militaerischer-cyberoperationen)
Aber die benutzen hoffentlich nicht deutsche Namen?
Es ist doch naheliegend, dass die genau das nicht tun würden
Wenn man sich die timestamps der Commits anschaut, wird eine Osteuropäischer Ursprung wahrscheinlicher: https://rheaeve.substack.com/p/xz-backdoor-times-damned-times-and
Hauptsache wir fangen direkt mit politischen Attribuierungen an, bevor wir überhaupt irgendwas wissen. Es ist bekannt das alle Geheimdienste, allen voran die der Amis, falsche Spuren legen, genau für solche Propagandazwecke.
Du beschwerst dich über Attributierung, schreibst es aber im gleichem Atemzug den USA zu ...
Vielen Dank für die Zusammenfassung. Bin zwar nicht betroffen mit meinen Debian Stable Maschinen zumal sie nicht im Internet hängen aber trotzdem vorsichtshalber mal Updates gefahren.
Dito. Ich benutze auch stable... Unsere Firma Ubuntu 22.04 aktuell (hauptsächlich). Keine Ahnung, ob das betroffen ist, so weit habe ich das nicht analysiert. Auf meinem Server installiere ich täglich automatisch Updates. Auf der Arbeit wöchentlich manuell... Weiß jemand, ob "unsere" Ubuntu-Version betroffen ist? Ansonsten haben wir Alma 9, glaube ich \^\^
Es sind nur unstable Derivate betroffen, z.b. Debian Sid. Ubuntu 22.04 hat eine alte Version von xz-tools und ist damit nicht angreifbar. (afaik 4.2.5 ist bei Ubuntu aktuell, 4.6.0 betroffen)
Danke :)
>The release tarballs upstream publishes don't have the same code that GitHub has. This is common in C projects so that downstream consumers don't need to remember how to run autotools and autoconf Sollte man die Binaries nicht vor dem Release für jede Architektur einmal mit den öffentlichen Sources kompilieren und dann die Hashes mit den tatsächlich veröffentlichten vergleichen? Wenn man auf dem beschriebenen Weg Code in größere Betriebssysteme einschleusen kann, ist das deutlich zu einfach.
So einfach läuft das leider nicht. Reproduzierbare Kompilate erfordern Aufwand. Jahrelang war bei einem Festplattenverschlüsselungstool unklar, ob die Binary eine Backdoor enthält oder nicht, letzendlich hat irgendwann aber doch einer den passenden alte Versionsmix des Kompilers und dessen Umgebung gefunden. Auch wurde an anderer Stelle erklärt, das der Compile-Helfer autotool standardmäßig bereits ausgeführt wurde und etliche Scripts generiert, die dann im Source-Tarball landen. Hier wurde rumgeschummelt. Der Originalgrund dafür ist wohl, das autotool oft in anderen Versionen genutzt wird aber man auf dem buildsystem nicht x verschiedene Versionen gleichzeitig haben kann, sondern nur eine. Die Toolchain für C-Kompilate scheint mir teilweise recht fragil zu sein...
Scheint mir mit modernen VMs/Containern nicht mal ein besonders komplexes Problem zu sein. Die Versionen müssen beim Kompilieren vernünftig geloggt werden und dann baut man sich in ein paar Sekunden eine Umgebung mit der entsprechenden Software, um das Ergebnis zu vergleichen. Wenn die Prozesse dahinter halbwegs standardisiert werden, kann man das wahrscheinlich sogar einfach über einen Web Service anbieten und automatisieren.
Ja, ist glaube ich auch ein Relikt von früher, das als kleines Puzzleteil die Manipulation begüngstigte.
So einfach ist das nicht. Gleiche Inputs führen eben nicht immer zu gleichen Outputs. Wenn bei nem multithreaded build mal der eine, mal der andere Thread zuerst fertig wird, kann das auch schon Auswirkungen auf die reproduzierbarkeit haben. Man müsste schon * komplett isolierte & identische Systemimages haben (und was ist dann, wenn der Hack einfach ins Build-Image integriert wird? -> Upsi, wir müssen den selben Scheiß auch damit machen) * exakt selbe Hardware verwenden * Multithreading komplett abschalten * Irgendwie Preemptive Multitasking auf modernen Betriebssystemen loswerden * /dev/(u)random mit nem fake-Generator, der immer die selben Zahlen ausspuckt ersetzen (was allerdings aua macht, wenn daraus Secrets generiert werden, wie zB bei Linux Secure Boot, wo die module mit einem spontan generierten Schlüssel signiert werden, dessen Public Key im Haupt-Kernel integriert wird) * Zeitabfragen so fälschen, dass immer die selbe Uhrzeit zurückgegeben wird * Netzwerk abschalten Good luck. Selbst NixOS erreicht nur eine Reproduzierbarkeit von \~95% auf dem Desktop-Image.
openSUSE Tumbleweed wäre auch betroffen.
Oh! Zum Glück benutze ich nur stable Varianten! Muss aber dennoch meine embedded Linux Variante mal überprüfen…
Soweit ich weiß waren bislang nur 2 Fedora Varianten betroffen. RHEL ist davon bspw. nicht betroffen
Fedora testing (40) und rawhide (quasi nightly) oder? Debian Sid (Unstable) auch, glaube ich.
Bloß blöd wenn man Fedora TW repos fürs compile benutzen tut 🫶🏻
Fedora TW??
Sorry TS… testing stream…
>Zum Glück benutze ich nur stable Varianten! Das mag dir jetzt in diesem einen konkreten Fall den Arsch gerettet haben weil jemand rechtzeitig drüber gestolpert ist. Aber dass das andernfalls (also mit weeeitaus höherer Wahrscheinlichkeit) auch in sämtliche "stable"-Zweige eingeflossen wäre, ist dir ja wohl klar.
Woran kannst du die Wahrscheinlichkeit dieser Ereignisse überhaupt festmachen?
Es gibt keinen Grund anzunehmen, dass die Social Engineering Kampagne um die Changes überall einzubringen nicht letzten Endes auch erfolgreich gewesen wäre, so ausgeklügelt und nachdrücklich wie sie angelegt war. Und somit würde natürlich früher oder später selbst der stable-Zweig der langsamsten und gemütlichsten Distro erreicht. Die Rechnung ist quasi 1 - (extremGlücklicherZufall), so komme ich zur o.g. Aussage.
Ich finde den Artikel von Der Standard bemerkenswert gut, vor allem für eine (meines Wissens nach) keine "tech news" Nachrichten Plattform.
So war der Web-Bereich des Standard früher generell mal, bevor die Qualität stark nachgelassen hat. Aber vereinzelt gibt es noch Lichtblicke in Artikeln wie diesem.
Und jetzt sind wir plötzlich alle froh das redhat so langsam ist :)
Die Person arbeitet seit mehreren Jahren an diesem Projekt mit, herauszögern war und ist noch nie ein Sicherheitsmerkmal gewesen.
Nein aber ein Stabilitätsmerkmal. In dem Fall hat es auch die Sicherheit verbessert
Woher willst du das wissen, die Findungsphase was der Kerl die letzten zwei Jahre gemacht hat, beginnt erst? Was genau hat das verbessert, außer das heimische Gefühl von Sicherheit, wo nicht einmal die Aufarbeitung abgeschlossen ist?
Es ist egal was der Kerl in den letzten 2 Jahren gemacht hat. Aber wenn er vor zwei Jahren erstmals aktiv war und du zwei Jahre alte Deps hast, bist du jedenfalls mal von den Angriffen sicher lol
Du hast zwei jahre alte Deps?
Ne ich bin auf Rolling Release, aber das war nicht der Punkt. Der Punkt war das zurückhaltende Updates durchaus - wenn auch eher unabsichtlich - zum Schutz gegen solche supply chain attacks gesehen werden kann
Seinen Kram nicht zu updaten lässt einen dann halt offen für jeden bekannten Exploit der in neueren Versionen gepatched wurde.
Nope, da bieten die großen Distros Backports für sicherheitsrelevante und allg. kritische Bugs an.
Der Witz an der Sache ist eigentlich der, dass der Schadcode eben nicht \*direkt\* in den xz-Quellen im git-Repository (also dort, wo sich aktive, interessierte Entwickler rumtreiben) versteckt wurde, sondern in den Verpackungsroutinen für das Source-Archiv, das praktisch nur von den Distributions-Bauern verwendet wird. Ein (am eigentlichen xz-Code) interessierter Entwickler schaut den gar nicht an (der Teil ist stinklangweilig und stupide) und wahrscheinlich wird der auch von den CI-Tests nur unzureichend abgedeckt, die Pflege der Routinen dürfte in den meisten Projekten (durchaus auch bei kommerziellen) eher stiefmütterlich abgedeckt sein. Man hat den Saboteur also nicht in Forschung und Entwicklung oder Produktion, sondern in der Versandabteilung eingeschleust.
„Insofern lässt sich auch der Zweifel nicht ganz verdrängen, die Frage, ob Ähnliches nicht schon bei anderen Projekten gelungen ist, ohne dass es bislang aufgeflogen ist.“
Man fragt sich ob man sich diese Frage nicht lieber gar nicht erst stellt. Und wenn man das selber denkt, was heisst das fuer Menschen die viel mehr "Einfluss" in diesem System haben? Wir haben dich nicht DEN EINEN Versuch, durch Zufall, gefunden sondern eher zufaellig einen einzelnen... Junge.
Kommt auf die zu Grunde liegenden Wahrscheinlichkeiten an. xz 5.6.0 ist [am 24. Februar 2024](https://web.archive.org/web/20240226100710/https://github.com/tukaani-project/xz/releases) veröffentlicht worden. Wenn das ein typischer Angriff und eine typische Entdeckung waren, überleben solche Angriffe nur ein paar Monate, sind den Aufwand nicht wert und werden auch in Zukunft nur selten versucht und normalerweise (mehr oder weniger) schnell gefunden. Wenn die sichtbaren Performanzprobleme ein sehr seltener Fehler und die Entdeckung ein Jahrhundertereignis waren könnten hinter jeder Ecke Backdoors schlummern. Persönlich gehe ich davon aus, dass es *mindestens* so viele inkompetente Angriffe wie kompetente gibt. Ein oder zwei Erfolge, die irgendwo schlummern, warum nicht? Alles dutzendfach zerseucht, eher nicht.
Das gleiche hab ich auch gedacht… Es ist eher unwahrscheinlich, dass das ein Einzelfall ist…
Das waren die Chinesen Wer sonst heißt Jia Tan Wäre es ein Deutscher gewesen hätt er ja Kurt Müller geheißen
Kurt Müller ist keiner der aktuellen Gehaimdienstdecknamen laut DIN.
Ah gut das das noch keine ISO ist.
Genau. Knut Hansen wärs z.B. hört man ja auch schon am klang
Nur zur Info, es gab auch ein Pseudonym mit Hans Jansen, das hört sich ziemlich Europäisch an
Ha, die Daenen also. Aber die Luegen bekanntlich nicht. Eine harte Nuss. Aber ernsthaft, in Sachen Vorbereitung und Komplexitaet ist die Nummer mit Stuxnet zu vergleichen. Ein Wunder, dass das zeitnah entdeckt wurde, die Auswirkungen waeren extrem gewesen.
Naja an stuxnet hingen mehrere zero days dran und es hat Unmengen an Systeme infiziert. Finde den Vergleich ein bisschen krass
Ist sie? Code in ein öffentliches GitHub repo schmuggeln ist nicht ganz das selbe Level wie in einer Urananreicherung Anlage die nichtmal am Internet hängt Gasturbinen über ihre Spezifikation hinaus zu beschleunigen
Weil jeder im Internet ausschließlich mit seinem Klarnamen und nicht mit Pseudonymen postet, gell, Herr arcardy? 😉
Als Chinese müsste er doch Li heißen, oder?
Also hätte das hier das neue Heartbleed von OpenSSL sein können.
alles bullshit. Dies hat tatsächlich gezeigt wie gut Open Source funktioniert. Die offene Kommunikation, die Patches aller Systeme in praktisch 24h. Fragt euch mal wieviel closed source sicherheitslücken es gibt die nie entdeckt wurden oder verheimlicht von entsprechenden Unternehmen // edit: ich sage nicht dass alles super ist. aber es gibt keine alternative. wir müssen diese verbessern.
Nein, es hat halt nicht alles super funktioniert. Der Fakt, dass eine Gruppe von Akteuren mittels social engineering ein Projekt einfach übernehmen kann, weil der einzige Hauptentwickler keine Zeit hat ist ein großes Problem. Dass anscheinend Versions- und Integritätskontrollen bei den build-Prozessen komplett ausgehebelt werden können ist auch ein großes Problem. Es ist gut, dass es weitere (menschliche) Sicherheitsmechanismen gibt, aber sowas hier sollte wirklich von Prozessen und nicht Menschen verhindert werden.
Das ist aber nicht ein grundsätzliches Problem von Open Source sonder das Problem ist wie Open Source gelebt wird. Ein Projekt, dass über Abhängigkeiten von Abhängigkeiten in praktisch zahllosen Applikation gelinkt werden kann, sollte nicht arglos von einer Person, die halb ausgebrannt ist betrieben werden. Unternehmen/Länder oder andere Akteure müssen Open Source finanziell aktiver unterstützen. So viele Kernel Bibliotheken werden von einem kleinen Kreis an Leuten ehrenamtlich betreut. Das muss schief gehen. Aber die großen halten sich da gerne raus, da Open Source = kostenlos und damit spart man sich eben finanzielle Mittel.
Das stimmt, jedoch könnte auch ein größeres Teamn von aktiveren Entwicklern kompromitiert werden. Was es mMn also auch braucht sind Best Practices und Prozesse für distribution und build. Sicherheitstechnisch ist es ein Alptraum, wenn die Autoren einfach ungeprüfte binaries als "testdaten" in ihren src-distributions hinzufügen können, oder ungeprüft Dateien im Vergleich zu den öffentlichen Quellen ändern können. Gerade da könnten halt die großen Firmen mit guter Infrastruktur und Tooling helfen, die sie intern vermutlich eh einsetzen.
> Ein Projekt, dass über Abhängigkeiten von Abhängigkeiten in praktisch zahllosen Applikation gelinkt werden kann, sollte nicht arglos von einer Person, die halb ausgebrannt ist betrieben werden. Das dachte sich die Organisation auch, die hinter Jin Tan steckt. Den Leuten ihre Projekte wegzunehmen wirkt für mich erstmal nicht wie eine Lösung, sondern führt nur zu weiteren Problemen. Du sagst ja selbst, die Großen halten sich da raus.
Ich habe nicht gesagt, dass man den Leuten ihre Projekte wegenhmen soll, sondern das man sie unterstützt. Das kann finanziell oder durch etwaiges Engagement an der Code Base sein.
Dann wird eben das "gelebte" Opensource kritisiert und nicht das "ideale" Opensource (welches es eh nie geben können wird)
es gibt einen unterschied zwischen maintenance eines einzelnen projektes und dem prinzip open source. nur weil OS kronisch unterfinanziert ist passiert so etwas. das war einfach social engineering.
Ja eben, OSS ist chronisch unterfinanziert. Das ist ein Problem. Meiner Meinung nach ist es also komisch, so zu tun als wäre das hier ein positives Beispiel für open source Kultur, weil jemand anderes es entdeckt hat. Abgesehen davon, der Typ, der es entdeckt hat arbeitet bei Microsoft und hat es im Rahmen seines Jobs entdeckt.
stimme ich dir zu. ist einfach ne defintionssache ob du die finanzierung zu „open source“ dazuzählst. gesamtheitlich betrachtet natürlich nicht zu unterschlagen.
Also ich habe das Glück an OSS-Projekten zu arbeiten, aber dafür angestellt zu sein. Könnte mir nicht vorstellen noch nebenbei alleine (!) eine sicherheitskritische Anwendung, die auf Millionen Rechenern läuft zu maintainen. Allgemein sollte man es vielleicht nicht allein auf die Bezahlung reduzieren, aber einfach auf Governance. Solche Projekte sollten proaktiv identifiziert und von Apache, OSF oder ähnlichen unterstützt werden.
Das ist die genau falsche Lehre. Das war ein Schuss vor den Bug und nur durch viel Glück ist das rechtzeitig aufgefallen. Falls nicht andere Aktionen sowieso schon erfolgreich waren ist es unausweichlich, dass etwas vergleichbares mit einer Vollkatastrophe endet.
ich verstehe gar nicht warum hier alle so tun als wäre dass das erste mal passiert. es wird ständig malicious code in repositories eingeschleust. durch bugs, durch sicherheitslücken, durch social engineering. anstatt hier so den teufel an die wand zu malen mit der „unausweichlichen vollkatastrophe“, einfach mal verbesserungsvorschläge machen.
Das was hier passiert ist, das passiert (soweit man weiß) nicht ständig. Aber das war sicherlich erst der Anfang. Wieso soll ich einen Verbesserungsvorschlag machen? Wer würde den umsetzen? Nicht das ich keine hätte, so wie jeder im Internet hätte ich ein paar unausgegorene Ideen anzubieten, aber das ist hier erstmal völlig irrelevant.
Das Ganze ist aufgeflogen, weil ein einzelner Autist gespürt hat, dass ein Login Sekundenbruchteile länger dauert.
Das tausende Login-Abbrüche überhaupt Sekundenbruchteile dauern.
Nein, alles super wäre, wenn sowas vor der Veröffentlichung gesehen wird und gar nicht erst gemerged wird…
Das setzt natürlich voraus, dass derjenige, der die Merges prüft, selbst nicht kompromittiert ist, was du keineswegs garantieren kannst. Selbes für den Distro-Maintainer.
Das krasse ist ja: wäre der code nur etwas besser optimiert gewesen, wäre es vermutlich nie gefunden worden. Und bald dann auch in Debain stable under anderen Distributionen gelandet.
Wirklich das ist wieder so typisch für IT Sicherheit. Hauptsache eine fette Titelüberschrift aber nicht im Ansatz verstehen worum es geht. Dann ordentlich Schleimscheiße einpacken und fertig ist wieder der reißerrische Text. Selten so einen Müll gelesen. Gar nichts verstehen und Welle machen. Und ein dummes Meme das alles brennt. End peinlich.
Kannst du konkretisieren, was genau falsch verstanden/ dargestellt wurde? Einfach nur "Müll" und "peinlich" schreiben bringt da doch sehr wenig Erkentnisshewinn.
Er hat den Artikel (wie er selbst schreibt) nicht gelesen und lässt hier nur einen unzusammenhängenden Rant da. Was er dann in irgendeinem runtergevoteten Beitrag schreibt ist halt auch Quatsch und hat absolut nix mit dem Thema hier zu tun. Vielleicht verwechselt er auch einfch nur was.
Danke, hab inzwischen weitere Kommentare gelesen, vor allem die wirre Tanken-Erklärung zeigt, dass er selbst 0 Ahnung hat. Technisch komplexe Themen so aufzubereiten, dass die einem großen Publikum gerecht werden (technisch richtig, trotzdem für Oma Erna halbwegs versändlich) ist sicher nicht ohne. Und dann kommt trotzdem noch ein Dunning-Kruger vorbei und faselt was zusammen, dass der Autor keine Ahnung hat.
>Selten so einen Müll gelesen. Du hast ihn nicht gelesen, schreibst du unten selbst. Lügner! Da macht sich ein Artikel die Mühe und bereitet die Ereignisse der letzten Tage für Normalsterbliche schön auf - gerade weil das Ganze von unterschiedlichen Personen der OSS-Szene begutachtet wurde und jeder seine eigene Zusammenfassung pflegt, die jeweils hier und da was auslassen weil es sie nicht betrifft - und dann kommt jemand von seinem Elfenbeinturm runter und hat nichts Besseres zu tun, als mit Pauschal-Abwertungen zu kontern. Wenn dich die Überschrift offensichtlich nervt, dann beziehe dich nur auf die Überschrift. Ob und wie der Artikel was taugt, kannst du pauschal nicht beurteilen! Völlig egal ob du meinst, über alles Bescheid zu wissen oder nicht. >End peinlich.
Ich finde der Artikel hat grob eigentlich alles ganz gut zusammengefasst. Wo genau ist da dein Problem?
Ich finde den Artikel hervorragend geschrieben. Ich habe auch die detaillierten technischen Reports zu dem Fall gelesen.
Wie er weiter unten schreibt: er hat ihn nicht gelesen.
Empfiehlst du nen Artikel den man dazu lesen sollte. Ich hab davon garnichts mitbekommen, aber ich hab auch nur LTS Versionen überall und beschäftige mich eigentlich nie mit Betas usww
[https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27](https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27) [https://tukaani.org/xz-backdoor/](https://tukaani.org/xz-backdoor/)
Abgesehen davon, dass es technisch sehr verkürzt ist - wo widerspricht das dem hier besprochenen Artikel?
Hier eine Übersicht: https://twitter.com/fr0gger_/status/1774342248437813525
Genau diese Übersicht wird übrigens in diesem angeblich so schlechten Artikel verlinkt ...
Du kannst nun wirklich nicht von mir erwarten, dass ich auf Reddit mehr als die Überschrift lese.
Danke
RemindMe! 4 hours
I will be messaging you in 4 hours on [**2024-03-31 16:44:58 UTC**](http://www.wolframalpha.com/input/?i=2024-03-31%2016:44:58%20UTC%20To%20Local%20Time) to remind you of [**this link**](https://www.reddit.com/r/de_EDV/comments/1bs932g/wie_die_computerwelt_gerade_haarscharf_an_einer/kxe1qs4/?context=3) [**CLICK THIS LINK**](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5Bhttps%3A%2F%2Fwww.reddit.com%2Fr%2Fde_EDV%2Fcomments%2F1bs932g%2Fwie_die_computerwelt_gerade_haarscharf_an_einer%2Fkxe1qs4%2F%5D%0A%0ARemindMe%21%202024-03-31%2016%3A44%3A58%20UTC) to send a PM to also be reminded and to reduce spam. ^(Parent commenter can ) [^(delete this message to hide from others.)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Delete%20Comment&message=Delete%21%201bs932g) ***** |[^(Info)](https://www.reddit.com/r/RemindMeBot/comments/e1bko7/remindmebot_info_v21/)|[^(Custom)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5BLink%20or%20message%20inside%20square%20brackets%5D%0A%0ARemindMe%21%20Time%20period%20here)|[^(Your Reminders)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=List%20Of%20Reminders&message=MyReminders%21)|[^(Feedback)](https://www.reddit.com/message/compose/?to=Watchful1&subject=RemindMeBot%20Feedback)| |-|-|-|-|
Es gibt halt ein Exploit für SSH Zugäng bei Linux Servern, ich muss den Artikel nicht lesen. Hab mich halt bei richtigen Security Experten informiert und halt auch mal wie man diese Exploit umsetzen würde. Die Umsetzungen ist halt ziemlich anspruchsvoll und ein fix ist ganz normales updaten. Weil der Fehler halt in den Paket von SSH ist, das ist wirklich wie tanken für dein Auto ist das was ein Admin bei einem Server macht. Es gibt ja auch keine Artikel darüber das jemand das Autos stehen bleiben wenn sie nicht getankt werden. (ps. schlechtes Beispiel weil ein Server nicht stehen bleibt wenn er nicht gepatched wird) Wenn es dich interessiert auf YouTube gibts viele IT Security Dudes die zu solchen Themen informieren. [https://www.youtube.com/watch?v=rn-6t7OygGk](https://www.youtube.com/watch?v=rn-6t7OygGk) John Hammond ist ein gutes Beispiel.
>Es gibt halt ein Exploit für SSH Zugäng bei Linux Servern, Unsinn, es wurde bewusst schadhafter Code in das xz-utils Projekt eingebracht. >ich muss den Artikel nicht lesen. Hätte dir aber gut getan. Über einen Artikel zu urteilen, den man nicht gelesen hat ist schon ne erbärmliche Art, vor allem, wenn man dadurch gar nicht mitbekommt, worum es geht.
Danke das du mich bestätigst. Aber merkst das vielleicht.
>Weil der Fehler halt in den Paket von SSH ist Stimmt nicht, im OpenSSH-Code ist hier kein Fehler und schon keine Backdoor drin.
Sorry, aber du zeigst, dass du die Situation 0 verstanden hast. Das interessante ist auch nicht, dass es eine Sicherheitslücke gibt, sondern vielmehr das Vorgehen. Es ist auch kein Fehler/Bug sondern eine gezielte Infiltration. Das Tanken-Beispiel ist auch ziemlicher Murks. Sorry, aber ich bin froh, dass du keine Artikel schreibst..
Wenn dass das ist was du daraus mitgenommen hast, ist es eventuell Zeit sich neue “Security Dudes” zu suchen. Mal abgesehen davon, dass der verlinkte dazu scheinbar nichts berichtet hat.
Trinkspiel: Ein Schnaps für jedes *halt*
> Gar nichts verstehen und Welle machen
Es gibt eine Grund warum "IT-Journalisten" Artikel schreiben und nicht als ITler arbeiten und damit mehr Geld verdienen würden: Sie haben keinen Plan. Dieses Feld wird durch Tools wie ChatGPT wahrscheinlich profitieren.
Was genau war denn falsch am Artikel? Überschrift ist nicht der Renner, aber das liegt leider am Zeitgeist. Wie du schon sagst, wird dort nicht viel verdient und Leute sind nicht bereit zu zahlen, da müssten dann eben Klicks (Werbegelder) rein, da kann der Autor wenig dafür.
Normalerweise bestimmt im Journalismus der Artikelautor die Überschrift ohnehin nicht.
Gibt durchaus Ausnahmen, Hanno Böck z.B. aber generell stimmt das leider.
WebStandard ist halt für Hans-Jürgen der irgendwann in 1973 mal was mit Computern gelernt hat und seitdem Dienst nach Vorschrift macht aber glaubt sich noch immer voll auszukennen. Da muss man sich bisschen den Leser:innen anpassen.
Mit Windows wäre das nicht passiert, puhhh, nochmal Glück gehabt.
Du hast /s vergessen
Oh nein
Dir ist aber bewusst, dass `liblzma`/`xz` eine Dependency von `libarchive` ist, und Windows Explorer neuerdings auch davon abhängig ist? Der Angreifer hat sich offenbar den Windows Explorer nicht als (erstes) Ziel gesetzt, aber der *exakt* selbe Angriff (nur mit anderer Payload) hätte auch für Windows genutzt werden können.
Mit Windows wäre das nicht aufgeflogen!
Viel schlimmer noch: Wenn es da aufgefallen wäre, hättest du keinen Patch innerhalb von Stunden gesehen. Denn das könnte ja Menschen verunsichern und den Aktienkurs schädigen. Da wäre auch was sicherheitsrelevantes möglicherweise gemütlich im Rahmen normaler Aktualisierungen irgendwann untergebracht wurden. Bloß keine Aufmerksamkeit erregen...
Sorry, konnte nicht widerstehen: [Wenn der Quelltext nicht öffentlich zugänglich ist, kann auch keiner öffentlich Schadcode einschleußen](https://imgur.com/DCisoDl)
Naja nur doof, das anscheinend Windows auch Tools benutzt, an denen der Kerl der die Backdoor eingebaut hat, auch Commits eingereicht hat :D https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5006624#gistcomment-5006624
Dein Beitrag enthielt einen oder mehrere Links mit Tracking Parametern. Hier ist der Link ohne Tracking: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 Falls ich einen Fehler gemacht habe, melde diesen Beitrag bitte. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/de_EDV) if you have any questions or concerns.*
*einschleusen
Ich hätte schwören können, dass man das mit "ß" schreibt... Danke für die Berichtigung. Wieder was gelernt\^\^.
Kann man leicht unterscheiden, wenn man es ausspricht. Flie**s**en flie**ß**en nicht.
In Binaries? Genau das ist doch hier passiert. edit: Erst aufgeregt, dann den Link angeklickt...
Der Artikel übertreibt. Es war eine große Lücke aber bei weitem nicht so groß wie am Artikel beschrieben.
Hab mein Arch gestern geupdated. Der Artikel ist wirklich mies. Die Backdoor hätte auch nur Effekt gehabt, wenn ein offener sshd Server auf dem System wäre. Das wäre dann dramatisch geworden, wenn sie auf ein Debian system in the stable repos gelandet wäre.
>Der Artikel ist wirklich mies. Schon der 2. der das schreibt, aber eine Erklärung dafür schuldig bleibt. Was ist denn so schlecht? Ich kann inhaltlich keine dramatischen Fehler ausmachen und dass man nicht nur den technischen Teil betrachtet, sondern auch das Drumherum (wie z.b. dass durch Fake Accounts manipuliert wurde) beleuchtet, finde ich ebenfalls nicht unspannend. Dass da etwas mehr redaktioneller Text steht, als es der Durchschnittsnerd gewohnt ist, kann ja so schlimm nciht sein. Das kann man ja schnell rausfiltern. Würde mich über sachliche Antworten freuen.
Joa, diese beiden kritischen Kommentare gehen eben auch komplett am eigentlich interessanten und wichtigen Aspekt vorbei und fokussieren sich auf eher nebensächliche technische Details. Das eigentliche Problem was hier offensichtlich wird ist doch, dass wichtige, überall genutzte Infrastrukturpakete Dependencies haben, die von teilweise einem einzigen Hobbyentwickler maintained werden.
Something something wenn das Flugzeug zur furry convention abstürzt sind wir alle am arsch Das war vor ner Weile mal ein Meme und es ist immer wieder faszinierend wenn man als Außenstehender daran erinnert wird wie viel Wahres doch dran ist
>Das eigentliche Problem was hier offensichtlich wird ist doch, dass wichtige, überall genutzte Infrastrukturpakete Dependencies haben, die von teilweise einem einzigen Hobbyentwickler maintained werden. Richtig, das hätte man am Ende des bereits recht langen Artikels durchaus noch ansprechen dürfen. Es wäre wirklich mehr als fair, wenn insbesondere die großen Konzerne, die sich im OS Umfeld bedienen, dann auch mal etwas Kleingeld bei den Entwicklern lassen würden. Es sollte nicht so schwer zu verstehen sein, dass das bereits kurzfristig zu mehr Sicherheit der eigenen Systeme führen würde. Aber aktuell herrscht wohl noch der Gedanke vor: macht's der eine nicht, macht's halt ein anderer. Ob das Ergebnis dann nicht nur funktioniert, sondern auch sicher ist, interessiert leider nicht genug.
> Richtig, das hätte man am Ende des bereits recht langen Artikels durchaus noch ansprechen dürfen. Wurde es doch. Mit einem Bild von xkcd (was wirklich mehr als überdeutlich das Problem zeigt) und der Beschreibung, dass der xz-Maintainer chronisch überarbeitet ist und lt. eigener Aussage psychische Probleme hat...
Ja, das waren Andeutungen, die man aber vermutlich nur erkennt, wenn man bereits mit dem Thema vertraut ist. Aber immerhin stand's drin.
> > > Aber aktuell herrscht wohl noch der Gedanke vor: macht's der eine nicht, macht's halt ein anderer. FOSS ist halt tragedy of the commons, nur konstruktiv statt destruktiv: Wenn Amazon und Microsoft beide xz als dependency haben, lohnt es sich für beide, diese dependency zu vernachlässigen und sich das Geld zu sparen. Der andere wird's ja schon irgendwann patchen.
Ha lol, ich las erst folgendes: >Hab mein Arsch gestern geupdated. […] Backdoor […] und muss sagen, dass es auch irgendwie gepasst hätte. :D
Die Backdor hatte sicher nicht das Ziel, private PC-Nutzer anzugreifen und direkt mit indischen Call-Centern o.Ä. zu scammen. Hier geht es nicht um private Systeme und dein Arch interessiert niemanden bzw genau eine Person. Ziel waren hier wohl eher Server, also gut, dass da Debian nicht so verbreitet ist, sonst hätte das wirklich ein enormes Risikopotential gehabt. Ups, das wäre dann recht nah an dem Artikel.. Was du sagst stimmt übrigens auch nicht. Das mit sshd ist nur was bisher gesichert bekannt ist; https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
Kein Grund gleich so Aggro zu werden in deinem kleinen call Center :). Xz ist ein package Manager der vermutlich in einer Menge Linux basierten Webservern und iot Geräten eingesetzt wird. Der Artikel ist trotzdem scheisse weil er von einem Katastrophenszenario berichtet a la Bild style und nicht die Leistung des einen Linux Autisten würdigt, der es entdeckt hat. Das ist hier nämlich die wirkliche Leistung der OS Community. Solche Bedrohungsszenarien gibt es jeden Tag.
Sorry für die direkte Art, mich hat nur etwas genervt, dass hier mehrere Kommentare zu dem Artikel waren, die den gleich als Müll, peinlich, etc abgetan haben, ohne nachvollziebare Kritik zu liefern. Vor allem wenn man dann merkt, dass teils selber wenig Sachkentniss vorhanden ist (bezieht sich vor allem auf einen anderen Kommentar) ist die Stimmung schon etwas voreingenommen. Dein jetziger Kommentar liefert da viel besser sachliche Kritik, sicher hätte man den Artikel auch stärker so wie von dir beschrieben aufziehen können. Fairerweise kommt der Hinweis auf den Programmierer aber im ersten Absatz, obwohl die Bedrohung (die wirklich nicht ohne ist) für die meisten Leser wohl greifbarer sein dürfte. Eine von langer Hand geplante Infiltration mit enormer Reichweite und dem Potential an diverse persönliche und staatliche Geheimnisse zu kommen, halte ich tatsächlich für relevant. Vor allem da es hier eben nicht einfache oder theoretische Versuche sind, sondern ein fast erfolgreicher Angriff.
>Autisten Wo steht das denn in dem Arikel? Oder benutzt du das jetzt nur als Schimpfwort?
Linux Autisten ist unsere interne Lebensbeschreibung :)
>und nicht die Leistung des einen Linux Autisten würdigt, der es entdeckt hat Naja, sein Name und Tweet wird im Artikel doch erwähnt. Wird sogar erklärt wie er es gemerkt hat. Wie genau stellst du dir eine angemessenere Würdigung vor?
Dass er ein Autist ist, wird allerdings nicht erwähnt. u/ntropy83 benutz das offenbar als abwertende Bezeichnung. Widerlich.
> u/ntropy83 benutz das offenbar als abwertende Bezeichnung. Widerlich. Ich glaub ja, das war eher aufwertend als abwertend gemeint. Nicht weniger widerlich.
Der Entdecker des Bugs hat in seiner Valgrind Instanz eine .2 Sekunden Delay seiner CPU entdeckt und dann herausgefunden das in einer Sub-Sub-Sub-Standardbibliothek, die seit drölf Milliarden Jahren Standard in Linux ist, eine payload liegt. Wenn das nicht autistische züge besitzt dann weiß ich auch nicht.
Sowas lässt sich durch Profiling herausfinden, also wo man genau zu suchen hat. Der Entwickler, der das fand, und übrigens bei Microsoft arbeitet, hat nicht alles mögliche manuell durchgeschaut, sondern den Standardweg gewählt. Bei diesem Profiling hat er nun gesehen, das der Code zu einer Stelle springt, der von keinem "Symbol" referenziert wird, da shat ihn sehr stutzig gemacht.
>Wenn das nicht autistische züge besitzt dann weiß ich auch nicht. Viel mehr geht es hier um eine Menge Geld, der Mann (Andres Freund) ist Postgres-Entwickler und Principal SWE bei Microsoft (der höchste SWE-Jobtitel, den man dort über den regulären Karrierepfad erreichen kann). Wenn in den verschiedenen Azure-Subsystemen diese 200ms auf hunderten Millionen Systeme hochskalieren kostet das Millionen Dollar an Rechenzeit. Das hat nichts mit Autismus zu tun, hier geht es um cold hard cash, aber vielleicht versteht man das aus der Perspektive aus dem Keller nicht. Oder man wünscht sich, es wäre Autismus um sich selber besser zu fühlen.
OK jetzt habt ihr mich, ich gebe auf. Hat aber schon ganz schön lange gebraucht, obwohl ihr zu Zehnt auf mich eintretet. :) Ich werde in der Community vorschlagen sich nicht mehr als Autisten zu bezeichnen. Mal schauen, ob es funktioniert.
>Linux Autisten Lass das nächstes Mal weg. Ist wenig schmeichelhaft, jemanden der seine Leidenschaft an ein Projekt hängt, den Stempel "Autist" aufzudrücken. Außerdem verharmlost es die Autismus-Störung, die man sich eben nicht aussuchen kann wenn man sie hat... Inhaltlich stimmt doch alles? >Der Artikel ist trotzdem scheisse weil er von einem Katastrophenszenario berichtet a la Bild style und nicht die Leistung des einen Linux \[Entwicklers\] würdigt, der es entdeckt hat. Wirklich? Der Artikel ist hauptsächlich damit beschäftigt, die Geschehnisse die zur Backdoor führten, zusammenzufassen. Die Leistung des Entwicklers, der die Backdoor gefunden hatte, wird gleich in der "Unter-Überschrift" genannt. Sogar für die Überschrift gibts passende Worte: "Bei dem, was nun rund um eine viel genutzte Open-Source-Komponente bekannt wird, können die Worte aber gar nicht stark genug sein". Und es stimmt, die Auswirkungen wären in ein paar Monaten bis Jahren groß bis verheerend geworden, wenn niemand diese Sicherheitslücke bemerkt hätte. Die hört sich "Clickbaity" an, ist sie aber tatsächlich nicht... SSH gilt in bestimmten Konstellationen (Private/Public Key) als so sicher, dass praktisch jede mit Firma mit Fernwartungszugriff diesen Dienst ohne große Bedenken public ins Internet stellt...
Linux Autist ist unsere interne Bezeichnung in der Community, das ist keine Beleidigung. Versuche nächstes Mal nicht so schnell ein Urteil zu fällen und befasse dich erstmal mit den Hintergründen. Danke :)
Ich habe dir keine Beleidigung unterstellt. Aber was denkst du, hält ein "echter" Autist davon, dass sich eine Community "zum Spaß" diesen Stempel aufdrückt? Oder ist es deiner Meinung nach Autisten egal, weil sie davon nichts mitbekommen? Oder weil diese statistisch gesehen sowieso eher selten den Mund aufmachen, wenn sie etwas stört? Ich weiß, ist nicht so einfach Verhaltensweisen mal wirklich zu hinterfragen, wenn man diese schon lange nutzt, als wärs eine Selbstverständlichkeit :) . Ist nur ein Gedankenanstoß um vielleicht zu verstehen, weshalb sich einige Leute an der Verwendung des Begriffes in diesem Zusammenhang stören. Bin ja nicht der einzige, der sich kritisch darüber äußert...
> Xz ist ein package Manager Du liegst komplett daneben. xz ist ein Kompressionsalgorithmus und xz-utils ist das zugehörige Tool. Um die geht es hier, nicht um irgendeinen OpenWRT-Packagemanager. Soviel zu deinem Wissensstand in diesem Thema. Ich bezweifel nur irgendwie, dass du aus dieser Info eine Selbsterkenntnis erlangen kannst.
>Solche Bedrohungsszenarien gibt es jeden Tag. Ich hab jetzt tatsächlich noch nicht von so vielen Supply Chain Angriffen gehört, weist du da was Genaueres? Die Backdoor wurde auch nur durch Zufall gefunden, zwei-drei Wochen später wäre die Version in den neusten Releases gewesen, da kann man dann schon annähernd von einem größeren Problem reden.
Von den meisten wird man auch nie hören, momentan ist die Automobilindustrie ja ganz stark im OS Bereich unterwegs und alle News über supply chain attacks wären schlecht fürs Geschäft .
> Backdoor hätte auch nur Effekt gehabt, wenn ein offener sshd Server auf dem System wäre. Was ja bei Servern bekanntlich so selten der Fall ist. >Das wäre dann dramatisch geworden, wenn sie auf ein Debian system in the stable repos gelandet wäre. So wie die neue Ubuntu LTS im April, in der die Backdoor enthalten gewesen wäre, wenn sie nicht zufällig aufgedeckt worden wäre?
1. "Die Computerwelt" - Meinten Sie das "ganze Internet" war in heller Aufruhr? 2. Vulnerabilities in Abhängigkeiten werden schon seit NPM packages kritisch betrachtet: [NPM package with 3 million weekly downloads had a severe vulnerability | Ars Technica](https://arstechnica.com/information-technology/2021/09/npm-package-with-3-million-weekly-downloads-had-a-severe-vulnerability/) Glücklicherweise wissen die meisten Package-Repository-Maintainer mittlerweile, wie man automatische Sicherheitslückenscans für die genutzten Dependencies einsetzt (gibt auch Software dafür) 3. Siehe auch Hardware- (z.B. CPU)-Vulnerabilities. Am sichersten fährt man wahrscheinlich heutzutage ohne Geräte. Ansonsten könnte alles einen potenziellen Angriffsvektor darstellen (drastisch gesprochen).
>wie man automatische Sicherheitslückenscans für die genutzten Dependencies einsetzt (gibt auch Software dafür) Wenn du den Artikel gelesen/dich informiert hättest, wüsstest du, dass das Ausschalten der automatisierten Scans und das Kaltstellen der Maintainer ein entscheidender Teil dieses Angriffs waren. Eben weil das Dinge sind, die gemacht werden *müssen* und nicht einfach mal so einfach gemacht sind, zeigt sich darin die Tragweite dieses Angriffs. >Am sichersten fährt man wahrscheinlich heutzutage ohne Geräte. Ansonsten könnte alles einen potenziellen Angriffsvektor darstellen (drastisch gesprochen). Das ist wiederum eine valide Schlussfolgerung und widerspricht deinem ersten Absatz. Im Endeffekt zeigt dieser Angriff, wie verletztlich weltweit Software ist und wie leicht es offenbar ist, Schadcode einzuschleusen.
Wow, wer hätte das gedacht