Le 19 juillet au matin, la société spécialisée dans la cybersécurité CrowdStrike publiait une mise à jour de son logiciel. Rien d’anormal jusque-là, mais le nouveau fichier avait un gros problème : il provoquait des plantages et des écrans bleus en boucle sur les PC Windows, y compris les serveurs.

Un bug, des conséquences importantes

Le grand public a alors découvert l’existence de CrowdStrike pour une bonne partie, et sa présence dans de nombreux systèmes critiques. En effet, difficile de passer à côté des pannes en série qui ont découlées de ce bug : des annulations dans les aéroports, une bourse au ralenti, des employés au chômage technique faute d’ordinateurs utilisables, etc.

Les ordinateurs de la très grande majorité des utilisateurs de Windows n’étaient pas directement affectés. Il faut en effet avoir CrowdStrike, une solution pour les entreprises, pour être directement touché. Indirectement par contre, c’était une autre histoire.

Le week-end suivant la panne, CrowdStrike publiait de premiers détails techniques sur la panne. De son côté, Microsoft annonçait que 8,5 millions de machines étaient affectées, soit moins de 1 % de l’ensemble du parc Windows. Suffisant pour provoquer une belle pagaille un peu partout dans le monde.

Cinq jours après le fiasco, l’entreprise détaillait la chronologie des événements et annonçait des mesures correctives pour éviter que cela puisse se reproduire. On y apprenait notamment que les mises à jour subissaient des tests avant d’être déployées, mais que celle du 19 juillet était passée entre les mailles du filet à cause d’un bug dans le validateur de contenu.

• [MàJ] Fiasco CrowdStrike : détails techniques, 8,5 millions de machines touchées selon Microsoft
• Fiasco CrowdStrike : la chronologie des évènements, les mesures prises par l’éditeur

Le Root Cause Analysis est là

Hier, CrowdStrike a mis en ligne un nouveau document attendu : le Root Cause Analysis (RCA), un PDF de 12 pages qui détaille les causes profondes et les actions mises en place. Une nouvelle fois, l’éditeur « s’excuse sans réserve » auprès de ses clients. Le fondateur et CEO de l’entreprise, George Kurtz, fait de même. Il précise au passage que 99 % des sondes sous Windows étaient de nouveau fonctionnelles au 29 juillet, avec une variation de ±1 % au fil des semaines, contre 97 % le 24 juillet, cinq jours après l’incident.

This morning, we published the Root Cause Analysis (RCA) detailing the findings, mitigations and technical details of the July 19, 2024, Channel File 291 incident. We apologize unreservedly and will use the lessons learned from this incident to become more resilient and better…

— CrowdStrike (@CrowdStrike) August 6, 2024

Dans son introduction, le rapport détaillé sur les causes profondes de la panne remonte en février 2024, quand CrowdStrike ajoute à son capteur Falcon une nouvelle fonctionnalité pour détecter de nouveaux types d’attaques (Template Type) sous Windows. C'est pour cela que seul le système de Microsoft était impacté. CrowdStrike est aussi disponible sur MacOS et Linux, mais ils ne pouvaient donc pas être affectés.

Quelques jours plus tard, le 5 mars, un premier Rapid Response Content est déployé (pour le Channel File 291) après une série de tests, affirme l’entreprise. Les Rapid Response Content sont au capteur Falcon ce que les fichiers de définition sont aux antivirus : ils permettent de se tenir à jour sur les attaques, sans actualiser le capteur en lui-même.

Février, mars, avril… tout va bien avec la nouvelle config

D’autres mises à jour sont ensuite déployées entre les 8 et 24 avril, toujours via les Rapid Response Content. CrowdStrike ajoute que toutes ces versions ont fonctionné comme prévu en production.

Les Rapid Response Content sont traités par le Content Interpreter du capteur, « à l'aide d'un moteur basé sur des expressions régulières ». Chaque Rapid Response Content est donc « associé à un Template Type spécifique », pour chaque version du capteur.

Avec la nouvelle version 7.11 de son capteur, CrowdStrike a ajouté un Template Type pour prendre en charge de nouvelles techniques d’attaques, notamment les canaux nommés et d’autres communications interprocessus dans Windows (IPC). C’est le rôle du Channel File 291.

Du Rapid Response Content au Rapid BSOD

La suite, on la connait : deux nouvelles instances sont déployées via une mise à jour Rapid Response Content à 6h09, heure française, le 19 juillet. Et là, c’est le drame. Une des deux « faisait évoluer la nouvelle fonctionnalité publiée pour la première fois en février 2024 », avec les conséquences que l’on connait.

L’explication est finalement assez simple : « Le capteur attendait 20 champs en entrée, alors que la mise à jour en fournissait 21. Dans cette situation, la non-concordance a entraîné une lecture mémoire hors limites, provoquant un crash du système ».

Cette différence entre le nombre de paramètres proposés et ceux attendus « a échappé à plusieurs couches de validation et de tests ». CrowdStrike n’a rien vu non plus lors des « stress test » sur son Template Type ni lors des premiers déploiements sans encombre quelques mois auparavant.

Un paramètre en plus ou en moins, et c’est le drame

Pourquoi en juillet et pas avant, ni pendant les tests ? « Cela était dû en partie à l'utilisation de critères de correspondance génériques pour la 21e entrée lors des tests et dans les premières Template Instances IPC ». Le bug était donc déjà présent lors des précédentes mises à jour, sans pour autant se déclencher.

Lors de la mise à jour du 19 juillet, une des deux mises à jour « a introduit un critère de correspondance non générique pour le 21e paramètre d'entrée ». Et patatras : « Ces nouvelles Template Instances ont conduit à une nouvelle version du fichier Channel File 291 qui nécessitait alors que le capteur examine le 21e paramètre d'entrée ».

Jusqu’à présent, le 21e paramètre n’avait pas d’importance et n’était pas utilisé par les Template Instances IPC. Mais les capteurs qui ont reçu la nouvelle version du Channel File 291 et dès « la prochaine notification IPC du système d'exploitation, les nouvelles Template Instances IPC ont été vérifiées ».

La 21e entrée a alors fait son entrée fracassante. « Le Content Interpreter n'attendait que 20 valeurs. Par conséquent, la tentative d'accès à la 21e valeur a généré une lecture de mémoire hors limites […] et a entraîné un crash du système ».

Simple, mais diablement efficace. Cela explique aussi pourquoi CrowdStrike faisait planter en boucle les ordinateurs : la même erreur se répétait sans cesse à chaque démarrage. On comprend aussi pourquoi une mise à jour de l’application permettait de résoudre le souci… encore fallait-il que la mise à jour se fasse avant le plantage. Certains y arrivaient, d’autres non. Les recommandations étaient d’essayer de redémarrer sa machine une quinzaine de fois.

Une série de problèmes et au moins autant de correctifs

Pour résumer, le bug est la conséquence de plusieurs éléments : « l'inadéquation entre les 21 entrées du Content Validator et des 20 du Content Interpreter, le problème de lecture hors limites qui était latent dans le Content Interpreter et l'absence d'un test pour vérifier spécifiquement les critères de correspondance non génériques dans le 21e champ ».

Plusieurs correctifs ont été mis en place. Désormais, le Content Compiler du capteur vérifie le nombre de paramètres. Il a déjà été mis en production le 27 juillet dans les outils internes de la société. Le programme vérifie au passage qu’il n’existe pas de problème sur le nombre de paramètres des Template Types, quelle que soit la plateforme.

Le Content Interpreter vérifie également qu’il ne va pas lire des données mémoire hors limite, une sage précaution… Une mise à jour sera déployée sur toutes les versions à partir de la 7.11 du capteur, avec une disponibilité générale prévue au 9 août. Bien évidemment, le nombre d’entrées attendues et proposées ont été alignées, à 21.

Ce bug « ne peut plus se reproduire »

Enfin, toujours selon l’analyse de CrowdStrike et celle d’un tiers (dont le nom n’est pas précisé), « ce bug n'est pas exploitable par un acteur malveillant ». L’entreprise ajoute avoir évidemment procédé à des corrections. Dorénavant, un tel scénario avec le Channel File 291 « ne peut plus se reproduire ».