Maintenant que le soufflet est retombé, prenons un peu de recul sur l'incident CrowdStrike qui a affecté 8,5 millions de machines le 19 juillet 2024. Pour mémoire, le déploiement de la mise à jour défectueuse n'a duré que 79 minutes ... qui vont certainement coûter très cher ! 

Avant toute chose, ce que l'on peut noter c'est que les professionnels et les bonnes volontés qui ont été mobilisés pour répondre à l'incident n'ont pas failli à leur tâche. Mais comment expliquer cette ampleur ? Ce que l'on sait, c'est que la panne mondiale du 19 juillet dernier est le résultat d'une mise à jour.

La mise à jour en question impliquait un fichier de configuration connu sous le nom de Channel File 291, conçu pour cibler de nouveaux pipes utilisés par les 2C (command & Control) des attaquants. Cette mise à jour semble avoir été “malformée", en tout cas, elle est passée à travers les vérifications d'usage et a déclenché une erreur logique dans le pilote de CrowdStrike, ce qui a provoqué le tant redouté écran bleu de la mort sur les systèmes Windows touchés.

CrowdStrike a rapidement identifié le problème et déployé un correctif en quelques heures, fourni des conseils techniques détaillés, y compris des étapes de mitigation et des outils pour identifier les hôtes impactés.

Le terme correctif doit être pris avec des pincettes car il s'agit d'une correction de la mise à jour défectueuse, pas des machines en pannes. Pour les 8,5 millions de Pc touchés, ce sont les admins, les responsables IT, etc qui ont réparé chaque système en les redémarrant en mode sans échec, puis trouvé le fichier de mise à jour corrompue Channel 291 dans le dossier CrowdStrike pour le supprimer et redémarrer.

Pour comprendre pourquoi et comment une mise à jour défectueuse peut provoquer un tel crash, il faut d'abord distinguer les notions de mode utilisateur et de mode noyau dans Windows :

Le système d'exploitation de Windows utilise un système d'anneaux pour séparer le code en deux zones distinctes : le mode noyau pour le système d'exploitation lui-même et le mode utilisateur où les applications s'exécutent. 

Le mode noyau effectue des tâches telles que la communication avec le matériel et les périphériques, la gestion de la mémoire, la planification des threads, et toutes les fonctions essentielles que le système d'exploitation fournit. 

En théorie, le code des applications ne s'exécute jamais dans le noyau et le code noyau ne s'exécute jamais en mode utilisateur. Le mode noyau est plus privilégié, ce qui signifie qu'il peut voir toute la carte mémoire du système et ce qui s'y trouve sur n'importe quelle page physique et à tout moment. En mode utilisateur vous ne voyez que les pages de la carte mémoire que le noyau vous laisse voir.

Si une application a besoin d'un service fourni par le noyau, elle ne sera pas autorisée à s'exécuter directement dans le noyau. L'application "demande" au noyau (par le biais d'un thread) et attend la réponse. Un thread côté noyau examinera alors les arguments spécifiés, validera tout et exécutera le code noyau requis. Une fois terminé, le thread noyau renverra les résultats au thread utilisateur.

En cas de dysfonctionnement en mode utilisateur et noyau, la différence de traitement saute au yeux. Lorsqu'un code d'application plante, l'application plante et l'on a un message d'erreur. Lorsque du code dans le noyau plante, le système entier plante. Il crash parce qu'il le doit, pour se protéger. Par exemple si le noyau détecte qu'il est sur le point de libérer de la mémoire qui a déjà été libérée, il va interpréter cette anomalie comme une défaillance critique (c'est une condition inattendue) et Windows va afficher un écran bleu, parce que s'il laisse le code s'exécuter, les conséquences peuvent être pires pour l'OS et les fichiers enregistrés sur la machine (dont ceux des utilisateurs).

Ce n'est pas un mécanisme spécifique à Windows. C'est valable pour tous les systèmes d'exploitation comme Linux et macOS aussi. Cependant MacOS plante moins et l'écran est... rose, on voit pourquoi un peu plus loin. 

Peu de choses s'exécutent dans le noyau. Les seules choses qui vont "en théorie" dans le noyau sont celles qui doivent l'être, comme le planificateur de threads et le gestionnaire de tâches, et les fonctionnalités qui doivent accéder au matériel, comme un pilote de périphérique qui parle à un processeur graphique. Ainsi, la totalité de ce qui est exécuté en mode noyau se résume vraiment au système d'exploitation lui-même et aux pilotes de périphériques, en théorie.

L'EDR Falcon de Crowdstrike est une (bonne) solution de sécurité avancée qui contrairement à un antivirus classique ne va pas simplement chercher des définitions de fichiers. La solution de CrowdStrike analyse un large éventail de comportements d'applications pour essayer de détecter de manière proactive de nouvelles menaces avant qu'elles ne soient catégorisées et répertoriées. 

Et pour être capable de surveiller le comportement des applications à partir d'un emplacement sûr, une partie du code de l'EDR est dans le noyau.

CrowdStrike a donc écrit un pilote de périphérique même s'il n'y a pas vraiment d'interaction avec un périphérique matériel. Ce bout de code a un accès complet et sans restriction aux structures de données du système et aux services dont il a besoin pour s'exécuter.

Microsoft propose la certification WHQL (Windows Hardware Quality Labs) aux éditeurs, de sorte que les pilotes certifiés WHQL sont signés avec un certificat numérique car considérés robustes et fiables. Tant que le pilote lui-même ne change jamais, le certificat reste valable.

En théorie toujours, à chaque fois qu'une nouvelle menace se présente un éditeur devrait réécrire le pilote et repasser la certification, ce qui implique des délais. Ce n'est pas acceptable pour une solution de sécurité qui doit être maintenue à jour en temps réel pour offrir la protection la plus haute à ses clients.

Pour contourner ces délais, CrowdStrike peut inclure des fichiers de définition qui sont traités par le pilote mais non réellement inclus avec lui. C'est ce qui a été envoyé dans la mise à jour. 

Ainsi, lorsque le pilote CrowdStrike est sollicité, il accède à un dossier sur la machine à la recherche de ces fichiers de définition dynamique pour exécuter son code, comme par exemple le fichier Channel File 291 récupéré par 8,5M de Pc le 19 juillet dernier.  Le contenu de ces fichiers n'est pas connu mais il est récupéré dans le cadre de l'exécution du pilote dans le noyau Windows. C'est là que se pose problème. 

La cause précise du bug, n'a pas été révélée. Est-ce que ce fichier contient des bouts de code, des variables qui vont ensuite s’exécuter dans le noyau ?  En revanche, on peut s'interroger sur la manière dont le pilote Crowdstrike gère et traite les mises à jour, comment les arguments qui sont passés dans le noyau sont vérifiés en amont.

On peut aussi tout autant s'interroger sur le fait que Windows n'est pas résilient en cas d'échec de chargement d'un pilote. Pourquoi ne pas essayer de démarrer sans lui la prochaine fois ? 

En fait, Windows propose un certain nombre d'options comme par exemple démarrer avec la dernière configuration valide connue. Cependant, le problème est que le pilote CrowdStrike est un pilote de démarrage, s’exécutant en mode noyau. En d'autres termes, il doit être installé pour démarrer le système d'exploitation... c'est le piège.

La plupart des pilotes de démarrage sont inclus dans les packages de pilotes qui sont fournis avec Windows, et l'OS les installe automatiquement.

L'opération de remédiation dans le cas Crowdstrike n'est pas complexe mais nécessite un accès physique à la machine (l'opération est bien décrite sur l'internet) pour la redémarrer en mode sans échec, uniquement avec le nombre minimal de pilotes Windows requis pour le système fonctionne. 

De précédents problèmes de mise à jour avec Linux : 

En avril 2024 une mise à jour CrowdStrike avait déjà affecté les clients utilisant la distribution Debian de Linux. La mise à jour a provoqué le plantage de ces systèmes et les a empêchés de redémarrer normalement. Le problème a été reconnu par CrowdStrike le lendemain, mais il a fallu des semaines pour déterminer la cause exacte et mettre en œuvre un correctif. 

Un autre problème similaire est survenu un mois plus tard, le 13 mai, cette fois affectant la distribution Rocky Linux. Ces serveurs ont connu des blocages après la mise à jour vers Rocky Linux 9.4. Ce qui s’est passé était prévisibles, sauf qu'aujourd'hui personne ne fait le malin en déclarant qu'il avait prévenu tout le monde.   

Tiens, Apple est absent de la liste : 

Curieusement, les machines Apple sont absentes de la liste, pourtant Crowdstrike fournit des solutions de sécurité pour Mac OS via sa plateforme Falcon Plus. Pourquoi ?  Falcon pour Mac OS n'installe pas d'extensions de noyau comme c'est le cas sur Windows. 

Apple a complètement abandonné l'utilisation des extensions de noyau, obligeant les éditeurs de solution de sécurité à utiliser les extension systèmes fournies par la marque à la pomme. En d'autres termes Crowdstrike n'a pas le choix, l'accès au noyau de Mac OS n'est pas permis. De plus, aucune institution, aucun gendarme de la concurrence n’a obligé Apple à ouvrir son OS qui par définition est un écosystème fermé. 

Microsoft responsable ou pas ?

Pas vraiment. Chez Microsoft comme chez CrowdStrike on est bien conscient des risques lorsqu'on exécute du code en mode noyau. Le noyau du système d'exploitation c'est son cœur, le niveau le plus bas et élémentaire. 

Une des principales fonction du noyau d’un OS est d’effectuer l’interaction entre les programmes, l’utilisateur et le matériel. Le matériel d'un Pc fonctionne en général à partir de pilotes (drivers) qu’un fabriquant peut fournir.

On peut se demander pourquoi Microsoft a autorisé CrowdStrike à exécuter du code au sein du noyau. Cette solution nécessite-t-elle une intégration profonde à ce point ? Eh bien oui, les solutions de sécurité tendent à s'installer au plus bas niveau possible pour mieux surveiller les menaces, CrowStrike n'est pas une exception. 

Un peu de recherche historique nous montre qu'à l'origine le noyau de Windows n'était pas ouvert. Par exemple, les pilotes graphiques ne s'exécutaient pas en mode noyau. Aujourd'hui ce n'est plus le cas, pour des raisons de performance les pilotes vidéo ont été déplacés au niveau du noyau. 

Mais le trajet a aussi été effectué en sens inverse. Par exemple, à l'origine, les pilotes d'imprimantes étaient dans le noyau Windows. Seulement, les imprimantes sont devenues complexes, connectées en réseau, accessibles depuis l'extérieur, donc risquées. Le modèle de pilote d'imprimante a été déplacé en mode utilisateur pour rendre Windows beaucoup plus robuste et stable.

Donc la faute à... la Commission Européenne ?

En 2009, la firme de Redmond avait tenté de verrouiller l'accès à son système d'exploitation mais la commission Européenne en a décidé autrement. 

Selon Microsoft, un accord d'inter-opérabilité imposé par la Commission européenne en 2009 pourrait avoir conduit l'éditeur de Windows à ouvrir ses technologies, ce qui a permis à un partenaire comme CrowdStrike de provoquer la panne du 19 juillet dernier. 

Il y a bien eu un accord en 2009 et conformément aux conditions fixées et Microsoft a été amené à fournir aux éditeurs de logiciels de sécurité tiers l'accès aux API utilisées par ses produits de sécurité dans les systèmes d'exploitation Windows Client et Server.

L'EU n'a pas trouvé d'accord avec Apple et Google mais il faut rappeler que la part de marché des systèmes d'exploitation de Microsoft en 2009 était de plus de 95 %. Ça a bien changé depuis.

Quoiqu'il en soit, après avoir rappelé que cet accord de 2009 avec l'EU était une des raisons de l'incident, Microsoft semble avoir nuancé sa position. Surement que pointer le doigt vers l'EU (alors que Microsoft n'est pas à priori responsable) n'est pas très judicieux. 

Conclusion et enseignements pour l'avenir :

L'événement du 19 juillet 2024 n'est pas anodin. En prenant un peu de recul on a vu que plusieurs facteurs favorable étaient en place pour qu'il survienne (Monopole, architecture, performance, compétition, régulation...), sans compter pour celui ou celle qui observe le marché de la tech, un contexte de vagues de licenciements massifs, et cela depuis plusieurs mois.

Dans le cas présent, jeter l'opprobre sur Microsoft est injuste. L'incident a faussement été attribué à Microsoft le jour même. C'est une mise à jour de Crowdstrike qui est à l'origine de la pane sur 8,5 Millions de machines. Pas de mise à jour, pas de pane, c'est le fait générateur. De plus la firme de Redmond a bien été obligée par l'UE d'ouvrir son système il y a 15 ans, alors qu'elle avait la même position qu'Apple. 

Blâmer Crowdstrike est tout aussi injuste. La majorité des solutions de sécurité sont installées en bas niveau, cet incident aurait pu survenir chez un autre éditeur et concurrent.  

Néanmoins, on peut tout de même s'interroger sur les contrôles et les vérifications qui ont été effectuées avant de distribuer la mise à jour. 

En effet, il ne s'agit pas d'une anomalie exotique sur quelques machines ayant une configuration particulière. C'est l'ensemble des postes clients de la solution qui ont été affectés. La question de la vérification (et non pas par des automates) et des tests unitaires réalisés en amont est toute légitime. Manifestement, ils ont fait défaut.  

Les éditeurs de sécurité évoluent dans un marché très concurrentiel, être le premier à disposer d'une solution à jour, proactive et en temps réel contre les menaces est un avantage compétitif. Cette compétition pousse les éditeurs à confondre vitesse et précipitation. 

Au niveau des éditeurs et de Microsoft, il y a surement beaucoup de leçons à tirer de cet incident. Certes, Microsoft s'est fait un peu tordre le bras pour ouvrir son système d'exploitation, mais les conditions d'accès au noyau devraient (et vont certainement) être revues. Microsoft peut revoir son architecture noyau, ses API mais ça risque être complexe car beaucoup de produits partenaires et aussi de Microsoft ont des intégrations de bas niveau. L’écosystème Windows est beaucoup plus vaste que celui de ses concurrents et il y a plus de chances que l’éditeur pose de nouvelles conditions techniques à ses partenaires. 

Des alternatives techniques déjà testées vont émerger pour contourner cet accès au noyau tout en essayant d'en conserver les avantages de sécurité et de performance, tant du côté de Windows que des éditeurs. CrowdSrike propose bien sur Mac des solutions qui fonctionnent sans accès bas niveau, ce qui permet d’éviter le crash du système.  

Côté réglementaire, il y a peut-être quelque chose à revoir, le paysage de 2009 à bien évolué en 15 ans et les OS ouverts à ce point présentent un réel risque. De plus, les règles ne sont pas les mêmes pour tout le monde. 

Enfin, on peut souligner que Microsoft propose sur ces OS une clé de récupération permettant de redémarrer un Pc qui ne boot pas. Cela aurait permis de gagner du temps, Mais combien de DSI l'avaient mise en œuvre avant l’incident ?

Ultimement, d'aucun rappelle à envie que l'on ne fait pas de mise à jour un vendredi. Oui mais voilà en 2024, la mise à jour d'une solution de sécurité comme un EDR si l'on veut rester protégé, ça ne fonctionne pas comme ça. 

Quoiqu'il en soit, le fait de constater qu'une panne sur 8,5 Millions de Pc dans le monde suffit pour mettre à l'arrêt des pans entiers de l'économie, de l'industrie et certains services étatiques, doit bien faire réfléchir et amener à tirer quelques enseignements sur nos architectures, la fiabilité technique, la résilience et la sécurité de la sécurité. 

Les assureurs seront également amenés à réfléchir sur le sujet, mais cela fera l'objet d'un prochain papier.