Crowdstrike-Desaster: Ein Eingabeparameter zu viel war schuld an den riesigen Ausfällen
Die Ursachenforschung nach dem "größten IT-Ausfall aller Zeiten" scheint abgeschlossen. Das Unternehmen Crowdstrike erklärt, wie es zum GAU kommen konnte: Ein einziger Eingabeparameter löste das weltweite Chaos aus.
Vor rund drei Wochen kam es zu einem weltweiten Ausfall der IT-Infrastruktur: Durch ein fehlerhaftes Update des Dienstleisters Crowdstrike wurden zahlreiche Fluggesellschaften, Krankenhäuser und Regierungsbehörden lahmgelegt. Selbst der Zahlungsverkehr war in einigen Ländern wie Australien betroffen. Einige Tage später erklärte Crowdstrike, dass die Ausfälle an einem Konfigurationsupdate für die Software Falcon Sensor lagen - nun veröffentlicht das Unternehmen mehr Details in einer Ursachenanalyse.
Demzufolge wurde das Update für die Software mittels "Rapid Response Content" ausgespielt, mit dem Crowdstrike schnell auf potenzielle Bedrohungen reagieren und entsprechende Aktualisierungen ausspielen kann. Hierfür wurde im Februar 2024 ein neuer Vorlagentyp "Inter Process Communication" (IPC) eingeführt, mit dem bestimmte Angriffe schnell erkannt werden sollen.
Dieser Vorlagentyp definiert insgesamt 21 Parameter, der Sensor kann jedoch nur 20 verarbeiten. Im Update vom 19. Juli, das letztlich zu den Ausfällen führte, waren erstmals exakt 21 Eingabeparameter enthalten - entsprechend einer zu viel für den Intergrationscode. Dieser rief "den Content Interpreter mit den Vorlageninstanzen der Channel-Datei 291 auf, lieferte jedoch nur die gewohnten 20 Eingabewerte zum Abgleich", wie es in der Crowdstrike-Mitteilung heißt.
In vorherigen Updates sei der 21. Parameter nie genutzt worden, auch in Freigabe- und Belastungstests sei die unterschiedliche Anzahl an Parametern nie angekommen. Erst das folgenschwere Update verwendete dies, sodass im Content Interpreter der Out-of-Bounds-Speicherzugriff sowie der daraus resultierende Systemabsturz entstanden.
Um solche extremen Ausfälle künftig zu vermeiden, verspricht Crowdstrike weiterhin einen Katalog an Maßnahmen, der teilweise wohl schon umgesetzt wurde. Hierzu zählt etwa die Erstellung weiterer Tests für Vorlagentypen sowie erweiterte Möglichkeiten für Crowdstrike-Kunden, die Bereitstellung von Rapid Response Content manueller zu gestalten.
Wie kann man bitte bei einem Boot-Treiber im Kernel so dermaßen nachlässig entwickeln? Zumal es ja nicht der erste solche Vorfall war. Vor einigen Monaten gab es mit Probleme mit der Linux-Version von CrowdStrike, die bei einigen Distributionen auch den Kernel weggeschossen hat. Sicher, anderes Entwickler-Team, aber bei gescheiter Kommunikation und verantwortungsvollen POs, sollte man eigentlich davon ausgehen, dass nach solchen Problemen auch die verwandten Produkte auf entsprechende Fehler überprüft werden.
Das finde ich ähnlich peinlich wie ein Flugzeugbauer, dem nicht verschraubte Teile vom Himmel fallen.
Bei mir im Unternehmen hatte ich das vor ein paar Wochen ebenfalls. Eine Vertragsübersicht, die Unternehmensweit alle Fachbereiche betrifft, lief nicht mehr richtig. Entsprechend konnten die Bereiche rund 6 Stunden nicht mehr arbeiten. Der Fehler war, dass wir lediglich auf einer Testumgebung - wie sonst auch - getestet haben. Eine Umgebung, die bei 99 % der Fälle
ausreichend ist, aber für den Fall damals eben nicht. Nun testen wir - auch wenn dies nicht gewünscht wird - immer auf einer Produktionskopie, wenn es diese Vertragsübersicht betrifft.
Ich hab mich damals richtig scheiße gefühlt, weil ich das fachlich freigeben habe - das ganze ging auch entsprechend bis zum Vorstand, der "not amused" war. Ich möchte nicht wissen, wie sich die Personen bei Crowdstrike gefühlt haben müssen, wenn auf einmal weltweit solche Probleme entstehen.
Erstes Semester Informatik Studium.
Immer den lowcase und den highcase testen, in dem Fall 0 und 21 Parameter.