Wir sind dieses Wochenende nur durch unglaubliches Glück und extrem knapp an wohl einer der grössten Katastrophen rund um die globale IT-Sicherheit vorbeigeschrammt.
Phuh! Doch — was ist eigentlich passiert? Wie konnte das überhaupt geschehen? Und was können (und müssen) wir tun, um dies zukünftig zu vermeiden?
@marcel "Wir sollten uns bei Software wieder auf die wichtigen Komponenten besinnen und nicht einfach alles an zusätzlichen Softwarekomponenten importieren, nur weil es praktisch ist. Oder zumindest versuchen, diese Abhängigkeiten so weit wie möglich zu isolieren."
@glitzersachen Es gibt inzwischen (seit gestern?) ja die Standalone-Version von sd_notify(). Eigentlich meinte ich genau sowas. Und da bewegt sich was, toll!
Bei systemd bin ich gespalten. Ich finde es extrem mächtig und deshalb manchmal praktisch; die Komponenten spuelen gefühlt besser zusammen als in "Legacy"-Lösungen. Aber es hat auch zu viele Optionen und ist zu gross/komplex.
Ich habe aber keine bessere Lösung zur Hand (und auch keine messbare Kriterienliste).
Der Angriff hatte zum Ziel, Abermillionen von Servern weltweit für die unbekannten Angreifer zu öffnen. Was diese mit den Früchten der Vorbereitung der letzten 3 Jahre dann hätten erreichen wollen, das werden wir wohl nie erfahren. Aber die potenziellen Auswirkungen auf Abermillionen von Nutzerinnen, ihren Daten aber auch die Wirtschaft und Stabilität von ganzen Ländern hätten dramatisch werden können. #xz#lzma#ssh https://dnip.ch/2024/04/02/xz-open-source-ostern-welt-retten/
Durch Good-Cop/Bad-Cop-Taktiken wurden Softwareentwickler dazu gedrängt, subtil versteckte Sicherheitslücken einzubauen. Wie können wir das zukünftig vermeiden?
.
1️⃣ Vereinfachung/Reduzierung von Programmen und Abhängigkeiten
2️⃣ Mehr Wertschätzung und Unterstützung für die Open-Source-Entwickler
3️⃣ Bessere Kontrolle, aber ohne Belastung für die Entwickler
4️⃣ Angewandtere Ausbildung
Was sind eure Ideen dazu? Freue mich auf Feedback!
«Die Feiertage. Die ganzen IT-Abteilungen feiern mit der Familie… Die ganzen IT-Abteilungen? Nein! Eine von unbeugsamen Open-Source-Enthusiasten bevölkerte Mailingliste hört nicht auf, den Eindringlingen Widerstand zu leisten.»
Inzwischen gibt es Demo-Code, mit dem jede Applikation ohne die ganzen #xz-Abhängigkeiten systemd-Notifications versenden können. Danke, @pid_eins ! https://mastodon.social/
Oh, btw: I was just made aware of a 4½ minute video that summarizes most of the events and has (what I greatly appreciate) some great real-world analogy for how the backdoor was installed and then detected. Enjoy!
Auf einem anderen Kanal hat mich jemand auf einen möglichen Grund hinter der fehlenden Qualitätssicherung beim finalen Einbau der Lücke gemacht: Die Angreifer sahen womöglich ihre Felle davonschwimmen. Ich habe das noch nachgeführt. Danke! https://dnip.ch/2024/04/02/xz-open-source-ostern-welt-retten/#Wieso_die_Eile
Based on their analysis of working hours, timestamps, and holidays, it seems likely "Jia Tan" worked out of Eastern Europe or Russia while doing the #xzBackdoor ⬆️.
"Trigglux" disagrees: The commit times of "Jia Tan" could also explain an after-work job at UTC+0800. At least it would match his commit times, "Trigglux" says.
Add comment