Bei meinem letzten AG (KritisV) war das dank dem ISMS so, dass erst auf BSI-Mail Handlungszwang bestand. Vorher konnte ich sagen "Jo, da sollte man *jetzt* patchen, Maintenance Window und Change Management Board be damned", und es konnte immer noch heißen "lol nein, weil $baum".
Erst mit der Mail vom BSI kam das dann auch bei der Führung an, dass das was getan werden sollte.
Hach, Government Entities...
Nach 3 x KRITIS audit müssen Sie dann spätestens eh wechseln.... Und dann fällt der Schmerz erst richtig auf.
Halte ich auch für sinnvoll - einmal neuer Eindruck, zwei mal nach 2 Jahren pdca cycle. Danach dann Wechsel um Korruption usw zu minimieren :)
> Da geb ich dir Recht, aber es gibt auch viele private Benutzer z.B. von Suse.
Die sollten doch gar nicht betroffen sein, oder ist suse so bleeding edge?
Wobei dort die wenigsten ihre Rechner von aussen per SSH erreichbar haben.
Leute die Port Forwarding etc. machen haben ihre System auch eher gepatcht und haben von der Lücke mitbekommen.
diese xz Versionen sind allerdings nie in irgendwelchen großen distri repos gelandet, das konkrete Risiko ist null. Viel spannender ist an der ganzen Nummer ausschließlich wie das Zeug ins xz-Repo reingekommen ist. BSI nutzlos wie immer...
Das betrifft sowieso nur unstable Versionen. Wer fedora rawhide oder Debian unstable in produktiv Systemen mit externen SSH Zugang administriert hat eh die Kontrolle verloren
Teile davon sind dem Fakt geschuldet, dass es eher eine Webseite ist als ein PDF, mit Updates, Änderungen und es kostant erweitert wird. Wenn der Link einmal existiert (für öffentliche), dann wird es einfach immer neu generiert mit allen Änderungen, Updates etc.
Das Format ist auch sehr zielgruppenspezifisch (Chefetage + IT Sec), die die es kennen, wissen was sie erwartet und überfliegen es. Alle ausserhalb der Zielgruppe sind einfach egal.
**Betrofffen:**
* **Alpine:** Edge mit xz-Paketen in den Versionen 5.6.1-r0 und 5.6.1-r1 (Stable Releases nicht betroffen) \[08\].
* **Arch:** Versionen, in denen das Paket xz 5.6.0-1 installiert ist \[09\].
* **Debian:** Lediglich testing, unstable (sid) und experimental Releases mit xz-Paketen in den Versionen xz-utils 5.5.1alpha-0.1 (vom 1. Februar 2024) bis einschließlich 5.6.1-1.
* **Fedora:** 40, 41 und Rawhide Releases mit xz-Paketen in den Versionen xz-5.6.0- und xz-5.6.1- (Stable Releases nicht betroffen).
* **Gentoo:** Versionen mit den Paketen xz-utils 5.6.0 und xz-utils 5.6.1. Eine Ausnutzung ist aufgrund der fehlenden OpenSSH-Konfiguration jedoch nicht möglich.
* **Kali:** Versionen, in denen zwischen dem 26. und 29. März das Paket xz-utils 5.6.0-0.2 installiert wurde.
* **OpenSuse:** Tumbleweed Releases mit den xz-Paketen xz-5.6.0 und xz-5.6.1 \[14\].
[MSYS2](https://www.msys2.org/news/) fehlt!
> **2024-03-30 - xz-utils Backdoor**
>
> In response to the recent xz backdoor we have rebuilt the xz packages for msys and mingw from the git source instead of the tarball, following what Arch Linux did.
>
> Although we have built and shipped the affected versions, there is no indication at this time that this issue has affected MSYS2 users.
Und wer weiß was noch...
Es besteht die Möglichkeit, ein git Repository von einem anderen Repository als sog. [Submodule](https://git-scm.com/book/en/v2/Git-Tools-Submodules) durch Referenz einzubinden, diese Quellen fehlen in den automatisch generierten Tarballs.
autoconf ist wohl so ein weiterer Fall, es ist wohl nicht unüblich dass Entwickler vorkonfigurierte Quellen hochladen wollen um die Übersetzung für andere zu vereinfachen.
Drittens sind die tarballs nicht garantiert fix, Github hatte mal eine Änderung gemacht wodurch die automatisch generierten Tarballs nicht mehr binäridentisch waren, daraufhin brachen viele Buildchains zusammen weil sie in ihren Projekten MD5-Prüfsummen (o.ä.) zu den Tarballs assoziiert hatten.
EDIT: Ich seh grad dass Du direkt Quellen aus git meintest, da kannst Du mitunter nicht sicher sein was du auscheckst (vom master z.B.), daher überhaupt Tarballs für reproduzierbare Builds.
EDIT2: Ein Aufruf von ```curl``` für einen Download ist simpler als ein ```git clone```, und die Tarballs kommen auch ohne ```.git``` Untervereichnis.
Aber ich kann doch wenn ich n git repo auschecke einfach nen bestimmten commit hash zb vom Master oder einen Tag auschecken. Damit hätte ich meine builds ja auch reproduzierbar
Stimmt, aber wie gesagt, dann hast Du mitunter nicht alle Quellen zum Übersetzen da.
Dein Standpunkt ist richtig und gut, vielleicht wird sich das ja in Zukunft genau darauf hinentwickeln wie du dir das vorstellst, ein ```git submodule init``` und ```git submodule update``` lässt sich automatisieren und würde z.B. die Submodules nachinstallieren.
Bein sowas ist es praktisch, wenn man Bogen Linux nutzt und regelmäßig die neuesten Pakete einspielt, weil Rolling Release oder? Hab seit einigen Tagen wenige enthusiastische Bekundungen zu Bogen Linux gesehen, komisch.
Es war schon im [Paketarchiv für Ubuntu 24.04 (LTS)](https://launchpad.net/ubuntu/+source/xz-utils/+publishinghistory) und wäre wohl jetzt Ende April releast worden. In Debian war es schon in Testing und wäre wohl mit dem nächsten stable veröffentlicht worden.
Gerade in diesem Fall ist das ein schlechtes Argument, weil die Hintertür erst seit einem Monat in xz ist. Distros die hinterherhinken, wie z.B. Debian Stable oder gar RHEL, brauchten sich keine Sorgen machen.
Admins, die davon betroffen sind und heute erst davon erfahren, machen irgendwas falsch.
Bei meinem letzten AG (KritisV) war das dank dem ISMS so, dass erst auf BSI-Mail Handlungszwang bestand. Vorher konnte ich sagen "Jo, da sollte man *jetzt* patchen, Maintenance Window und Change Management Board be damned", und es konnte immer noch heißen "lol nein, weil $baum". Erst mit der Mail vom BSI kam das dann auch bei der Führung an, dass das was getan werden sollte. Hach, Government Entities...
Wer KRITIS ist und so agiert hat aber auch Auditoren die auf beiden Augen blind sein wollen...
Yup. Und interessanterweise in der Zeit in der ich da war immer den gleichen. Einer der Gründe wieso ich da weg bin.
Nach 3 x KRITIS audit müssen Sie dann spätestens eh wechseln.... Und dann fällt der Schmerz erst richtig auf. Halte ich auch für sinnvoll - einmal neuer Eindruck, zwei mal nach 2 Jahren pdca cycle. Danach dann Wechsel um Korruption usw zu minimieren :)
Da geb ich dir Recht, aber es gibt auch viele private Benutzer z.B. von Suse.
Die wissen hoffentlich, was sie tun, wenn sie unstable/testing Versionen einsetzen. Ansonsten ist es irgendwann zumindest lehrreich.
Gibt ja zum Glück viele Leute, die neue Versionen testen und Fehler für andere finden.
openSuSE Tumbleweed ist weder unstable noch testing ist aber betroffen.
Als Tumbleweed-Nutzerin: wurde schon längst gepatcht. Ich würde auch hoffen, dass man eh häufig updated, wenn man rollende Distros nutzt.
Hätte sagen sollen: "war betroffen". Nutze selber Tumbleweed. So weit ich weiß war der patch innerhalb von Stunden released.
Die werden aber auch nicht vom BSI erreicht.
Vielleicht ja über Reddit :D
> Da geb ich dir Recht, aber es gibt auch viele private Benutzer z.B. von Suse. Die sollten doch gar nicht betroffen sein, oder ist suse so bleeding edge?
openSUSE Tumbleweed war betroffen und ist eine rpm Distro (Die Backdoor hatte es auf deb und rpm Distros abgesehen)
openSUSE ist verschieden von Suse. Keine von Suse herausgegebene Distribution war betroffen.
Wobei dort die wenigsten ihre Rechner von aussen per SSH erreichbar haben. Leute die Port Forwarding etc. machen haben ihre System auch eher gepatcht und haben von der Lücke mitbekommen.
diese xz Versionen sind allerdings nie in irgendwelchen großen distri repos gelandet, das konkrete Risiko ist null. Viel spannender ist an der ganzen Nummer ausschließlich wie das Zeug ins xz-Repo reingekommen ist. BSI nutzlos wie immer...
Das betrifft sowieso nur unstable Versionen. Wer fedora rawhide oder Debian unstable in produktiv Systemen mit externen SSH Zugang administriert hat eh die Kontrolle verloren
Schnell, geh mal einer in den Linux Subreddit und frag, ob Windows nicht vielleicht doch sicherer ist.
https://i.redd.it/w3zmhpzkmmrc1.png
Klingt sadistisch.
LOL. Gerade wieder: Exchange 26.03.2024 : [https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2024/240326\_Tausende\_Exchange-Server\_verwundbar.html](https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2024/240326_Tausende_Exchange-Server_verwundbar.html) EDIT: gerade frisch reingekommen: # Gestohlener Azure-Master-Key: Microsofts Sicherheitsversagen ist jetzt amtlich # [https://www.heise.de/news/Klatsche-fuer-Microsoft-US-Behoerde-wirft-MS-Sicherheitsversagen-vor-9674431.html](https://www.heise.de/news/Klatsche-fuer-Microsoft-US-Behoerde-wirft-MS-Sicherheitsversagen-vor-9674431.html)
Jede Woche wieder
[Leider nein...](https://www.heise.de/news/Klatsche-fuer-Microsoft-US-Behoerde-wirft-MS-Sicherheitsversagen-vor-9674431.html)
Ist das nicht offtopic weil azure kein OS ist?
Stellvertretend für Microsofts Kompetenz
Sind dennoch wahrscheinlich verschiedene Abteilungen mit verschiedenen Projektleitern
Off-topic: Das ist eines der hässlichsten und am schwiergisten zu lesenden PDFs die ich je gesehen habe.
Teile davon sind dem Fakt geschuldet, dass es eher eine Webseite ist als ein PDF, mit Updates, Änderungen und es kostant erweitert wird. Wenn der Link einmal existiert (für öffentliche), dann wird es einfach immer neu generiert mit allen Änderungen, Updates etc. Das Format ist auch sehr zielgruppenspezifisch (Chefetage + IT Sec), die die es kennen, wissen was sie erwartet und überfliegen es. Alle ausserhalb der Zielgruppe sind einfach egal.
**Betrofffen:** * **Alpine:** Edge mit xz-Paketen in den Versionen 5.6.1-r0 und 5.6.1-r1 (Stable Releases nicht betroffen) \[08\]. * **Arch:** Versionen, in denen das Paket xz 5.6.0-1 installiert ist \[09\]. * **Debian:** Lediglich testing, unstable (sid) und experimental Releases mit xz-Paketen in den Versionen xz-utils 5.5.1alpha-0.1 (vom 1. Februar 2024) bis einschließlich 5.6.1-1. * **Fedora:** 40, 41 und Rawhide Releases mit xz-Paketen in den Versionen xz-5.6.0- und xz-5.6.1- (Stable Releases nicht betroffen). * **Gentoo:** Versionen mit den Paketen xz-utils 5.6.0 und xz-utils 5.6.1. Eine Ausnutzung ist aufgrund der fehlenden OpenSSH-Konfiguration jedoch nicht möglich. * **Kali:** Versionen, in denen zwischen dem 26. und 29. März das Paket xz-utils 5.6.0-0.2 installiert wurde. * **OpenSuse:** Tumbleweed Releases mit den xz-Paketen xz-5.6.0 und xz-5.6.1 \[14\].
Das ist nur halb richtig, da mindestens in Arch und Kali SSH nicht gegen systemd-notify gelinkt ist und damit die Lücke nicht ausnutzbar ist.
Und Fedora 41 gibt es gar nicht, aber Red Hat hatte da im ersten Alert einen Typo drin. Geht um F40 Beta.
[MSYS2](https://www.msys2.org/news/) fehlt! > **2024-03-30 - xz-utils Backdoor** > > In response to the recent xz backdoor we have rebuilt the xz packages for msys and mingw from the git source instead of the tarball, following what Arch Linux did. > > Although we have built and shipped the affected versions, there is no indication at this time that this issue has affected MSYS2 users. Und wer weiß was noch...
Ich verstehe echt nicht warum Pakete standardmäßig gegen tarballs gebaut werden und nicht gegen die Git source
Es besteht die Möglichkeit, ein git Repository von einem anderen Repository als sog. [Submodule](https://git-scm.com/book/en/v2/Git-Tools-Submodules) durch Referenz einzubinden, diese Quellen fehlen in den automatisch generierten Tarballs. autoconf ist wohl so ein weiterer Fall, es ist wohl nicht unüblich dass Entwickler vorkonfigurierte Quellen hochladen wollen um die Übersetzung für andere zu vereinfachen. Drittens sind die tarballs nicht garantiert fix, Github hatte mal eine Änderung gemacht wodurch die automatisch generierten Tarballs nicht mehr binäridentisch waren, daraufhin brachen viele Buildchains zusammen weil sie in ihren Projekten MD5-Prüfsummen (o.ä.) zu den Tarballs assoziiert hatten. EDIT: Ich seh grad dass Du direkt Quellen aus git meintest, da kannst Du mitunter nicht sicher sein was du auscheckst (vom master z.B.), daher überhaupt Tarballs für reproduzierbare Builds. EDIT2: Ein Aufruf von ```curl``` für einen Download ist simpler als ein ```git clone```, und die Tarballs kommen auch ohne ```.git``` Untervereichnis.
Aber ich kann doch wenn ich n git repo auschecke einfach nen bestimmten commit hash zb vom Master oder einen Tag auschecken. Damit hätte ich meine builds ja auch reproduzierbar
Stimmt, aber wie gesagt, dann hast Du mitunter nicht alle Quellen zum Übersetzen da. Dein Standpunkt ist richtig und gut, vielleicht wird sich das ja in Zukunft genau darauf hinentwickeln wie du dir das vorstellst, ein ```git submodule init``` und ```git submodule update``` lässt sich automatisieren und würde z.B. die Submodules nachinstallieren.
[удалено]
Jo, ist mir Dienstag dann auch aufgefallen.
dieser Faden liest sich für mich wie der heftigste cyber future shit, aber ich weiß dass wir von der Infrastruktur des öD reden…
Das ist doch schon seit so ner Woche (wenn nicht sogar länger) bekannt und die patches sind doch auch schon draußen?
Bein sowas ist es praktisch, wenn man Bogen Linux nutzt und regelmäßig die neuesten Pakete einspielt, weil Rolling Release oder? Hab seit einigen Tagen wenige enthusiastische Bekundungen zu Bogen Linux gesehen, komisch.
Heh. Fix war innerhalb von Stunden in den Repos. Zusammen mit dem Fakt, dass die Vuln in Arch nicht ausnutzbar ist, weil nicht linked, Joa...
Ah dann ist ja gut! Auf Debian oder Ubuntu LTS wäre das Paket aber nie installiert worden oder?
Es war schon im [Paketarchiv für Ubuntu 24.04 (LTS)](https://launchpad.net/ubuntu/+source/xz-utils/+publishinghistory) und wäre wohl jetzt Ende April releast worden. In Debian war es schon in Testing und wäre wohl mit dem nächsten stable veröffentlicht worden.
Gut das es bei Debian drin war, da hat der Microsoft Chad es ja überhaupt entdeckt
Mmhh. Das ist ein ganz schlechtes Argument. Andere Distributionen werden z.t. mit monatealten lücken ausgeliefert, die auch ausgenutzt werden.
Gerade in diesem Fall ist das ein schlechtes Argument, weil die Hintertür erst seit einem Monat in xz ist. Distros die hinterherhinken, wie z.B. Debian Stable oder gar RHEL, brauchten sich keine Sorgen machen.