Selon Microsoft, 97 % des ordinateurs frappés par la panne CrowdStrike fonctionnent de nouveau. Rappelons que 8,5 millions de PC sous Windows rencontraient des écrans bleus à répétition, à cause du plantage d’un pilote installé par la solution de sécurité Falcon de CrowdStrike. Ce plantage était entrainé par la lecture d’un simple fichier indiquant au capteur comment mieux repérer les tentatives d’attaques malveillantes.

Cette panne mondiale a soulevé de nombreuses questions. La plus importante était sans doute de savoir comment une telle mise à jour, a priori sans danger, a pu aboutir à un tel résultat. La seconde était en filigrane : le système Windows ne peut-il pas être revu, pour ne plus laisser aucun composant tiers en espace noyau, à la manière de la décision radicale d’Apple en 2020 avec macOS Big Sur ?

Sur la première, CrowdStrike s’est expliquée, détaillant le fonctionnement de son logiciel Falcon, des composants impliqués, les types de mises à jour ainsi que la manière de les tester et de les valider. L’éditeur américain a clamé que de nouveaux tests et sas de validation allaient être mis en place. Objectif, bien sûr : ne pas reproduire un tel concours de circonstances. Et pour cause, puisque le cœur du problème est que ses tests ont validé la petite mise à jour fautive alors qu’elle contenait des informations erronées.

Pour la seconde, Microsoft a pris la parole dans un billet publié samedi soir.

Microsoft confirme l’origine du problème

« Nos observations confirment l'analyse de CrowdStrike selon laquelle il s'agit d'une erreur de sécurité de lecture hors limites de la mémoire dans le pilote CSagent.sys développé par CrowdStrike », indique d’abord Microsoft.

Ces observations sont fondées sur les propres analyses de Microsoft, qui s’est servi du débogueur WinDBG Kernel et de plusieurs extensions. L’entreprise précise qu’il s’agit d’outils gratuits accessibles à tous. Ils servent à examiner les crash dumps (fichiers de vidage mémoire), notamment ceux produits par Windows en cas d’écran bleu (BSOD). Vous avez peut-être déjà observé, sur un tel écran, un pourcentage augmentant en bas à gauche. Il correspond à la création de ce fichier. Dans la plupart des cas, ils sont créés par l’infrastructure Windows Error Reporting (WER).

« Malheureusement, avec les données WER, nous ne recevons qu'une version compressée de l'état et nous ne pouvons donc pas désassembler pour voir un ensemble plus large d'instructions avant le crash, mais nous pouvons voir dans le désassemblage qu'il y a une vérification de NULL avant d'effectuer une lecture à l'adresse spécifiée dans le registre R8 », précise néanmoins Microsoft.

L’intérêt du module en espace noyau

La firme confirme également que le fameux module csagent.sys – qui a provoqué le plantage à l’origine de la panne mondiale – est bien enregistré en tant que pilote de filtre de système de fichiers. Une méthode classique selon Microsoft pour les agents de lutte contre la cybermalveillance. « Les produits de sécurité s'en servent souvent pour analyser tout nouveau fichier enregistré sur le disque, comme le téléchargement d'un fichier via le navigateur », ajoute la société.

En outre, ces filtres peuvent être utilisés pour faciliter la surveillance du système. Sur Windows, une API du système de fichiers est dédiée à cette tâche. Elle permet à un pilote d’être notifié quand une opération donnée sur le système de fichiers est réalisée. Il peut s’agir de l’arrivée d’un nouveau fichier, d’une modification de son contenu, d’un déplacement, etc. Or, le fichier de canal 291, qui a entrainé le plantage du module csagent.sys (erreur de lecture hors limites de la mémoire), devait modifier la logique du capteur sur ces opérations. Sa présence dans le crash dump signifie qu’il a bien été lu, confirme Microsoft.

Il reste toutefois un flou sur le degré de corrélation entre ce fichier et la violation d'accès. Elle « nécessiterait un débogage supplémentaire du pilote à l'aide de ces outils, mais n'entre pas dans le cadre de ce billet de blog », indique l’entreprise. On peut donc s’attendre à des informations supplémentaires. Autre précision intéressante, les machines ayant généré des rapports ne représentent qu’une partie de toutes celles touchées par le problème, car le partage de ces informations est volontaire en entreprise.

Microsoft défend son modèle

La semaine dernière, Microsoft avait pointé un doigt accusateur vers l’Europe : si le monde connaissait une telle panne, c’était la faute de la Commission. L’éditeur rappelait l’existence d’un accord conclu en 2009, selon lequel les éditeurs tiers devaient avoir les mêmes possibilités que Microsoft sur Windows. En clair, les mêmes API et capacités pour tous. À l’époque, la firme avait dit tout son enthousiasme.

Dans le billet publié ce week-end, point d’accusation ni même mention de l’Europe. À la place, Microsoft pose la question : « Pourquoi les solutions de sécurité s'appuient-elles sur les pilotes du noyau ? ».

Plusieurs éléments de réponse sont donnés. Les performances d’abord, car les processus résidant dans l’espace noyau ont une priorité plus élevée. Microsoft donne en exemple la collecte et l’analyse d’une activité réseau à haut débit. Côté grand public, le cas le plus connu est le pilote graphique, dont une partie réside en espace noyau, pour des questions de performances. Depuis Vista cependant, tout ce qui n’a pas spécifiquement besoin de ce niveau de performances est relégué en espace utilisateur (c’est le cas de tous les pilotes de périphériques par exemple).

L’espace noyau permet aussi de mieux se prémunir contre l’effraction. Windows fournit un mécanisme nommé Early Launch Antimalware (ELAM), permettant de lancer d’abord certains pilotes spécifiques. Le pilote de CrowdStrike est ainsi labellisé ELAM et se charge au début de la séquence de boot. C’est le cas généralement de toutes les solutions de sécurité de type antivirus. Ce chargement permet d’observer l’activité aussi tôt que possible et rend la solution de sécurité plus résistante à sa désactivation par un malware.

Compromis sur la fiabilité

C’est l’un des aspects les plus intéressants du billet : « Dans le cas général, il existe un compromis que les fournisseurs de sécurité doivent justifier lorsqu'il s'agit de pilotes de noyau. Les pilotes de noyau offrent les propriétés susmentionnées au détriment de la résilience ».

Microsoft explique que le fonctionnement en espace noyau se fait « au niveau le plus fiable de Windows ». Les capacités de confinement et de récupération y sont « par nature limitées ». Les éditeurs tiers sont donc encouragés à peser « soigneusement » le pour et le contre de composants dans cette zone, car la visibilité et la résistance à l’altération se payent au prix d’un risque pour la fiabilité générale. C’est ce qu’a démontré la panne CrowdStrike.

Microsoft ajoute qu’il est tout à fait possible pour un éditeur de sécurité de « trouver un équilibre ». Par exemple, en plaçant des capteurs minimaux en espace noyau pour la collecte de données et la mise en œuvre, et en déportant tout le reste en espace utilisateur. Ce « reste » comprend notamment la gestion des mises à jour et l’analyse du contenu.

La société rappelle certains mécanismes de sécurité existant dans Windows en espace utilisateur, comme les enclaves de sécurité basées sur la virtualisation (VBS), les processus protégés, les événements ETW ou encore l’Antimalware Scan Interface (AMSI).

Une collaboration insuffisante

Le billet ajoute qu’il existe un réseau collaboratif entre Microsoft et les éditeurs de solutions de sécurité. Nommée Microsoft Virus Initiative (MVI), elle établit « un dialogue et une collaboration au sein de l'écosystème de sécurité Windows afin d'améliorer la robustesse de l'utilisation de la plateforme par les produits de sécurité ».

L’éditeur donne ensuite quelques informations sur le fonctionnement du réseau. Par exemple, les partenaires qui participent « activement » reçoivent des avantages « tels que des briefings techniques et des boucles de retour d'information avec les équipes produits de Microsoft ».

La firme évoque également le cas des pilotes WHQL (Windows Hardware Quality Labs), qui doivent subir de nombreux tests pour recevoir l’estampille. Le processus existe depuis longtemps et aboutit, de manière générale, à une qualité supérieure pour les pilotes. Cependant, Microsoft donne l’info sans préciser si WHQL s’applique ici. Et, si c’est le cas, pourquoi tous les tests réalisés n’ont pas permis de relever le problème.

Des mesures pour « moderniser l’approche »

Microsoft liste dans son billet les fonctions de sécurité activées par défaut dans Windows 11. L’entreprise prévoit donc de « collaborer avec l'écosystème de lutte contre les logiciels malveillants afin de tirer parti de ces fonctions intégrées pour moderniser leur approche, en contribuant à soutenir et même à accroître la sécurité et la fiabilité ».

Il est ainsi prévu de conseiller les éditeurs tiers, pour les informer des « meilleures pratiques et des technologies pour rendre plus sûre la mise à jour des produits de sécurité ». N’est-ce pas pourtant l’objectif de la MVI ?

Microsoft veut en tout cas réduire la « nécessité d'utiliser des pilotes de noyau pour accéder à des données de sécurité importantes ». Il est également question d’encourager l’adoption de fonctions comme les enclaves VBS ou de l’attestation de haute intégrité. Curieusement, Microsoft rappelle qu’elle s’est engagée sur le langage Rust, avec une inclusion à venir dans le noyau Windows.

Ce que ne dit pas Microsoft en revanche, c’est que si nombre de fonctions de sécurité sont activées par défaut dans Windows 11, le système est loin d’être majoritaire sur les PC. Windows 10 compte encore pour plus de 60 % du parc Windows. Son support technique est cependant censé s’arrêter le 14 octobre 2025 et Microsoft espère sans doute une vaste vague de renouvellement matériel. C’est peut-être son argument auprès des éditeurs tiers : investissez dans les nouvelles technologies, tout le monde finira par les avoir.