Zusammenfassung

  • Eine neue Version des Channel File 291 erreichte Falcon-Sensoren, und auf den betroffenen Rechnern endete die Auswertung im Absturz.
  • Der Anbieter hat Prüfschritte angekündigt: Grenzprüfungen, erweiterte Tests, einen Content Validator, zusätzliche Ausrollstufen, mehr Kundenkontrolle und zwei externe Prüfer.
  • Keiner dieser Schritte ist im gesichteten Material getestet. Die belastbare Einordnung lautet deshalb ungeprüft, nicht widerlegt.

Der Vorgang ist in wenigen Sätzen beschrieben, und diese Sätze stammen aus Zitaten. Eine dritte Seite gibt ausgewählte Auszüge aus der technischen Ursachenanalyse des Anbieters wieder, darunter den Satz: „Sensors that received the new version of Channel File 291 carrying the problematic content were exposed to a latent out-of-bounds read issue in the Content Interpreter." Der Ausfall selbst steht im Anschluss: „and resulted in a system crash". Help Net Security zitiert in seinem Bericht zu Ursachen und Gegenmaßnahmen das entscheidende Detail: „the integration code that invoked the Content Interpreter with Channel File 291’s Template Instances supplied only 20 input values to match against."

Damit ist der Mechanismus benannt. Der Content Interpreter ist die Komponente im Sensor, die den Inhalt einer Channel-Datei gegen Regeln abgleicht. Ein Template Type gab 21 Eingabewerte vor, geliefert wurden 20; beim 21. Wert las der Interpreter über den gelieferten Bereich hinaus und stürzte ab. Die Channel-Datei lag nicht auf einem einzelnen Rechner, sondern wurde über den Update-Kanal an Sensoren derselben Version verteilt. Der Fehler war damit kein lokaler Defekt, sondern ein verteilter. The Hacker News ordnet den Vorgang in seinem Bericht über das Inhaltsvalidierungsproblem so ein: The "Channel File 291" incident, as originally highlighted in its Preliminary Post Incident Review (PIR), has been traced back to a content validation issue.

Genau dort beginnt die Frage nach den Prüfschritten. Drei Zustände sind zu unterscheiden, und sie werden regelmäßig verwechselt. Angekündigt heißt: eine Veröffentlichung sagt, die Kontrolle existiere. Umgesetzt heißt: ein versioniertes Artefakt und ein Ausrollnachweis zeigen, dass sie auf dem relevanten Pfad zwingend greift. Nachgewiesen heißt: kontrollierte Läufe zeigen, dass definierte schlechte Eingaben abgelehnt werden, mit Ausgabe und mit Folge für die Freigabe. Zwischen dem ersten und dem zweiten Zustand liegt ein Dokument. Zwischen dem zweiten und dem dritten liegt ein Prüfprotokoll.

Die Berichterstattung fasst die angekündigten Maßnahmen zusammen. Es sind Zusammenfassungen, keine Zitate, und sie werden hier als solche wiedergegeben: Grenzprüfungen zur Laufzeit, eine breitere Testabdeckung der Template Types einschließlich des Abgleichs ohne Wildcards, eine Beschränkung des 21. Feldes im Content Validator auf den Wildcard-Abgleich, neue Testverfahren im Content Configuration System, zusätzliche Ausrollstufen und Ringe, mehr Kundenkontrolle darüber, wann und wo Rapid Response Content ausgerollt wird, sowie zwei nicht namentlich genannte Software-Sicherheitsanbieter, die Sensor und Qualitätsprozess prüfen sollen.

Jede dieser Maßnahmen verschiebt etwas anderes, und das lässt sich ohne Interna beschreiben. Grenzprüfungen zur Laufzeit wirken im Sensor. Sie verhindern, dass ein einzelner fehlerhafter Wert zum Absturz führt, und begrenzen damit den Schaden eines Fehlers, den vorher niemand gesehen hat. Erweiterte Tests und eine zusätzliche Feldbeschränkung wirken vor der Freigabe; sie sollen den Fehler abfangen, bevor er den Kanal erreicht. Ausrollstufen begrenzen die Zahl der Rechner, die eine schlechte Aktualisierung zuerst sehen. Kundenkontrolle verschiebt die Entscheidung über den Zeitpunkt zum Betreiber.

Die beiden externen Prüfer sagen etwas über den Prozess aus, aber sie prüfen nichts, was ein Kunde einsehen könnte.

Der Schritt von der Ankündigung zur Umsetzung braucht wenig: eine Versionsnummer der Regel, ein Freigabeprotokoll, ein Datum, ab dem sie zwingend ist. Der Schritt zum Nachweis braucht mehr: einen Korpus mit Grenzfällen, die dokumentierte Ablehnung genau des Fehlers aus dem Vorfall, die Ausgabe des Validators und die Angabe, welche Freigabe daraufhin gestoppt wurde. Ringe brauchen Zahlen, nämlich wie viele Rechner in der ersten Stufe hängen, welche Schwelle zur Beförderung führt, welches Signal den Ausroll stoppt und welcher Weg zurückführt.

Für die externen Prüfer braucht es Namen, Auftragsumfang, Methode, Befunde und eine Wiederholungsprüfung. Nichts davon steht im gesichteten Material.

Eine zweite Frage bleibt von allen diesen Maßnahmen unberührt. Die externe Analyse von ERNW beschreibt den Sensor so: „CrowdStrike’s kernel driver (CSAgent.sys) interprets the content of Channel Files directly in the kernel. Conceptually, it is like implementing (at best) a regex engine... directly in the kernel." Ein Regelabgleich im Kernel bedeutet: ein Fehler in den Regeln oder in ihrer Auswertung ist ein Fehler im Kernel. Grenzprüfungen fangen einen bestimmten Fehlertyp ab. Sie ändern nicht, wo die Auswertung stattfindet. Wer diese Grenze verschieben will, müsste die Interpretation aus dem Kernel herausnehmen, in einen weniger privilegierten, isolierten Prozess, oder belegen, dass die verbleibenden Beschränkungen dasselbe leisten. Ein Absturz eines Dienstes bleibt ein Ausfall eines Dienstes; ein Absturz im Kernel ist ein Ausfall des Rechners.

Die Berichterstattung hält außerdem fest, dass der Anbieter Einwände zurückweist, der Fehler habe eine Rechteausweitung oder die Ausführung fremden Codes ermöglicht, und dass er nach eigener Angabe mit Microsoft an Sicherheitsfunktionen im User-Modus arbeiten will. Der zweite Punkt berührt die Grenze tatsächlich, der erste ändert an der Fehlerklasse nichts. Beides sind Zusammenfassungen, keine Zitate.

Was dieser Text tragen kann, ist damit umrissen. Gesichtet wurden vier veröffentlichte Seiten, die die Ursachenanalyse zitieren oder zusammenfassen, darunter die externe Analyse von ERNW; die Seiten des Anbieters selbst lagen nicht als Text vor. Eine gezielte Suche nach Anhörungen in gesetzgebenden Gremien, nach Stellungnahmen von Aufsichtsbehörden und nach Gerichtsakten ergab keine Quelle. Für die angekündigten Prüfschritte folgt daraus nichts über ihre Wirksamkeit, sondern etwas über ihren Belegstand: im gesichteten Material sind sie angekündigt und nicht nachgewiesen. Ein fehlender Nachweis ist kein Beweis für Abwesenheit. Er ist der Grund, warum ein Betreiber weiterfragen muss. Zum Weiterlesen: der Verzeichniseintrag zu CrowdStrike.