Erste Details zur Ursache des Absturzes von CrowdStrikes CSAgent.sys

[GN⁺]

Hacker-News-Kommentare

• Erster Kommentar

  • Das BSOD-Problem ist auf eine Kombination aus fehlerhaften Binärdaten und einem fehlerhaft geschriebenen Parser zurückzuführen.
  • Nach den Erfahrungen der letzten 10 Jahre entstehen die meisten CVEs, Abstürze, Bugs und Verlangsamungen beim Deserialisieren von Binärdaten in maschinenlesbare Datenstrukturen.
  • Das betrifft viele Bereiche, darunter Kompressionsalgorithmen, Reader für Font-Outlines, Bild-/Video-/Audio-Parser, Parser für Videospieldaten, XML-/HTML-Parser sowie die Parser für Zertifikate/Signaturen/Schlüssel in OpenSSL.
  • Auch der Content-Parser des EDR-Programms von CrowdStrike ist keine Ausnahme.

• Zweiter Kommentar

  • Statt rootkitbasierter Endpoint-Überwachungssoftware könnten Open-Source-Lösungen ethischer sein.
  • Open-Source-Tools arbeiten transparent und können sicherstellen, dass es keine Backdoors oder schwerwiegenden Bugs gibt.
  • Sie können öffentlich auditiert werden und als Geschäftsmodell mit der Bereitstellung von Malware-Signaturen für Security-Teams betrieben werden.

• Dritter Kommentar

  • Microsoft trägt Verantwortung für den Ausfall bei CrowdStrike.
  • Microsoft hat im Bereich Workplace-Computing de facto eine monopolartige Stellung und ist verpflichtet, für Sicherheit/Zuverlässigkeit/Funktionalität seiner Produkte zu sorgen.
  • Wegen fehlender Konkurrenz verzögert sich die Innovation bei Windows.
  • Zum Beispiel läuft CrowdStrike unter macOS und Linux im User Space, unter Windows jedoch nicht.
  • Innovation bei Application Sandboxing ist nötig.
  • Microsoft hält die Schlüssel zur weltweiten Computing-Infrastruktur in der Hand und wird dabei kaum kontrolliert.
  • Obwohl der Umsatzanteil von Windows gesunken ist, braucht es mehr Verantwortung, weil das Produkt kritische Infrastruktur betreibt.
  • Regierungen sollten den Wettbewerb im Markt für Desktop-Workspaces fördern oder Microsofts Windows-Produkte regulieren.

• Vierter Kommentar

  • Ich verstehe nicht, warum die Auswirkungen so groß waren.
  • Bei kritischen Services sind langsame Rollouts mit automatischem Monitoring und Rollback normalerweise Standard.
  • Üblich ist ein Deployment in der Beta-Phase ohne Kundentraffic und bei ausbleibenden Problemen eine schrittweise Ausweitung.
  • Auf diese Weise hätte man das Problem sofort stoppen können.

• Fünfter Kommentar

  • Ich nutze CrowdStrike nicht, aber es wirkt so, als würde der CS-Treiber zuerst installiert und so entworfen, dass er sich nicht entfernen lässt.
  • Der Treiber lädt unsignierte Datendateien, und Benutzer können sie beliebig löschen.
  • Ein böswilliger Benutzer könnte eine schädliche Datendatei erstellen und den Treiber zu Fehlverhalten bringen.
  • Es besteht das Risiko, Kernel-Rechte zu erlangen.

• Sechster Kommentar

  • Ich frage mich, warum das Problem bei Test-Deployments nicht entdeckt wurde.
  • Es ist schwer zu glauben, dass vor dem Deployment nicht getestet wurde.
  • Jedes Unternehmen sollte vor einem Deployment eine Testumgebung haben.
  • Während der Entwicklung ist es normal, Pakete zu installieren, die fehlschlagen oder Probleme verursachen, aber sie direkt in die Produktionsumgebung zu deployen, ist keine gute Idee.

• Siebter Kommentar

  • Ich frage mich, ob CrowdStrike-Kunden bei Updates mitreden können.
  • Ich bezweifle, dass alle Kunden CrowdStrike vollständige Rechte für Remote Code Execution einräumen.
  • Ich hoffe, dass Zertifizierungsstellen und Kryptografie-Experten solche Updates auf Systemen blockieren können.

• Achter Kommentar

  • Ich frage mich, ob die „Channel-Datei“ vom CS-Treiber signiert und verifiziert wird.
  • Falls nicht, könnte das eine große Schwachstelle des Rootkits sein.
  • Eingaben, die mit hohen Rechten ausgeführt werden, sollten zumindest einer Integritätsprüfung unterzogen werden.
  • Dass sich die Channel-Datei einfach löschen lässt, deutet darauf hin, dass es keinen Mechanismus zur Erkennung von Manipulationen gibt.