Der Vorfall, bei dem CrowdStrike bereits vor Monaten Debian und Rocky Linux beschädigte

• Unabhängig vom großflächigen BSOD-Ausfall unter Windows gab es bereits Fälle, in denen CrowdStrike-Updates auch in Debian- und Rocky-Linux-Umgebungen Serverausfälle verursachten
• In einem Civic-Tech-Lab stürzten im April unmittelbar nach einem Update alle Debian-Linux-Server gleichzeitig ab und verweigerten den Bootvorgang; eine Wiederherstellung war erst nach der Entfernung von CrowdStrike möglich
• Die betreffende Debian-Konfiguration galt als unterstützt, war jedoch nicht mit der neuesten stabilen Debian-Version kompatibel; in der Ursachenanalyse wurde eine Lücke in der Testmatrix festgestellt
• Auch Rocky-Linux-Nutzer berichteten, dass Server mit CrowdStrike nach einem Upgrade auf RockyLinux 9.4 wegen eines Kernel-Bugs abstürzten; auch der CrowdStrike-Support erkannte das Problem an
• Organisationen, die auf CrowdStrike angewiesen sind, sollten Updates vorsichtiger einspielen und Notfallpläne für Ausfälle bereithalten

---

Linux-Ausfälle vor dem Windows-Vorfall

• Das weitreichende Blue-Screen-of-Death-Problem auf Windows-PCs beeinträchtigte den Betrieb in mehreren Bereichen, darunter Fluggesellschaften, Banken und Gesundheitsdienstleister
  • Ursache war eine fehlerhafte Channel-Datei (channel file), die CrowdStrike per Update auslieferte
  • CrowdStrike bestätigte, dass dieser Absturz Mac- oder Linux-PCs nicht betraf
• Allerdings erlebten auch Nutzer von Debian und Rocky Linux erhebliche Ausfälle durch CrowdStrike-Updates, was Bedenken hinsichtlich der Update- und Testverfahren auslöste
  • Für Kunden, die täglich auf CrowdStrike-Produkte angewiesen sind, kann dies ein potenzielles Risiko darstellen

Bestätigte Probleme unter Debian und Rocky Linux

• Gleichzeitiger Absturz von Debian-Servern

  • In einem Civic-Tech-Lab ließ ein CrowdStrike-Update im April alle Debian-Linux-Server gleichzeitig abstürzen und verhinderte das Booten
  • Das Update war nicht mit der neuesten stabilen Debian-Version kompatibel, obwohl diese Linux-Konfiguration als unterstützt galt
  • Das IT-Team stellte fest, dass die Maschinen booteten, sobald CrowdStrike entfernt wurde, und meldete den Vorfall

• Verzögerte Reaktion und fehlende Tests

  • Ein an dem Vorfall beteiligtes Teammitglied äußerte Unzufriedenheit über die verzögerte Reaktion von CrowdStrike
  • CrowdStrike erkannte das Problem einen Tag später an, benötigte jedoch mehrere Wochen, um eine Ursachenanalyse bereitzustellen
  • Die Analyse ergab, dass die Debian-Linux-Konfiguration nicht in CrowdStrikes Testmatrix enthalten war
  • Das Teammitglied kritisierte: „Das Modell von CrowdStrike scheint zu sein: Wir pushen Software auf eure Maschinen, wann immer wir wollen, unabhängig davon, ob es dringend ist oder ob sie getestet wurde.“

• Abstürze nach Upgrade auf Rocky Linux 9.4

  • Rocky-Linux-Nutzer berichteten, dass Server mit CrowdStrike nach einem Upgrade auf RockyLinux 9.4 wegen eines Kernel-Bugs abstürzten
  • Der CrowdStrike-Support erkannte dieses Problem an
  • Wiederholte Kompatibilitätsprobleme auf unterschiedlichen Betriebssystemen zeigen ein Muster aus unzureichenden Tests und mangelnder Sorgfalt

Worauf Organisationen vorbereitet sein sollten

• Um ähnliche Probleme künftig zu reduzieren, sollte CrowdStrike strengere Tests für alle unterstützten Konfigurationen priorisieren
• Organisationen sollten CrowdStrike-Updates vorsichtig einspielen und Notfallpläne ausarbeiten, um potenzielle Ausfälle abzufedern
• Zugehörige Quellen
  • Ycombinator
  • RockyLinux

[click]

Es sieht so aus, als hätte die KI nicht den Haupttext, sondern die Werbung zusammengefasst.

[xguru]

Die HTML-Struktur der Neowin-Website ist merkwürdig, daher wurden alle Anzeigen in der oberen Leiste als Haupttext erkannt. Ich habe das korrigiert.

[GN⁺]

Meinungen auf Hacker News

• Es ist erstaunlich, dass das OSS-/Linux-Ökosystem, obwohl es aus vielen Code-Haufen besteht, die von unabhängigen, lose koordinierten Gruppen kostenlos zusammengefügt wurden, oft robuster ist als Software von milliardenschweren Unternehmen.
  Einer der Gründe könnte sein, dass OSS-Systemprogrammierer schmutzige Wäsche in der Öffentlichkeit waschen. Es geht weniger um „Viele Augen machen Bugs oberflächlich“, sondern eher um „Schlechter Code wird peinlich, sobald ihn jemand nur ansieht“.
  Ich bereite gerade ein kommerzielles Projekt darauf vor, als Open Source veröffentlicht zu werden, und vor der Veröffentlichung des Quellcodes muss ich einiges aufräumen: Dokumentation verbessern, TODOs/FIXMEs bereinigen, Kommentare prüfen usw. In geschlossenen kommerziellen Codebases habe ich allerdings schon deutlich Schlimmeres gesehen, und ich vermute, die meiste Enterprise-Software ist auf einem ähnlichen Niveau.

  • OSS-Software hat kaum Profitmotiv und wird daher eher geschrieben, um etwas „zum Laufen zu bringen“, als um etwas „zu verkaufen“.
    Der Zeitdruck ist auch geringer; wenn sich ein Release verzögert, wirkt sich das nicht auf die Quartalszahlen aus. Kommerzielle Software sehe ich eher als Marketingarbeit denn als Ingenieursarbeit.
  • Linus würde dem wohl nicht zustimmen, und es gibt einen Grund, warum der Kernel immer enorme Hürden aufstellt. Er würde den Großteil des User-Space-Codes zu Recht ablehnen.
    Dass Dinge außerhalb des Kernels überhaupt laufen, ist ein Wunder, und das zeigt sich daran, wie oft sie bei Distributionsupdates kaputtgehen und wie häufig man alles neu bauen muss, um es wieder zum Laufen zu bringen. Updates in der Produktion sind ein extrem stressiger Prozess.
    Audio und Video habe ich noch gar nicht erwähnt, und wenn dann noch Wayland dazukommt, ist das ein eigener Albtraum. Deshalb ist Windows in vielerlei Hinsicht näher am Standard: Es wird aus allen Richtungen brutal beansprucht und erledigt trotzdem täglich wichtige Aufgaben auf unzähligen Maschinen.
    Ob jemand dafür bezahlt wird, ist nicht entscheidend; die Tiefe der Entscheidungsfindung, wie man sie in Texten von Raymond Chen und anderen sieht, ist auch in der OSS-Welt sehr selten.
  • Dinge, die gegen Bezahlung gebaut werden, bei denen aber MBAs die endgültigen Entscheidungen treffen, sind oft deutlich schlechter als Hobby- oder Leidenschaftsprojekte.
    Ich glaube nicht, dass das nur mir so geht, und ich hoffe, dass es weiterhin Communities gibt, die Dinge bauen, weil sie etwas Nützliches und Werkzeuge schaffen wollen, die sie selbst kontrollieren können.
  • Deadlines dürften ebenfalls ein großer Faktor sein. Viele OSS-Entwickler bauen Projekte in ihrer Freizeit für sich und andere, und bei einem Leidenschaftsprojekt kann man auf die eigene Arbeit eher stolz sein.
    Kommerzielle Software fühlt sich oft so an, als wäre sie mit Duct Tape zusammengeflickt, nur um die Deadline eines Managers einzuhalten; dann wird daraus ein „egal“ und man ist schon zufrieden, dass es überhaupt fertig ist.
  • Die Leute, die den Code schreiben, als Amateure zu bezeichnen, halte ich nicht für eine gute Beschreibung. Die meisten dürften erfahrene, hoch technische Leute sein, und „lose koordiniert“ trifft auch auf viele Unternehmen zu.
    Entscheidend ist, dass Menschen in Open Source oft coden, weil es sie interessiert. Wenn man etwas gut, zuverlässig und clever machen will, ist die Erfolgswahrscheinlichkeit höher, als wenn man es nur gegen Bezahlung tut oder um Peinlichkeiten zu vermeiden.

• Ein relevanter Kommentar aus dem großen CrowdStrike-Thread von gestern: „CrowdStrike hat das am 19. April mit unserer Produktions-Linux-Flotte gemacht, und seitdem wollte ich die ganze Zeit darüber ranten“ [1]
  Danach folgt ein mehrabsätziger Rant.
  [1] https://news.ycombinator.com/item?id=41005936

  • In der einige Wochen später veröffentlichten Root-Cause-Analyse war unser Szenario ebenfalls nicht in der Testmatrix enthalten, obwohl es wie eine unterstützte Konfiguration aussah: n-1-Version auf Debian stable.
    Auch in der eigenen Postmortem-Analyse gab es keine wirkliche Möglichkeit, zu verhindern, dass dasselbe wieder passiert. Denn die Struktur lautete: „Wir pushen Software auf deine Maschinen, wann immer wir wollen, unabhängig davon, ob es dringend ist oder nicht, und ohne Tests.“
  • Es ist nicht einfach nur ein verwandter Kommentar; es sieht so aus, als sei dieser HN-Thread im Artikel als Hauptquelle verwendet worden.

• Als ich in diesem Bereich arbeitete, begleitete mich ständig die Frage: „Sind diese Dinge tatsächlich nützlich?“
  Das ist schwer zu beantworten, aber ich frage mich, ob es unabhängige Studien gibt, die die Wirksamkeit von Produkten wie CrowdStrike überprüft haben. Oder ob wir alle nur wegen Sicherheitstheater unser Leben schlechter machen.

  • Das ist ähnlich wie der Versuch, die Wirksamkeit von Antivirensoftware zu untersuchen. Aber damit hast du die Antwort eigentlich schon gegeben: Solange man Metriken erzeugt, die das Management verdauen kann, gilt es als wertvoll.
    Wie es sinnvoll sein soll, so etwas Invasives hinzuzufügen, ist fraglich. In den 90ern haben Antivirenfirmen auch Viren geschrieben und das, was sie selbst gebaut hatten, in Netzwerke eingeschleust, während sie bei ihren Abonnenten die Infektion wie durch Zauberhand verhinderten.
  • Ich frage mich, ob jemand tatsächlich gesehen hat, dass so ein Tool etwas verhindert hat. Das Unternehmen, das dieses Tool gebaut hat, hat sein eigenes Produkt ja wohl selbstverständlich auch genutzt.
    Wenn man das gesamte Web fragt: „Hat das jemand gesehen?“, wird sicher irgendjemand auftauchen. Aber es gibt enorm viele Menschen, die wegen solcher Tools Sicherheitslücken erlebt haben, und die Zahl derer, die Stabilitäts- und Verfügbarkeitsprobleme hatten, entspricht praktisch der Zahl der Nutzer dieses Tools.

• Die Produktqualität befindet sich von Flugzeugen bis Software im freien Fall. Heutzutage kümmern sich alle nur noch um zusätzliche Einnahmen, sodass fehlende QA zum Normalfall geworden ist.

  • Unsere Wirtschaft wurde auf Gewinn min-maxed, und jetzt scheinen wir in die Erntephase einzutreten.
    Aus demselben Grund können wir nicht genügend Artilleriegranaten für die Ukraine herstellen, keine Chipfertigung ins Inland holen und keine Schiffe bauen.
  • Ein weiterer Grund ist, dass immer häufiger nicht-technische Leute Entscheidungen treffen und sogar technische Programme entwickeln.
    Vor 15 Jahren wollten die meisten Menschen in der Branche wirklich dort sein, nur wenige waren Ausnahmen. Inzwischen ist es wie jeder andere Job geworden: Die meisten Entwickler interessieren sich kaum für ihren Output, und entsprechend ist das Ergebnis am Ende ein Chaos.
    In den letzten Jahren habe ich kaum noch Entwickler unterhalb Senior-Level getroffen, die ihren eigenen Müllcode tatsächlich testen.
  • Der wirtschaftliche Preis für Fehler ist geringer als der Gewinn, der damit erzielt wird. Bevor sich das ändert, wird sich gar nichts ändern.
  • Das ist nicht einfach nur ein Problem der Produktqualität.
    Es ist eine Struktur, in der nach Marketing riechende Influencer, die selbst nicht wissen, was sie tun, Müll an Leute verkaufen, die vom Anbieter geschürte Paranoia mit Compliance-Checkboxen überdecken wollen. Diese Leute verstehen weder Threat Modeling noch wie ein Betriebssystem funktioniert.
    Nach der CIA-Triade haben sie Verfügbarkeit vollständig aufgegeben, opfern teilweise auch Vertraulichkeit, indem sie jede Bewegung des Systems an irgendein Cloud-Unternehmen senden, und versuchen dafür ein falsches Sicherheitsgefühl von Integrität zu bekommen, die der Anbieter nicht einmal garantiert. Ich habe kaum Belege dafür gesehen, dass dieses Produkt in einer sauber geschichteten Sicherheitsarchitektur tatsächlich irgendetwas leistet.
    Das ist das genaue Gegenteil eines Security-Angebots. Ein Kartenhaus aus Lügen und Inkompetenz, und buchstäblich nahe an der Definition von Malware. Es exfiltriert Daten, die man nicht kontrollieren kann, kann Systeme über Remote-Command-and-Control-Funktionen zu Fall bringen und führt in Ring 0 völlig beliebigen Code aus.
    Im März 2023 habe ich das Ganze als erhebliches Geschäftsrisiko bezeichnet, aber die oben genannten Leute haben es durchgedrückt. Ich habe meinen Widerspruch aufgezeichnet und gedenke nun, mich damit zu revanchieren.
    Wenn Leute es kaufen, ist es egal, ob es zu Müll gemacht wird. Und tatsächlich ist es zu Müll gemacht worden.
  • Es ist traurig. Es gibt Unterschiede von Unternehmen zu Unternehmen, und persönlich ist QA einer meiner liebsten Teile des Software Engineerings, aber viele große Unternehmen kürzen QA, sobald sich die Gelegenheit bietet.

• Es gab auch Berichte, dass CrowdStrike eine fehlerhafte DLL in Windows-Anwendungen injizierte, sodass Anwendungen abstürzen konnten, ohne dass die Anwendung selbst schuld war.
  https://x.com/molecularmusing/status/1808756095860543916

  • Das ist ein völlig anderes Thema. Die injizierte DLL ist eine optionale Funktion, die standardmäßig deaktiviert ist, und Administratoren werden ausdrücklich gewarnt, vor dem Rollout die Kompatibilität mit ihrer Flotte zu prüfen.
    Es gibt vier Stufen anwendbarer Hooks, die zunehmend instabil werden, und in UI und Dokumentation wird wiederholt gewarnt. XUMD lädt beispielsweise eine Bibliothek in laufende Prozesse und hookt mehrere User-Mode-APIs, damit der Sensor Informationen überwachen kann.
    Manche Endpoint-Telemetrie kann nur über User-Mode-Hooks erfasst werden. XUMD liefert Informationen darüber, welche APIs ein Prozess nutzt; diese Informationen werden auf Basis des beobachteten kumulierten Verhaltens für mehrere Präventionsmechanismen des Sensors verwendet.
    Im Gegensatz zu AUMD kann die Cloud die XUMD-Sichtbarkeit dynamisch ändern, ohne den Sensor zu aktualisieren. Die Einstellungen sind Disabled, Cautious, Moderate, Aggressive und Extra Aggressive; je weiter hinten, desto größer sind mögliche Performance- oder Anwendungskompatibilitätsprobleme, weshalb sie für Produktion nicht empfohlen werden.
    Da XUMD in User-Prozesse geladen wird, mit denen es ursprünglich nicht gemeinsam entwickelt wurde, kann es insbesondere in Umgebungen mit anderen Sicherheitsprodukten zu Abstürzen, Startfehlern oder Performance-Einbußen kommen. Um zu sehen, welche Prozesse die XUMD-DLL geladen haben, kann man in der Kommandozeile tasklist /m csxumd* ausführen.

• All das passiert, weil Unternehmen die Haftung für Folgeschäden vertraglich ausschließen können.
  So wie man die Haftung für Folgeschäden bei Verlust von Menschenleben nicht vertraglich ausschließen kann, sollten solche Klauseln ebenfalls undurchsetzbar gemacht oder zumindest begrenzt werden.

  • War das nicht das, was die europäische Cybersecurity-Richtlinie erreichen wollte? Die, über die sich alle aufgeregt haben, bis eine FOSS-Ausnahme aufgenommen wurde.

• Die Aussagen „Das Update war nicht mit der neuesten Stable-Version von Debian kompatibel, obwohl diese Linux-Konfiguration als unterstützt ausgewiesen war“ und „Die Analyse ergab, dass die Debian-Linux-Konfiguration nicht in der Testmatrix enthalten war“ wirken ziemlich nah an tatsächlichem Betrug.
  Man erklärt, Konfiguration X zu unterstützen, testet Konfiguration X aber in Wirklichkeit überhaupt nicht. Das ist, als würde man sagen, ein Auto habe Sicherheitsgurte, ohne irgendwo im Herstellungsprozess zu prüfen, ob die Gurte installiert sind und funktionieren.
  Wenn ein Autohersteller so etwas getan hätte, wäre er vermutlich angeklagt worden; ich verstehe nicht, warum CrowdStrike nicht. Es ist verständlich, bestimmte Linux-Versionen nicht zu unterstützen, aber wenn man mit Unterstützung wirbt und nicht einmal testet, ist das mindestens vorsätzliche Fahrlässigkeit und vielleicht sogar offener Betrug.

• „Niemand hat es bemerkt“ klingt wie eine niedliche Umschreibung dafür, dass CrowdStrike verhindert hat, dass die Presse es bemerkt. In den HN-Threads am Tag des Bugs gab es Kommentare von Leuten, die schon seit Monaten versucht hatten, Probleme zu melden.
  Sogar der Artikel selbst schreibt so, als hätten Leute das Problem bemerkt. Wer hat es dann nicht bemerkt? Oder waren diese Probleme einfach nicht prominent genug, um nicht ignoriert zu werden?

  • Glaubst du, CrowdStrike habe die Berichterstattung der Presse unterdrückt? Ich frage mich, ob du denkst, sie hätten der NY Times, der WaPo und den großen Fernsehsendern Schecks geschickt.
    Die Presse interessiert sich nicht für ein paar ausgefallene Server, solange es in der realen Welt nicht sichtbar wird, wie etwa bei Flugausfällen.
  • Ich erinnere mich, damals etwas gesehen zu haben, dachte aber, dass nur sehr wenige Leute so eine Software auf Linux installieren würden. Tatsächlich gibt es auch nur sehr wenige solche Unternehmen.
    Der Blast Radius war klein, vermutlich sogar kleiner als bei einem schlechten Nvidia-Treiber.

• Falls hier jemand CrowdStrike verwendet: Ich frage mich, was es genau macht. Ich sehe, dass es als „Antivirus“ bezeichnet wird, aber wenn ich sehe, dass es auf einem Arbeits-Laptop installiert ist, wirkt es wie ein Keylogger und Aktivitätsmonitor.
  Man sagt zwar „ich habe nichts zu verbergen“, aber es stört mich trotzdem, dass die Superuser des Unternehmens mich überwachen.

  • Es hilft dabei, den Genehmigungsstempel von Security-, Compliance- und Rechtsabteilungen zu bekommen.
  • Es gibt eine bessere Lösung, als Antivirus-/EDR-Lösungen als Malware oder Spyware zu bezeichnen: Arbeitsgeräte nicht für private Dinge nutzen.
    Das Gerät gehört dem Unternehmen und wird für den Zugriff auf die Unternehmensumgebung verwendet; wenn echte Malware darauf gelangt, ist es also ein Verantwortungsbereich, der Schaden anrichten kann. Wenn man Privatsphäre braucht, sollte man besser ein separates Gerät verwenden.

• In manchen Unternehmen heißt es, CrowdStrike sei auf allen Endpoints ausgerollt, aber jemand sagte, es sei kommentarlos durchgegangen, es nur in einer virtuellen Maschine mit begrenzten Ressourcen laufen zu lassen. Um diese Zeit herum habe man auch gesehen, dass virtuelle Maschinen ausfielen.
  Von einem ehemaligen Kollegen bei einem anderen Großunternehmen habe ich auch gehört, dass die IT es einfach aufgegeben hat, Compliance auf Linux-Endpoints durchzusetzen. Manche IT-Admins scheinen faktisch eine „nicht fragen, nicht sagen“-Policy zu fahren.
  Nach dem Motto: Wenn man seinen alternativen Stack selbst zusammenstellt und keinen Wirbel macht oder lügt, soll man halt machen. Wenn der Antrieb für die Durchsetzung größtenteils Checkbox-Compliance ist, ergibt das durchaus Sinn.
  Ich frage mich, wie weit verbreitet diese Art von böswilliger Befolgung ist und wie sehr sie dazu beigetragen hat, dass der Vorfall im April keine größere Nachricht wurde.