Incident CrowdStrike Falcon : 8,5 millions de machines affectées

À l’origine du bug

Ce n’est pas une mise à jour défaillante de la sonde Falcon qui est à l’origine de la panne, mais une mise à jour de contenu de détection pour cette sonde, un fichier de configuration, ou Channel File, comme les désigne CrowdStrike.

Dans un billet de blog, l’éditeur pointe sur l’une d’entre elles, numérotée 291 : elle « contrôle la manière dont Falcon évalue l’exécution de tubes nommés sur les systèmes Windows. Les tubes nommés sont utilisés pour des communications normales entre processus ou systèmes dans Windows ». 

La mise à jour en question était « conçue pour viser des tubes nommés malicieux nouvellement observés et utilisés par des frameworks courants de commande et de contrôle (C2) dans des cyberattaques ». Accessoirement, Fortra, l’éditeur de Cobalt Strike, venait justement de documenter un tel cas. Manque de chance, « la mise à jour de configuration a provoqué une erreur logique résultant en un plantage du système d’exploitation ».

Si CrowdStrike s’est attelé tout le week-end à aider ses clients, Microsoft s’est également impliqué, notamment avec la production d’un outil dédié avec deux options d’exécution et de réparation.

Des précédents

Un tel épisode n’est hélas pas totalement inédit, du moins dans ses origines. En juin 2022, la mise à jour des modèles comportementaux pour les agents Apex One et Worry-Free Business Security de Trend Micro avait provoqué des défaillances majeures sur les postes de travail Windows 7 32 bits. 

Et ce n’est pas exclusif à Windows : plus récemment, un incident avait touché les sondes Falcon pour Linux, sur les noyaux 5.14.0-410 et plus.

Mais l’un des incidents les plus emblématiques est peut-être celui ayant impliqué McAfee, le 21 avril 2010 : des dizaines de milliers de PC avaient été paralysés, dans le monde entier, majoritairement fonctionnant sous Windows XP SP3. 

Ironie (vraisemblablement douloureuse) de l’histoire, George Kurtz, fondateur et CEO de CrowdStrike, était alors directeur technique monde et vice-président exécutif de McAfee. Intel devait racheter l’éditeur quelques mois plus tard.

Cela soulève bien sûr la question de la validation des mises à jour avant leur distribution, mais aussi la vérification de leur validité et de leur innocuité par l’agent lui-même avant leur ingestion. Un peu comme les contrôles visant à éviter des actes malveillants comme les injections SQL, par exemple. 

L’accès au ring 0 en question

Si une simple mise à jour de contenu pour la sonde de l’EDR est susceptible de faire planter le système lui-même, et pas seulement la sonde, c’est notamment parce que la sonde s’exécute dans le ring-0, l’environnement du noyau, par opposition au user land (l’environnement à moindres privilèges où s’exécutent les simples applications). Ces dernières peuvent planter ; cela n’affectera pas les autres applications et encore moins le système dans son ensemble.

Ce n’est pas la première fois que ce mode de fonctionnement, pour un système de sécurité de l’hôte, est questionné : les chercheurs du projet Zéro de Google s’en étaient par exemple insurgés en 2016, après la découverte d’une vulnérabilité dans l’agent antivirus de Symantec.

Les privilèges offerts par le ring-0 sont régulièrement vantés pour le niveau de visibilité et de contrôle qu’ils fournissent. Et l’on retrouve ces considérations pour d’autres systèmes d’exploitation. Apple a d’ailleurs, avec le temps, pris ses distances des extensions du noyau et développé des API estimées plus sûres d’usage pour les agents antivirus et EDR.

Du côté de Microsoft, si ce choix n’a pas été fait, ce serait plus ou moins à cause de Bruxelles… qui exigeait de l’éditeur qu’il garantisse à ses concurrents, sur le terrain de la sécurité, l’accès au même niveau de privilèges. Mais cela n’imposait pas un accès au ring-0.