Backdoor im "xz" package

[testperson 1.675]

Hi,

 

habe an anderer Stelle gerade den Hinweis bekommen, dass in "xz" eine Backdoor implementiert wurde. Auch wenn es nicht komplett hier her passt: oss-security - backdoor in upstream xz/liblzma leading to ssh server compromise (openwall.com)

 

Meldung von heise: Hintertür in xz-Bibliothek gefährdet SSH-Verbindungen | heise online

 

Hier noch eine (mögliche) Timeline: Everything I know about the XZ backdoor (boehs.org)

 

HTH

Jan

bearbeitet 30. März von testperson

[NilsK 2.932]

Moin,

 

es klingt wie "ätsch", aber bei solchen Meldungen stelle ich immer wieder fest, wie wenig das typische Open-Source-Argument zutrifft, dass der offene Entwicklungsprozess ja automatisch für Sicherheit sorge, weil niemand unbemerkt eine Beckdorf einschleusen könne.

 

Abgesehen davon - schätze ich es richtig ein, dass das nur Linux betrifft?

 

Gruß, Nils

PS. ich lasse die Autokorrektur Mai gewähren.

[testperson 1.675]

Unter Mac OS ist wohl der Paketmanager Homebrew mit der anfälligen Version betroffen. Bei den "großen" Linux Distros ist / waren wohl nur "unstable" / "test" betroffen. FreeBSD ist wohl nicht betroffen. Zu anderen *BSD habe ich auf die Schnelle nichts gefunden.

 

Alles was ich hier aus diesen Lagern in die Finger bekommen habe vermeldete:

xz -V
xz (XZ Utils) 5.2.5
liblzma 5.2.5

 

[MurdocX 949]

Sollte jemand eine aktuelle "Kali" Version haben, lohnt sich auch ein Blick. Sie ist mit betroffen.

 

Das ist vermutlich nur die spitze des Eisbergs.. 

[NorbertFe 2.032]

vor 4 Stunden schrieb NilsK:

wie wenig das typische Open-Source-Argument zutrifft, dass der offene Entwicklungsprozess ja automatisch für Sicherheit sorge, weil niemand unbemerkt eine Beckdorf einschleusen könne.

Dann greift aber sofort das Argument, dass man das dann nachträglich sofort fixen könne (wenn man es kann oder andere). ;)

[NilsK 2.932]

Moin,

 

es ist ja auch aufgefallen, aber eben erst hinterher. Vermutlich nicht so wild wie damals bei Heartbleed, aber schon eine harte Nummer. Am Ende ist der Punkt, dass moderne Software so komplex ist, dass man solche Angriffe gar nicht wirksam verhindern kann. Weder durch Closed noch durch Open Source. Mir schwant, dass das "mit KI" nicht besser wird, aber das würde dann jetzt wohl den Stammtisch eröffnen (hicks).

 

Gruß, Nils

 

[NorbertFe 2.032]

[cj_berlin 1.312]

vor 21 Stunden schrieb NilsK:

stelle ich immer wieder fest, wie wenig das typische Open-Source-Argument zutrifft, dass der offene Entwicklungsprozess ja automatisch für Sicherheit sorge, weil niemand unbemerkt eine Beckdorf einschleusen könne.

Das habe ich mich schon immer gefragt - wer denn bitte hat gleichzeitig

• das Know-How, einen C-Code gegenzulesen
• die Zeit, ein Projekt, das quasi jedes andere Projekt nutzt, nach jedem Release zu analysieren,
• und die Nerven, einen von anderen verfassten Code zu lesen?

Merken wir hier ja auch: *entdeckt* wurde die Lücke mit "normalen" Mitteln - jemandem ist ein anormales Verhalten aufgefallen, er hat den kompilierten Prozess profiliert und seine Findings dokumentiert. Der Umstand, dass es sich hier um Open Source handelt, führte lediglich im letzten Schritt dazu, dass Andres Freund selbst die endgültige Diagnose stellen konnte.

bearbeitet 31. März von cj_berlin

[testperson 1.675]

Hui: Filippo Valsorda: "I'm watching some folks reverse engineer the xz backdoor, sharing some *preliminary* analysis with permission. The hooked RSA_public_decrypt verifies a signature on the server's host key by a fixed Ed448 key, and then passes a payload to system(). It's RCE, not auth bypass, and gated/unreplayable." — Bluesky (bsky.app)

 

Zitat

...

Apparently the backdoor reverts back to regular operation if the payload is malformed or the signature from the attacker's key doesn't verify.

Unfortunately, this means that unless a bug is found, we can't write a reliable/reusable over-the-network scanner.

...

 

[NilsK 2.932]

Moin,

 

ja, auf heise.de gibt es eine ganz gute Übersicht der bisherigen Erkenntnisse. Sieht schon ziemlich "state-sponsored" aus bei dem Aufwand.

 

Gruß, Nils

 

[cj_berlin 1.312]

Kenne den Heise-Artikel nicht, aber von dem, was ich sonst gelesen habe (die wichtigsten wurden hier schon verlinkt), war der Aufwand im Sinne von insgesamt aufgewendeten Stunden ja nicht so wahnsinnig hoch. Es sind die Jahre, die es insgesamt gedauert hat, die mir hier großen Respekt einflößen - vor allem, da man nicht weiß, an welchen anderen überlasteten "Random Guys from Nebraska" bereits seit Jahren gebaggert wird. Aber rein ressourcentechnisch könnte es auch eine One-Man-Show gewesen sein. Spannend fand ich auch die Hinweise, dass es Ungereimtheiten in dem vermeintlich chinesischen Namen gibt. Aber da müssen wir wohl noch abwarten. 

 

Die ganze Diskussion nach "mehr Geld für Open Source-Entwickler", die wie immer sofort ausgebrochen ist, greift natürlich auch zu kurz. Es war ja nicht der Geldmangel, der Lasse Collin in die Arme des vermeintlichen Jia Tan trieb. Wenn wir etwas schaffen wollen, das dieses Szenario in Zukunft verhindern soll, muss es mit Maßnahmen einhergehen, die gerade in der Open Source-Community auf wenig Gegenliebe stoßen werden. Sowas wie eine Clearing- und Matchmaking-Plattfrom, auf der Klarnamenpflicht herrscht.

 

Was Hersteller von kommerziellen Produkten allerdings machen könnten, und die Plattformen geben es heute schon her, ist an die Maintainer der Projekte, die sie nutzen, herantreten und sagen:

• wir geben Dir X Geld jedes Jahr
• dafür wird ein Account von uns "kommerzieller Co-Maintainer"
• jeder PR wird bis 48h (können auch 72h sein) zurückgehalten, before er ge-merge-t wird. In dieser Zeit können alle kommerzielen Co-Maintainer einen Code Review vornehmen und mit Begründung rejecten. Wer das Recht innerhalb dieser Zeit nicht wahrgenommen hat, hat es für diesen PR verwirkt
• bei Übertragung der Maintainerschaft des Projektes hat jeder zahlende kommerziele Co-Maintainer ein Vetorecht

Oder sowas in der Art. Dadurch wird die Freiheit in der Software-Entwicklung nicht eingeschränkt, die Supply Chain aber geschützt. Und die Software-Firmen werden in die Pflicht genommen, nicht bloss einen finanziellen Beitrag zu leisten, sondern auch bei der Qualitätssicherung mitzuwirken. Schließlich bauen sie Produkte daraus, wo deren Name draufsteht  

bearbeitet 1. April von cj_berlin

[NilsK 2.932]

Moin,

 

Ja, Vorschläge dieser Art gibt es ja auch immer mal wieder. Die setzen aber natürlich auch einiges an Infrastruktur voraus, damit man nicht einfach mit 150 Dollar und einer Briefkastenfirma das System für sich ausnutzt.

 

Erschütternder finde ich den anderen Punkt, auf den du hinweist. Es ist ja durchaus wahrscheinlich, dass an anderen Komponenten und Entwicklern auch solche Leute dran sind, die nur darauf warten, dass sie ihr unbemerktes Tun in etwas umsetzen können, was ihnen nutzt.

 

Gruß, Nils

[mwiederkehr 373]

Hier eine schöne Zusammenfassung des Vorfalls: https://dnip.ch/2024/04/02/xz-open-source-ostern-welt-retten/

 

Der bösartige Code wurde nicht einfach ins Repository eingecheckt. Das kam schon vor, wenn die Zugangsdaten eines Entwicklers gestohlen wurden, aber es wird schnell entdeckt und ist nur sinnvoll bei Paketen, die vollständig automatisiert eingebunden werden (zum Beispiel bei Node.js). Stattdessen wurde der Schadcode in einer "Testdatei" untergebracht und von dort während des Buildvorgangs in den Code eingefügt. Der einzig verdächtig erscheinende Commit ist der mit dem angepassten Makefile-Template.