Backdoor in xz/lzma

[fezie]

https://www.openwall.com/lists/oss-security/2024/03/29/4

So eben wurde im Upstream Code von den xz utils eine Backdoor gefunden. Die wohl auf den sshd zielt.
Genaueres ist noch nicht so klar

Debian stable is safe aber unstable/testing nicht...

[Exxtreme]

Hier gibt es mehr Infos:
https://news.ycombinator.com/item?id=39865810

[Marscel]

Die tl;dr-Version davon, und ob man vielleicht betroffen sein könnte: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

Wobei spannender als der Exploit das ganze Setup und Social Engineering die ganze Zeit davor zu sein scheint.

[Badesalz]

Wieviele solche Storys laufen noch unter dem Radar? 3? 4? 8?

[fezie]

War schon seit 2 Jahren geplant und jetzt erst zufällig aufgefallen.
Trotz Open Source. Hmm

[Badesalz]

Ja da erzählt der fefe bis auf den Einzeiler bisher nicht soviel von :wink:

[Exxtreme]

Hier noch ein Artikel, der das sehr gut zusammenfast:
https://www.derstandard.at/story/3000000213960/wie-die-computerwelt-gerade-haarscharf-an-einer-sicherheitskatastrophe-vorbeigeschrammt-ist

[The_Invisible]

Die tl;dr-Version davon, und ob man vielleicht betroffen sein könnte: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

Wobei spannender als der Exploit das ganze Setup und Social Engineering die ganze Zeit davor zu sein scheint.

Also eh nur BleedingEdge betroffen was man auf Server so eh nicht finden wird. Und selbst wenn wird hoffentlich niemand einen Public SSH betreiben...

[Badesalz]

@The_Invisible
Es sollte wohl auch nur der Fuß zwischen Tür und Rahmen werden.

[Marscel]

Also eh nur BleedingEdge betroffen was man auf Server so eh nicht finden wird. Und selbst wenn wird hoffentlich niemand einen Public SSH betreiben...

Joa, praktisch gerade noch gut gegangen.

[Badesalz]

Die Aufarbeitung bei fefe weiterhin recht mager :D

[Ganon]

War schon seit 2 Jahren geplant und jetzt erst zufällig aufgefallen.
Trotz Open Source. Hmm

Naja, der tatsächliche Schadcode ist erst seit ~3 Wochen im Projekt enthalten. Aber selbst der war nicht im git selbst, sondern in den tarballs, die separat erstellt wurden. Dann war der Täter Co-Maintainer vom Projekt. Es ist ja nun nicht so als hätte jemand ein drive-by pull request mit Schadcode blind angenommen.

Es ist mMn schon etwas übertrieben, wenn man hier erwartet, dass jemand irgendwas hätte früher erkennen sollen. Man hätte sicherlich an diversen Stellen misstrauisch werden können, aber dann müsstest du am Ende jedem Maintainer jeden Projektes misstrauisch gegenüber stehen und dann kommst du am Ende auch nicht voran.

Eine gewisse "Chain-of-Trust" ist auch im Open Source Umfeld vorhanden und das wird man auch nicht ändern können bzw. wollen.

[aufkrawall]

Was heißt "separat erstellt"? Waren die auf GitHub und sahen so aus, als wären sie einfach aus einem Tag gepackt worden? Wenn ja, ist das ja völliger Wahnsinn bez. der Sicherheit und es kann immer aller möglicher BS drin sein. :freak:

[Ganon]

Was heißt "separat erstellt"? Waren die auf GitHub und sahen so aus, als wären sie einfach aus einem Tag gepackt worden?

Ja. Aber so ist das halt. Wenn du Maintainer des Projektes bist, kannst du am Ende machen was du möchtest.

[aufkrawall]

Dann kann die Schlussfolgerung daraus für Maintainer eigentlich nur sein, Tarballs zu ignorieren und nur noch die Tags direkt über Git zu klonen.

[Ganon]

Dann kann die Schlussfolgerung daraus für Maintainer eigentlich nur sein, Tarballs zu ignorieren und nur noch die Tags direkt über Git zu klonen.

Das ist ein Weg ja. War ich prinzipiell auch immer dafür, erzeugt aber auch wesentlich mehr Traffic auf der Leitung, weil tarballs in der Regel wesentlich besser komprimiert sind. Deswegen wurde immer darum gebeten die tarballs zu nehmen. Ist am Ende nur eine winzige Milderung, weil ein "böser Maintainer" hat auch abseits davon genug Möglichkeiten dir etwas unterzujubeln.

Besser wäre sowas wie die Durchsetzung von Reproducible Builds. Da würde man relativ leicht erkennen, wenn git build und tarball build sich unterscheiden. Über die ganze Auslieferungskette hinweg.

[aufkrawall]

Das ist ein Weg ja. War ich prinzipiell auch immer dafür, erzeugt aber auch wesentlich mehr Traffic auf der Leitung, weil tarballs in der Regel wesentlich besser komprimiert sind.
Die Aktualisierung für ein bereits geklontes Repository ist ja auch nur inkrementell.

[Ganon]

Die Aktualisierung für ein bereits geklontes Repository ist ja auch nur inkrementell.

Würde aber verlangen, dass du von allen Projekten im Ökosystem die komplette Entwickler-Historie spiegelst. Das mag gehen, wenn du nur ein paar Projekte als Paket rausbringen willst. Für größere Systeme mit automatisiertem Build-System der gesamten Distribution, sind das nicht gerade kleine Anforderungen.

Und am Ende musst du dann trotzdem dem downstream Maintainer der Distribution vertrauen, dass der keinen Mist baut (ob nun absichtlich oder aus versehen). Wäre ja nun auch nicht das erste Mal, dass sowas passiert.

Von daher am Ende keine wirklich wirkungsvolle Lösung.

[Marscel]

Github bietet Tarballs der Release-Tags an, ohne dass man als Maintainer dafür oder dagegen was unternehmen kann.

Der Schlaumeier war aber so gut, in einer der README-Dateien gesondert zu erwähnen, dass man die mangels custom Signatur oder so ignorieren sollte. :ugly:

[aufkrawall]

Würde aber verlangen, dass du von allen Projekten im Ökosystem die komplette Entwickler-Historie spiegelst. Das mag gehen, wenn du nur ein paar Projekte als Paket rausbringen willst. Für größere Systeme mit automatisiertem Build-System der gesamten Distribution, sind das nicht gerade kleine Anforderungen.

Ich würde mal annehmen, dass die Paket-Maintainer der seriösen Distributionen das schultern können. Wo sollen denn da nur für den Master-Branch mit clone depth 1 riesige Datenmengen entstehen? :confused:

[BlacKi]

ich fand ja den social engineering part viel geiler.

hacker fragt maintainer x mal: hey, update mal.

maintainer: keine zeit.

hacker: kein problem, mach ich für dich, gib mal rechte!

maintainer: hier die rechte, aber bitte keinen unfug anstellen bitte.

hacker: trust me bro:freak:

[Ganon]

Ich würde mal annehmen, dass die Paket-Maintainer der seriösen Distributionen das schultern können. Wo sollen denn da nur für den Master-Branch mit clone depth 1 riesige Datenmengen entstehen? :confused:

Da bist du bei Updates aber auch schon nicht mehr bei "ist nur inkrementell", abseits von dem Aufwand dahinter. Wie schon gesagt, klar, kannst du so machen. Shallow Clones machen die Build-Systeme in der Regel auch, wenn man ein git als Quelle hat. Nur keine Updates auf denen, da sie direkt danach wieder weggeworfen werden. Ist auch nicht sehr Cache-freundlich, etc. pp.

Und wie gesagt, der Weg geht immer weiter zu automatisierten Build-Servern bei den Distributionen und der Paket Maintainer selbst baut das Paket nicht selbst. Auch ArchLinux befindet sich auf dem Weg dorthin.

[Marscel]

Ich würde mal annehmen, dass die Paket-Maintainer der seriösen Distributionen das schultern können. Wo sollen denn da nur für den Master-Branch mit clone depth 1 riesige Datenmengen entstehen? :confused:

Man checkt für gewöhnlich nicht den Master aus als Distributor, sondern einen spezifischen Tag.

Aber ansonsten sollte ein eingegrenzter Git-Clone ugf. ähnlich sein, ja.

[aufkrawall]

Man checkt für gewöhnlich nicht den Master aus als Distributor, sondern einen spezifischen Tag.

Ja, gut. Die Release-Tags sind dann tatsächlich oft auf Basis eines Extra-Branches. Denke aber, dass mit Git ein neuer Release-Branch auch inkrementell aktualisiert bzw. gewechselt wird.

[HarryHirsch]

ist das dieser beta only non produktiv backdoor?

[Ganon]

Github bietet Tarballs der Release-Tags an, ohne dass man als Maintainer dafür oder dagegen was unternehmen kann.

Wie die Links ja oben erklären. In der Regel liefert der Maintainer abseits von dem github Zeug eigene tarballs aus mit gpg Signatur, vorkonfigurierten Autotools-Zeug etc. pp.

Das größte Problem an der Stelle ist einfach, dass der Maintainer selbst das Problem war. Die einzige Lösung, die in einem Fall wie diesem effektiv helfen würde ist, das Projekt nicht mehr zu benutzen. Wenn man dem Maintainer des Projektes nicht mehr trauen kann, hilft hinten raus schlicht nichts mehr.

[Marscel]

Wie die Links ja oben erklären. In der Regel liefert der Maintainer abseits von dem github Zeug eigene tarballs aus mit gpg Signatur, vorkonfigurierten Autotools-Zeug etc. pp.

Das größte Problem an der Stelle ist einfach, dass der Maintainer selbst das Problem war. Die einzige Lösung, die in einem Fall wie diesem effektiv helfen würde ist, das Projekt nicht mehr zu benutzen. Wenn man dem Maintainer des Projektes nicht mehr trauen kann, hilft hinten raus schlicht nichts mehr.

Hier haben wir aber ein paar Red-Flags, die wir dank Github enttarnen können: Wenns um seine Signatur gehen würde, hätte er die einfach als Zusatzartifact hinzupacken können, neben den Tarball.

Stattdessen ein zus. Custom-Package: Vorgekauter automake-Output? Find ich weird, weil man eig. diese Tools vorlaufen lassen kann und vorallem auch sollte, weil ich dem Maintainer einfach technisch nicht unbedingt zutraue, mir meinen Kram für meine Instanz soweit auszuliefern. Et voilá, war nicht reproduzierbar bzw. da kam ein komisches Diff raus, das wohl diese korrupte Binary aus den Testcases aktiviert.

Aber Ok, vielleicht steck ich auch zulange in der Welt vglw. überschaubarer/lesbarer CMake + reproducible Buildchains drin.

[Exxtreme]

WGekWFxeD6c

Die grundsätzliche Problematik ist aber schon immer bekannt gewesen.

[Ganon]

Aber Ok, vielleicht steck ich auch zulange in der Welt vglw. überschaubarer/lesbarer CMake + reproducible Buildchains drin.

Es sind halt Dinge, die hat man eben halt schon immer so gemacht. Klar hinterher ist man immer schlauer. Aber es ist ja nicht so, dass das alles niemand hätte befürchtet. Einen Push Richtung meson und weg von Autotools zieht sich schon seit Jahren durch viele Projekte. Ebenso Reproducible Builds verbreiten sich ganz langsam. Sind aber auch beides Sachen, die du nicht mal eben an einem Nachmittag umstellst und am Ende ist es auch eine Sache des Maintainers. Und der war eben hier "der Böse".

Es ist halt auch nicht hilfreich jetzt in Aktionismus zu versinken und dann das Problem dann als gelöst zu betrachten. Die "Chain of Trust" muss halt mal neu bewertet werden und eben auch dafür gesorgt werden, dass man dieses Vertrauen auch untermauern kann.

Weil egal wie, auch wenn du dich hin setzt und dir deine komplett eigene Linux Distribution erstellst, traust du am Ende immer den Maintainern der Projekte. Es gibt Dinge, die noch etwas abfedern können, zum Beispiel Flatpak, was Anwendungen in einer Sandbox ausführt und sogar in einer (Offline-) Sandbox baut. Aber am Ende ist xz an der Stelle ein "core" Tool, was dann doch eher direkt auf dem Host benötigt wird.

[Badesalz]

Ob das Problem größer ist als z.B. Cisco mit dem eigenen Staat hat?
Bei OpenSource kann das wenigstens noch gefunden werden. Bei ClosedSource muss es erst herausgefunden werden...

Das Wichtigste an der Story ist, daß jetzt alle "Maintainer" bei allen Projekten nach und nach ihre Blauäugigkeit und Naivität verlieren werden.

Bisschen peinlich dagegen finde ich aber, das es halt von der ClosedSource-Scene :wink: gefunden wurde :usweet:

https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/

[Ganon]

Bisschen peinlich dagegen finde ich aber, das es halt von der ClosedSource-Scene :wink: gefunden wurde :usweet:

Naja, die Person arbeitet zwar bei Microsoft, hat aber, als er das gefunden hat, an PostgreSQL gearbeitet. Dein Satz klingt so als hätte ein Sicherheitsexperte bei MS das Teil auditiert und dann gefunden.

[Ganon]

Für die Leute, die die Links oben nicht lesen: Nebenbei hat die Person auch mehrere Beiträge beim Libarchive Projekt gestellt: https://github.com/libarchive/libarchive/issues/2103

Die wurden jetzt auch erst mal alle nacheinander auditiert und ggf. Korrekturen vorgenommen. Aber schaut mal, wer vor einem Jahr libarchive mit ins System aufgenommen hat :ugly: https://www.heise.de/news/Microsoft-Build-2023-Windows-unterstuetzt-deutlich-mehr-Archivformate-9064045.html

[Badesalz]

Dein Satz klingt so als hätte ein Sicherheitsexperte bei MS das Teil auditiert und dann gefunden.Ich hätte das ohne den Link dabei natürlich anders formuliert :wink:

Nebenbei hat die Person auch mehrere Beiträge [...]Dazu dann:
"The bigger problem here is the possibility of other commits under other usernames with the same guise. Obviously no easy task, although a wider search would be advisable considering the possible implications."

Das wird schon nicht ein einziger Typ sein. Und sie werden unter dem Namen nicht überall die Eier gelegt haben. Man muss halt auch erstmal zeigen, daß man bisschen was kann und auch die Energie dazu.

[Lurtz]

Bisschen peinlich dagegen finde ich aber, das es halt von der ClosedSource-Scene :wink: gefunden wurde :usweet:

Peinlich ist eigentlich nur dein oberflächliches Geätze gegen OpenSource.

[Ganon]

Und sie werden unter dem Namen nicht überall die Eier gelegt haben. Man muss halt auch erstmal zeigen, daß man bisschen was kann und auch die Energie dazu.

Klar haben der/die nicht überall gleich Backdoors verteilt. Aber einige Sachen wurden schon wieder abgeändert / rückgängig gemacht. So wurde in libarchive, auf den ersten Blick, völlig grundlos einige safe_fprintf calls zu fprintf abgeändert.

Diese Änderung war in dem Kontext _auf den ersten Blick_ auch nicht schlimm von dem was getan wurde. Aber man hat es jetzt trotzdem doch lieber wieder auf safe_fprintf umgeändert.

Man weiß ja nie. Ohne Debian-Patches, die um drei Ecken sshd mit xz verheiraten wäre diese Backdoor auch nicht funktionsfähig gewesen. Wer weiß was dort bei libarchive vorbereitet wurde.

[Badesalz]

Klar haben der/die nicht überall gleich Backdoors verteilt. Aber einige Sachen wurden schon wieder abgeändert / rückgängig gemacht. So wurde in libarchive, auf den ersten Blick, völlig grundlos einige safe_fprintf calls zu fprintf abgeändert.Und der/die Maintainer fragten sich damals nicht was/warum/weswegen? Die haben alle den "Winkearm" oder wie? :|

Peinlich ist eigentlich nur dein oberflächliches Geätze gegen OpenSource.Du hast es ja auch einfach. Dein Tourette ist dir nicht peinlich, weil du halt nichts dafür kannst. Nur für die anderen ist es.
Ähnlich verhält sich das übrigens, wenn man blöd ist.

[Lurtz]

Du hast es ja auch einfach. Dein Tourette ist dir nicht peinlich, weil du halt nichts dafür kannst. Nur für die anderen ist es.
Ähnlich verhält sich das übrigens, wenn man blöd ist.
Ach Gottchen. 0/10.

[aufkrawall]

GitHub könnte ja auch einfach signierte Tarballs anbieten, und die Signatur wird aus dem Tag-Commit erstellt. Das wäre so einfach, dass es die Frage aufwirft, weshalb es das nicht schon längst gibt oder keine gängige Praxis ist? Alle doof?

[Ganon]

Klingt eher danach als wüsstest du nicht was eine Signatur ist. Was ist denn bei dir der private Key?

[aufkrawall]

Welche Rolle soll das spielen, wenn es nur darum geht sicherzustellen, dass in den Tarballs nichts drin ist, was nicht in der Git-History eindeutig sichtbar ist?

[Ganon]

Welche Rolle soll das spielen, wenn es nur darum geht sicherzustellen, dass in den Tarballs nichts drin ist, was nicht in der Git-History eindeutig sichtbar ist?

Und das stellst du wie sicher, wenn der private Key öffentlich einsehbar ist? :ugly:

[PatkIllA]

Welche Rolle soll das spielen, wenn es nur darum geht sicherzustellen, dass in den Tarballs nichts drin ist, was nicht in der Git-History eindeutig sichtbar ist?
Da kannst du auch einfach direkt git nehmen. Das ist durch die Hashes kryptografisch vor Manipulationen geschützt.

Hätte doch hier auch nichts genutzt wenn man es schaft was unbemerkt durch den Maintainer aufzunehmen oder gar selbst Maintainer zu werden.

[aufkrawall]

Hätte doch hier auch nichts genutzt wenn man es schaft was unbemerkt durch den Maintainer aufzunehmen oder gar selbst Maintainer zu werden.
Nö, weil der Inhalt der Tarballs hier nicht dem des Source-Repositorys entsprach. Sagt zumindest Ganon. Wenn das nicht stimmt, ist meine Idee natürlich hinfällig.

[PatkIllA]

Nö, weil der Inhalt der Tarballs hier nicht dem des Source-Repositorys entsprach. Sagt zumindest Ganon. Wenn das nicht stimmt, ist meine Idee natürlich hinfällig.
Meinst du den Tarball den SourceCode oder die Binaries?
Bei den Binaries besteht kein kryptographischer Zusammenhang zum SourceCode. Wenn du das sicherstellen willst dann musst du schon selbst kompilieren oder der Signatur vom Herausgeber trauen. Oder etwas weniger sicher dem parallel veröffentlichten Hash.

[aufkrawall]

Ich meine den Source Code, die Distributionsmaintainer laden den (meist) als Tarball für ihre eigenen Builds. Wer 3rd Party Binaries ausrollt, gehört direkt geteert und gefedert. :freak:

[Ganon]

ist meine Idee natürlich hinfällig.

Die ist hinfällig, vollkommen egal was hier der Fall ist. Es ergibt einfach keinen Sinn.

[aufkrawall]

Aha, dann kann man ja Hash-Überprüfungen und Signaturen einfach global abschaffen. Ergeben laut Ganon keinen Sinn, weg damit.

[Ganon]

Aha, dann kann man ja Hash-Überprüfungen und Signaturen einfach global abschaffen. Ergeben laut Ganon keinen Sinn, weg damit.

Ich merke schlicht nur, dass du keine Ahnung hast von was du redest :ugly: Weil das was du behauptest, habe ich auch nirgendwo gesagt.

[aufkrawall]

Dann erklär mal, wie der Schadcode in den Tarball reinkommt, wenn GitHub als Plattform sicherstellen würde, dass das nicht einfach irgendeine xbeliebige Herkunft hat.

[Ganon]

Erst erklärst du mir, wo der Sicherheitsgewinn ist, wenn du das Paket mit einem öffentlich einsehbaren Schlüssel signierst :ugly:

[aufkrawall]

Was willst du immer mit irgendeinem Schlüssel irgendeiner Person? Es geht um Github als Plattform ffs. Dein Argument ist in etwa so, dass https wertlos sei, weil auch verschlüsselte Verbindungen nicht ausschließen, dass auf der anderen Seite ein Krimineller ist.

[Ganon]

Was willst du immer mit irgendeinem Schlüssel irgendeiner Person? Es geht um Github als Plattform ffs. Dein Argument ist in etwa so, dass https wertlos sei, weil auch verschlüsselte Verbindungen nicht ausschließen, dass auf der anderen Seite ein Krimineller ist.

Ich zitiere dich einfach mal:

GitHub könnte ja auch einfach signierte Tarballs anbieten, und die Signatur wird aus dem Tag-Commit erstellt.

Und dein Text sagt mir: Du hast keine Ahnung von was du redest und du weißt nicht was eine Signatur ist. Du weißt nicht wie sie erstellt wird, du weißt nicht was man damit macht und du erkennst offensichtlich auch nicht den Sinn dahinter. edit: Und wie HTTPS funktioniert weißt du scheinbar auch nicht.

[#44]

Was willst du immer mit irgendeinem Schlüssel irgendeiner Person?
Er geht auf deinen Post ein. Du wolltest etwas signieren. Und etwas mit dem Tag-Commit.

Die Signatur des Tag-Commit ließe sich in jedes Tar packen. Macht also keinen Sinn.
Ist der Tag-Commit der Private Key, kann jeder damit jedes Tar signieren. Der Key wäre ja offen verfügbar. Auch sinnlos.

Also ja. Das Geschriebene macht keinen Sinn, bis du es näher ausführst.

[aufkrawall]

Komisch (oder auch nicht), dass du die Frage nicht konkret beantworten kannst.
Dann erklär mal, wie der Schadcode in den Tarball reinkommt, wenn GitHub als Plattform sicherstellen würde, dass das nicht einfach irgendeine xbeliebige Herkunft hat.


Die Signatur des Tag-Commit ließe sich in jedes Tar packen. Macht also keinen Sinn.

Natürlich ergibt das keinen Sinn, wenn die Signatur nur eine Person ausweist. Es ist völlig logisch, dass die Gültigkeit der Signatur von der Gültigkeit der Hash-Werte der Dateien im Repository für diesen Zweck abhängen muss...
Und die Signatur erstellt Github als Plattform, und nicht der Repository-Maintainer. Meine Fresse...

[Ganon]

Komisch (oder auch nicht), dass du die Frage nicht konkret beantworten kannst.

Weil du meine Frage zuerst nicht beantwortet hast, wie Github das anstellen soll.

[PatkIllA]

Dann erklär mal, wie der Schadcode in den Tarball reinkommt, wenn GitHub als Plattform sicherstellen würde, dass das nicht einfach irgendeine xbeliebige Herkunft hat.
Da hat doch niemand behauptet.

Github baut dir automatisch aus jedem Commit/Tag/Branch ein Archiv mit dem SourceCode.

[Badesalz]

@aufkrawall
Es machen sich aktuell GARANTIERT recht viele recht fitte Leute Gedanken über den Vorfall. Und wie man das zukünftig sicherer machen könnte. Das meiste wird wahrscheinlich die Maintainer betreffen. Thema Verhaltensweisen und Handling. Imho weniger technisch und mehr die soziale und psychologische Seite. Im ersten Schritt - dem nicht-technischen - also eher eine Art "Richtlinien". Im ersten halt.

Meinst du echt du findest jetzt innerhalb eines Fingerschnippels DIE technische Idee wie das sicherer geht? Ich hätte mich das nicht gleich getraut :wink: Und alleine mit der Technik löst man eben nicht gleich ein jedes Problem. Das glaubt man immer nur in technischgeprägten Foren. Am besten halt direkt noch und nöcher mehr Crypto drüberwerfen. Das wirds schon :usweet:

@Lurtz
Wow :rolleyes: Aber immerhin Stückchen besser als dein eigenes -2/10.

[][immy]

Gedanken, ja. Passieren wird aber nichts, weil kaum eine forma freiwillig Geld für open source Bibliotheken aus geben will. Kommt nicht gut in den Quartalszahlen an ;)
Und selbst das würde nichts verhindern, sondern vermutlich noch mehr Betrüger anlocken.

Das eine staatliche Behörde dahinter steckt glaube ich kaum. Die Betrüger sind heute genug organisiert um solche Langzeitpläne umzusetzen.
Richtig los ging das Thema ja schon bei dem colors Paket vor ein paar Jahren. Und der Entwickler hat sich da eher einen Scherz erlaubt um auf die Situation aufmerksam zu machen. Passiert ist wie so oft quasi nix.

[Badesalz]

Das Thema hätte jetzt aber direkt auch RHEL und/oder SLES betreffen können. Der Spaß geht wohl langsam vorbei. Oder andersrum: Erst richtig los. Vom Gefühl her jedenfalls.

Ich finde an einigen Stellen brodelt es nun kleinwenig...

[Exxtreme]

Wenn der Angreifer gleichzeitig ein Maintainer eines Projektes ist dann wird sowas echt schwierig. Da Maintainer weitreichende Rechte haben was in das Projekt einfliesst und wie das Projekt gebaut wird. Die Maintainer entmachten wäre vielleicht eine Möglichkeit. Aber dann läuft man Gefahr, dass die sich andere Hosting-Plattformen suchen. Mir fällt da auch nicht wirklich was ein, was man da machen könnte.

Zumal es wahrscheinlich auch nicht reichen wird an einer Stelle was zu ändern. Das ganze war wohl möglich weil Debian da krasse Sachen beim Bauen der Pakete macht. Hier müssten wiederum die Debian-Leute ran und das Bauen der Pakete entschlacken etc. Man wird also womöglich auch die Tools zum Bauen von Anwendungen ändern müssen etc.

[Ganon]

Github baut dir automatisch aus jedem Commit/Tag/Branch ein Archiv mit dem SourceCode.

Am Ende ist es wieder ein Chain-of-Trust Thema. Zieht man sich die Pakete von Github traut man zusätzlich zum Maintainer eben auch noch Github, dass bei denen auch alles in Ordnung ist. Es gab vor Jahren auch mal Fälle, wo einige SourceForge Mirrors modifizierte Pakete ausgeliefert hatten.

Auch ein Branch und Tag ist kein unveränderlicher Teil von git. Kannst du jederzeit ändern, verschieben, löschen. Git commit hashes sind zwar aufgrund der "Blockchain" von git zwar gesichert, aber auch diese commits (wie auch Tags) müssen keinem Branch angehören. Sprich du könntest, je nachdem wo du den Hash her hast, gerade etwas nutzen was so nicht einfach öffentlich sichtbar ist.

Sprich ohne ständige manuelle Prüfung ist man hier auch immer einer Gefahr ausgesetzt etwas zu bekommen, was man nicht wollte. Dem Angriffsszenario aus der Richtung (wie gesagt, ist ja schonmal einmal passiert) geht man halt aus dem Weg indem der Maintainer selbst Pakete erstellt und sie signiert.

Ja nun... :D

Ist jetzt natürlich auch kein Thema "macht bisher keiner". Zumindest im Bereich Flatpak Packages ist das Pullen direkt aus dem Repo oder die Benutzung von github Packages mit Überprüfung des Dateihashes an sich die Norm. Aber es ist ja auch nicht jedes Projekt auf Github, wodurch das Laden von Packages von der Webseite des Maintainers natürlich auch vorkommt. Maintainer-Vertrauen ist dann hier auch etwas besser abzufedern, da das Zeug in einer konfigurierbaren Sandbox läuft. Ist aber natürlich prinzipbedingt nicht lückenlos.

Aber wie ich ja auch schon sagte, mMn sollte man das Projekt schlicht nicht benutzen, wenn man dem Maintainer nicht traut. Alles andere ist mMn recht sinnlos. Sehe da jetzt auch keine großartig andere Lösung, die nicht nach 5 Sekunden überlegen gleich wieder auseinander fällt.

[Badesalz]

Am Ende ist es wieder ein Chain-of-Trust Thema. Of trust? Es ist open source. Wäre doch mal schön, wenn da gelegentlich mehr als nur ein/der Maintainer drüber schauen würde. Oder?

edit:
fefe immernoch ganz schön stumm zum Thema :usweet:

[Ganon]

Of trust? Es ist open source. Wäre doch mal schön, wenn da gelegentlich mehr als nur ein/der Maintainer drüber schauen würde. Oder?

Welchen Open Source Software Code hast du dir denn die letzten Tage so angeschaut?

[PatkIllA]

Welchen Open Source Software Code hast du dir denn die letzten Tage so angeschaut?
Ich gucke schon mal gelegentlich in den Code von Bibliotheken oder .NET.
Aber auch nur um besser zu verstehen wie ich den besser nutzen.
Nach Sichereitslücken habe ich noch nie geschaut. Und eine gut versteckte Lücke würde ich wahrscheinlich auch nicht finden.

[The_Invisible]

Gibt nicht umsonst eigene Berufsfelder dazu die den ganzen Tag nix anderes tun, mit "nur mal drüberschauen" ist es nicht getan da die meisten Libs einfach zu groß/komplex sind und viele Lücken nur in Abhängigkeiten auftreten. Würde mir die Firma auch nie bezahlen.
Ich hoffe mal aber man hat daraus gelernt und die SecurityTeams der großen Konzerne werfen jetzt genau einen Blick auf solche "ein Mann" Projekte...

[Ganon]

Gibt nicht umsonst eigene Berufsfelder dazu die den ganzen Tag nix anderes tun

Schon. Die wollen im Regelfall aber auch dafür bezahlt werden. Google auditiert auch querbeet, aber es sind halt auch einfach mal Milliarden Zeilen an Code und tausende von Projekten und diese Zeilen ändern sich mit jedem Tag. Einfach zu erwarten, dass jede dieser Zeilen immer ausreichend und zeitnah auditiert ist, ist halt eine arg unrealistische Wunschvorstellung. Auch ist nicht jeder Software Entwickler ein Sicherheitsexperte.

Der Vorteil an Open Source ist, dass jeder den Code auditieren kann. Das heißt aber nicht zwangsläufig, dass das auch überall getan wird. Deswegen ist eine Chain-of-Trust halt auch im Open Source Bereich vorhanden.

Der große Unterschied ist: Wenn ich sage, dass eine bestimmte Software Sicherheitslücken/Hintertüren hat oder Spionage betreibt, dann hat im Closed Source Bereich keiner so wirklich die Möglichkeit etwas zu be- oder widerlegen. Ich traue dem Hersteller so ziemlich blind. Man erinnere sich an diverse Spyware die Spiele ausgeliefert hatten (z.B. Redshell) oder einige Anti-Cheat Software die praktisch Rootkits sind.

Im Open Source Bereich ist das eher möglich. Wie man hier ja sieht. Der Hersteller stellt den Quellcode bereit (auf die eine oder andere Art). Ich traue dem Hersteller zwar noch nicht 100%, aber schon einmal mehr, weil ich jetzt persönlich nachschauen könnte. Oder ich könnte jemanden damit beauftragen.

Aber sich einfach nur hinstellen und quasi sagen: "Das soll jetzt gefälligst jemand für mich kostenlos auditieren" ist eben auch quatsch.

Ich persönlich auditiere auch keinen Code, aber zumindest schaue ich z.B. bei von mir genutzten Flatpak Packages nach was die für Rechte haben, was sie mitliefern und prüfe ebenfalls nach, warum sich bei einem Update ggf. Sandbox-Ausweitungen ergeben haben (wird einem beim Update angezeigt). Da ist es aber auch verhältnismäßig einfach.

Oder tl;dr: Vertrauen ist gut, Kontrolle besser.

[Rooter]

Ich bin gespannt, ob dieser Wakeup Call genügt hat und jetzt bessere Best Practices für OSS entwickelt werden. Z.B. die FSF hat jetzt Arbeit und muss liefern.

Wäre doch mal schön, wenn da gelegentlich mehr als nur ein/der Maintainer drüber schauen würde. Oder?Da wäre schon mal ein guter Ansatz. Bevorzugt Leute aus z.B. zwei verschiedenen Ländern.

MfG
Rooter

[Hacki_P3D]

Fand den Artikel dazu auch ganz gut

https://dnip.ch/2024/04/02/xz-open-source-ostern-welt-retten/?utm_source=pocket-newtab-de-de

[sei laut]

[..]
Wäre doch mal schön, wenn da gelegentlich mehr als nur ein/der Maintainer drüber schauen würde. Oder?


Da wäre schon mal ein guter Ansatz. Bevorzugt Leute aus z.B. zwei verschiedenen Ländern.

MfG
Rooter
Zwei Länder sagt gar nichts über die Absichten eines Individuums aus. Am Ende müsstest du Persönlichkeitstests fordern.
Es ist übrigens kein Problem rein von Open Source, auch in Closed Source kann ein böswilliger Mitarbeiter wüten. In Open Source besteht nur die Chance, es leichter zu entdecken.
Daher finde ich die Diskussion etwas merklwürdig.Der Weg muss gehen weg von komplexen Software-Kartenhäusern und hin zu Software mit wenig Code und wenig Abhängigkeiten.

[Exxtreme]

Daher finde ich die Diskussion etwas merklwürdig.Der Weg muss gehen weg von komplexen Software-Kartenhäusern und hin zu Software mit wenig Code und wenig Abhängigkeiten.

Und genau das funktioniert nicht. Denn sobald ein Problem komplex ist, wird auch die Lösung für dieses Problem komplex sein. Denn wäre ein Problem nicht komplex dann hätte man das direkt in Hardware gelöst da das viel billiger ist. Und da Software sehr oft als Lösung für komplexe Probleme benutzt wird, ist diese auch komplex. Und damit ist man in der Situation, in der man heute ist. Und dafür sehe ich auch keine echte Lösung. Bzw. die Lösung wäre: alle komplexen Probleme abschaffen. Aber das ist sehr unrealistisch.

Und deshalb stochert man ständig an Symptomen von komplexer Software herum mt neuen Abstraktionen, neuen Frameworks, Bibliotheken etc.

[][immy]

Vor allem ist Chain of Trust quasi nicht möglich in einer Zeit wo man locker über 1000 Abhängigkeiten inkl deren sub-Abhängigkeiten hat. Irgendwo leidet da immer die Sicherheit.

[Badesalz]

Welchen Open Source Software Code hast du dir denn die letzten Tage so angeschaut?Du bist mir in all den Threads, all den Beiträgen und all den Jahren, noch nie mit Schwachsinn aufgefallen. Was ist denn da grad passiert? :freak:

Bin ich ein Teil der open source scene? Besteht die aus 100 Leuten weltweit? Die Typen die an der anderen Stelle safe_fprint gemacht haben, Gärtnern die jetzt, daß es einfach so an allen vorbeiging, als die Gauner das in fprint umgeschrieben haben?

Nein. Tatsächlich verstehe ich das nicht :usweet:

[Rooter]

Zwei Länder sagt gar nichts über die Absichten eines Individuums aus.Eben, EINES INDIVIDUUMS. ;) Wenn man zwei verschiedene Leute da zusammen drauf gucken lässt und beide müssen ihr okay geben, wird die Hürde schon deutlich höher. Natürlich auch nicht narrensicher, das gibt es ja eh nicht.

Und natürlich könnte man auch Firmen wie MS unterwandern. Alles eine Frage der kriminellen Energie.

MfG
Rooter

[samm]

Eben, EINES INDIVIDUUMS. ;) Wenn man zwei verschiedene Leute da zusammen drauf gucken lässt und beide müssen ihr okay geben, wird die Hürde schon deutlich höher. Natürlich auch nicht narrensicher, das gibt es ja eh nicht.Auf den Code schauen und komplett durchdenken, was da alles schief gehen oder ausgenutzt werden könnte, ist das Eine. Ist schon schwierig genug. Da wird auch bei zwei ultimativen Reviewern über Jahre erarbeitetes Vertrauen manchmal resultieren in einem "Jaja passt schon, ich versteh vielleicht nicht ganz alles aber hat ja nen Kommentar, der das erklärt".

Das Andere, was für xz wirklich geholfen hätte, wäre, alle Builds zwingend reproduzierbar zu machen und die dann auch als "Funktionalitäts-Reviewer" zu reproduzieren, dann auch ausführen und verdächtiges Verhalten messen. Hier wurd's ja nur wegen eines Unterschieds in der Performance bemerkt.

Und ich glaube, dieser zweite Punkt ist unrealistisch jemals erwarten zu können.

[Ganon]

Bin ich ein Teil der open source scene? Besteht die aus 100 Leuten weltweit? Die Typen die an der anderen Stelle safe_fprint gemacht haben, Gärtnern die jetzt, daß es einfach so an allen vorbeiging, als die Gauner das in fprint umgeschrieben haben?

Ist doch irrelevant was du dabei bist. Andere für ihre (ehrenamtliche) Arbeit zu kritisieren und mehr zu verlangen, ohne Bereitschaft dafür selbst etwas zu tun ist halt eben auch scheiße. Wenn man es selbst nicht kann und auch kein Interesse daran hat, dann sollte man vllt. einfach den Mund halten.

[Badesalz]

NEIN. Um "mehr zu verlangen" geht es da nicht. Und die Kritik galt nicht der Arbeit, sondern der Nichtarbeit. Dabei geht es auch nicht, daß es keinem in den ersten 2 Wochen auffiel.

Wenn das so abläuft wie es eben ablief, dann hat das ein strukturelles Problem. Das was ich meinte rein auf Personen zu spiegeln ist bisschen stumpf gedacht.

[Ganon]

sondern der Nichtarbeit.

Ja, wie ich ja sagte: z.B. die Nichtarbeit von dir.

[Badesalz]

My Lord...

Mit Grips, also mit Gegensatz zum Obigen, hättest du erstmal was gefragt. Schon weil alleine eine der Haupteigenschaften von Schlauen, die Neugier ist. Mit Grips hättest du gefragt was denn für "strukturelles Problem" ich meine und was ich denn meine wie man das lösen könnte (wenn ich schon der Meinung bin etwas zu dürftiges erkannt zu haben).

Und das auch garnicht mit der Erwartung nun eine Erleuchtung zu empfangen, sondern um überhaupt etwas zu haben was man bereden könnte, statt sich mit Personen zu beschäftigen...

Das ist aber eben nicht mehr so deine Eigenschaft, Neugierig zu sein. Dich interessiert das alles nen Shice. Dich interessiert nur deine maximal nasenlange Meinung dazu und deswegen bist du schon wieder auf Person runtergerutscht.

Und damit bist du aus meiner Meinungsbildung auch raus. Du bist halt nicht mehr austauschfähig.
Wegen der guten Texte und Themen der längst vergangenen Tage, als das alles noch nicht so feststellbar ansetzte, nenne ich es mal nicht gleich Starrsinn.

Bye bye.

[Ganon]

Wie ich es mir dachte. Außer Beleidigungen keine Argumente. Witzig, dass du den Text sogar noch mal editiert hast, um noch mehr Beleidigungen einzufügen.

Armselig.

[Badesalz]

:uclap:

[Exxtreme]

Offenbar gab es ähnliche Kaperversuche auch bei anderen Projekten:
https://www.heise.de/news/xz-Attacke-Hinweise-auf-aehnliche-Angriffsversuche-bei-drei-JavaScript-Projekten-9687246.html

[Badesalz]

:up: Na also! Es geht doch noch was in meine Richtung ;)

[Badesalz]

Jetzt werden erstmal alle möglichen Steine umgedreht. Gefällt mir :tongue:
https://www.bleepingcomputer.com/news/security/gitlab-affected-by-github-style-cdn-flaw-allowing-malware-hosting/

Und sonst so
https://openjsf.org/blog/openssf-openjs-alert-social-engineering-takeovers