Crowdstrike-Ausfall: Analyse zeigt trivialen Programmierfehler

Drei Wochen nach dem Windows-Großausfall durch CrowdStrike-Sicherheitssoftware hat das Unternehmen nun seine endgültige Analyse veröffentlicht und darin alle Ursachen der Störung erklärt. In dem zwölfseitigen Dokument erläutert CrowdStrike auch, welche Gegenmaßnahmen solche Vorfälle künftig verhindern sollen.

"Rapid Response Content", "Sensor Detection Engine", "Content Validator", "Template Type" – CrowdStrike bewirft den Leser gleich zu Beginn der "Root Cause Analysis" mit allerlei firmeninternen Fachtermini. Immerhin gibt es eine Kurzzusammenfassung, die den Fehler ohne große Vorrede erklärt.

Der ist nämlich schnell umrissen: Das fehlerhafte Update enthielt 21 Datenwerte und damit einen mehr, als der Kernel-Treiber erwartete. Dieser versuchte deswegen, auf eine ungültige Speicheradresse zuzugreifen – das Resultat ist sattsam bekannt.

What the Fuzz?

Dass dieser simple und leicht durch eine Laufzeitprüfung auf korrekte Array-Größe zu vermeidende Programmierfehler für mehr als acht Millionen Bluescreens weltweit sorgte, verwundert und bedarf einer genaueren Erklärung. Die liefert CrowdStrike und gibt bei dieser Gelegenheit nicht nur zu, die fatale Update-Datei vor dem Rollout nicht getestet zu haben, sondern offenbart auch lückenhafte Testroutinen für andere Bestandteile seiner "Falcon"-Sicherheitssoftware.

CrowdStrike gab an, der als Windows-Kerneltreiber implementierte Falcon-Sensor werde vor der WHQL-Zertifizierung (Windows Hardware Quality Labs) umfangreichen internen Tests ausgesetzt, unter anderem durch Fuzzing. Dass bei diesem automatischen Beschuss des Treibers mit Zufallsdaten eine fehlende Array-Längenprüfung nicht auffiel, ist bemerkenswert.

Ob das als "validiert, getestet und zertifiziert" gelten darf, wie CrowdStrike-CEO George Kurz angeblich während einer Telefonkonferenz mit Investoren im März behauptete, werden nun wohl die Gerichte klären müssen.

CrowdStrike gelobt Besserung

Kurtz stellt dem Analysebericht auch eine kurze Erklärung vom 6. August voran, in der er seine Dankbarkeit treuen Kunden gegenüber ausdrückt, sich nochmals für die negativen Auswirkungen des misslungenen Updates entschuldigt und Besserung gelobt.

Die folgt in Form von Maßnahmen, die für Software der CrowdStrike-Größenordnung teilweise als selbstverständlich gelten sollten: Da ist die Rede von Eingabeprüfung, Array-Längenprüfung und "einer größeren Bandbreite an Testkriterien". Damit verschleiert CrowdStrike die Natur des Fehlers: Er ist auf Unachtsamkeit und Nichteinhaltung der eigenen Datendefinitionen zurückzuführen, nicht auf ein esoterisches, selten auftretendes Szenario. Der Falcon-Sensor kam schlicht nicht damit klar, dass er exakt so viele Eingabedaten erhielt wie in der Datendefinition vorgesehen.

Viel kritisiert wurde von Administratoren und Sicherheitsexperten zudem die ungebremste Update-Prozedur. Systemverwalter hatten nicht die Möglichkeit, Updates der Falcon-Regeldefinitionen zu verzögern oder zu verhindern – das soll künftig möglich sein. Zudem wird CrowdStrike auch einen schrittweisen Updateprozess mittels "Canary Testing", also dem Test an einer kleinen Gruppe eingeweihter Anwender sowie mehreren Updaten-Wellen bei zahlender Kundschaft einführen.

Ob zu den von CEO Kurtz erwähnten treuen Kunden auch die Fluggesellschaft Delta Airlines weiterhin zählt, die sich derzeit öffentlich mit Microsoft und CrowdStrike streitet, darf bezweifelt werden.

Auch in der Community von heise security PRO, dem Fachdienst für Security-Profis, werden das CrowdStrike-Desaster und die Lehren daraus intensiv diskutiert. Die Experten diskutieren im Community-Forum, ob eine Verlagerung vom Kernel- in den Userspace die Lösung ist oder Unternehmen gar komplett auf EDR-Software (Endpoint Detection and Response) verzichten sollten.

(cku)