Pour les personnes qui ne suivraient pas du tout l’actualité, Crowdstrike est le nom de l’entreprise qui a causé un bug mondial le 19 juillet 2024. Beaucoup d’articles ont été écrits sur le sujet, je vais essayer de faire une synthèse rapide.

Ce qu’il s’est passé

Le 19 juillet dernier, un grand nombre d’ordinateurs sont tombés en panne à travers la planète. Microsoft estime qu’environ 8,5 millions de machines tournant sous Windows ne fonctionnent plus (on peut penser que cette estimation est sous-évaluée). Les ordinateurs touchés présentent tous le même symptôme, le célèbre “écran bleu de la mort”.
Il s’avère que tous les systèmes touchés sont protégés contre les virus et les intrusions par l’EDR (sorte d’antivirus évolué destiné aux entreprises) Falcon, édité par la société Crowdstrike.
Le problème est apparu après que Crowdstrike a diffusé une mise à jour. Un vendredi matin…

George Kurtz, le fondateur et CEO de Crowdstrike, communique quelques heures plus tard sur X. Le message en question est un exemple même de ce qu’il ne faut pas faire. Il semble avoir été écrit par des avocats ; aucune excuse n’est présentée et il tente de réduire la gravité du problème.
Il a beau dire “This is not a security incident”, il n’empêche qu’une mise à jour effectuée par Crowdstrike a provoqué le problème et a rendus indisponibles des millions d’ordinateurs qui fonctionnaient très bien. Quand un incident mondial est provoqué par l’outil qui est justement censé protéger contre les incidents, c’est assez ubuesque.

Il annonce que le problème a été corrigé et qu’une procédure permettant le retour à la normale a été publiée. Néanmoins, on peut remarquer que :

• La correction du problème consiste à avoir déployé une version déboguée de la mise à jour problématique. Ainsi, les ordinateurs qui n’ont pas déjà été impactés ne le seront pas (mais c’est trop tard pour une majorité de systèmes ; après tout, on nous dit bien que les mises à jour de sécurité doivent être installées automatiquement dès leur sortie, pour être bien protégé, non ?).
• La procédure de retour à la normale impose de redémarrer chaque PC en mode sans échec, effacer le fichier incriminé, puis redémarrer le PC. Le seul souci, c’est que cette intervention ne peut se faire que manuellement, et ne peut pas être faite à distance. Pour des entreprises qui possèdent des milliers d’ordinateurs, dont certains étant des serveurs sans clavier/écran, c’est délicat à mettre en œuvre.

Quelque part, on pouvait s’y attendre. À partir du moment où un PC Windows présente un écran bleu, on sait que ça va être compliqué pour tout remettre en état de marche.

On apprend qu’un très grand nombre de lignes aériennes sont paralysées. Certains hôpitaux (notamment aux Pays-Bas) doivent même fermer leurs services d’urgence. Des compagnies ferroviaires et des diffuseurs télé/radio doivent interrompre leurs activités.
Comme certains l’ont fait remarquer, on a là un aperçu de ce qui aurait pu se passer si le bug de l’an 2000 n’avait pas été géré correctement.

George Kurtz finit par communiquer de manière un peu plus acceptable, en s’excusant et en reconnaissant le problème. Il ose quand même dire « CrowdStrike is operating normally, and this issue does not affect our Falcon platform systems. There is no impact to any protection if the Falcon sensor is installed. Falcon Complete and Falcon OverWatch services are not disrupted.« . C’est à la limite du foutage de gueule.

L’origine du problème

Dès le 19 juillet, l’hypothèse d’un pointeur nul non vérifié était détaillée. Cela veut dire qu’un développeur a fait une erreur de débutant et n’a pas vérifié la valeur d’un pointeur avant de vouloir lire la donnée pointée.

Falcon Sensor, le logiciel de Crowdstrike, s’installe au cœur du système d’exploitation, afin de pouvoir dépister les attaques le plus efficacement possible. Mais cela veut dire aussi que si Falcon Sensor plante, c’est tout Windows qui plante. Donc un pointeur non vérifié peut tout planter.
D’ailleurs, Microsoft a osé dire que l’Union européenne avait sa part de responsabilité, puisque c’est elle qui a forcé Microsoft à ouvrir l’accès du kernel Windows aux entreprises tierces, pour autoriser la concurrence dans le domaine de la sécurité. L’Union européenne a répondu que Microsoft n’a jamais exprimé la moindre préoccupation concernant la sécurité suite à cette demande.

La mise à jour du 19 juillet ne concernait pas le logiciel Falcon Sensor lui-même ; le code installé n’a pas été modifié. C’est “juste” un fichier qui − pour faire simple − décrit les attaques à détecter, qui a été déployé. Ce fichier fait partie des “contenus de réponse rapide” qui servent à améliorer la sécurité des systèmes sans pour autant devoir mettre à jour le code installé. Pour la petite histoire, ces fichiers sont mis à jour régulièrement par Crowdstrike, sans prévenir (au contraire des mises à jour logicielles).
On peut donc raisonnablement penser que ce fichier contenait des informations incorrectes, amenant le logiciel à avoir un pointeur nul (sûrement parce qu’il n’a pas trouvé une information dans le nouveau fichier).

Le 06 août 2024, Crowdstrike a publié une “root cause analysis” (analyse des causes profondes), qui tente d’expliquer en détail ce qu’il s’est passé, ainsi que les mesures prises par la société pour que ce type de problème ne se renouvelle pas.
Je vous laisse lire le document si vous voulez connaître tous les détails, mais voici les points principaux :

• Il y avait effectivement un problème dans le fichier mis à jour le 19 juillet. Il contenait 20 champs d’informations, alors qu’il devait en contenir 21.
• Il y avait effectivement un problème de pointeur non vérifié dans le code. Comme il ne recevait que 20 champs, le pointeur du 21e était à nul.
• Les processus de test avaient validé à la fois le code source incriminé et l’évolution du fichier.
  Le code source était toujours testé avec 21 champs remplis.
  Le fichier de réponse rapide était testé avec un wildcard, qui vérifiait que les champs étaient correctement remplis, mais pas que le nombre de champs était correct.

Les remédiations listées sont très précises. Elles indiquent que Crowdstrike a ajouté des étapes de validation, à la fois sur son code source et sur ses contenus de réponse rapide, pour s’assurer que ce genre d’erreur ne pourra pas se reproduire.

Par contre, ce qui est gênant, c’est qu’à aucun moment cette analyse ne parle du vrai problème.

Je m’explique : un développeur qui oublie de tester un pointeur, ça peut arriver. Un programme qui teste un fichier de manière incorrecte, ça peut aussi arriver.
Ce qui est incompréhensible, c’est que chaque morceau (code source ou contenus de réponse rapide) n’est testé qu’unitairement, et toujours de manière automatisée. À aucun moment l’ensemble de l’application n’est simplement déployée sur un ordinateur pour voir si toutes les mises à jour fonctionnent sans faire crasher la machine.
Si le fichier de réponse rapide mis à jour le 19 juillet avait d’abord été déployé sur un simple PC tournant sous Windows, Crowdstrike aurait vu immédiatement que ça générait un écran bleu.

L’analyse parle bien de “canary testing” et d’anneaux de déploiement. Ce que cela veut dire, c’est que les évolutions ne seront plus déployées d’un seul coup sur tous les ordinateurs de la planète, mais qu’elles seront d’abord délivrées à un petit nombre d’utilisateurs, puis à un nombre plus important, et ainsi de suite. L’idée étant que les utilisateurs jouent un rôle de bêta-testeurs, et qu’ils remontent rapidement les problèmes éventuellement rencontrés.
Cette manière de faire n’est pas nouvelle, et est plutôt une bonne pratique. Mais cela ne remplace pas un test de qualification grandeur nature en interne, avant de déployer une évolution (même si c’est sur un nombre limité d’utilisateurs dans un premier temps). Absolument rien n’excuse Crowdstrike de ne pas avoir mené de tels tests ; et il est absolument incompréhensible qu’ils ne fassent toujours pas de tels tests (en tout cas, cela n’apparaît pas clairement dans l’analyse).

Tout informaticien sait à quel point les tests sont difficiles à mettre en place et à maintenir. Mais tout le monde sait aussi à quel point ils sont indispensables pour assurer la qualité.
Il y a un principe fondamental, c’est que les moyens mis en œuvre pour garantir la qualité doivent être en adéquation avec les moyens dont bénéficie l’entreprise, et avec les risques encourus en cas de problème.
Dans le cas de Crowdstrike, on parle d’une entreprise qui était valorisée 83 milliards de dollars (donc ayant les moyens nécessaires) et dont le logiciel est intégré au cœur des systèmes d’importantes entreprises financières, médicales et du transport (donc avait un devoir éthique quant à sa stabilité).

Lorsqu’une petite startup sans argent plante son service non critique, ce n’est pas très grave et on ne peut pas trop lui en vouloir. Et dans certains cas, cela n’empêche pas la petite startup de grossir (par exemple, au début des années 2010, Twitter était connu pour ses indisponibilités et sa fail whale, ce qui ne l’a pas empêchée d’être valorisée 22 milliards de dollars à la même époque).
Mais dans le cas de Crowdstrike, il n’y a rien d’excusable.

Où en sommes-nous maintenant ?

Pas mal de choses sont apparues ces trois dernières semaines, depuis l’incident du 19 juillet.

Pour commencer, Crowdstrike a annoncé il y a quelques jours que 99% des systèmes impactés ont été relancés. C’est déjà ça.

Au niveau mondial, les pertes liées au bug de Crowdstrike sont évaluées à environ 15 milliards de dollars. Il est estimé que seulement 10 à 20% (1,5 à 3 milliards) de ces pertes seront remboursées par les assurances. Le reste (entre 12 et 14 milliards de dollars) est donc une perte sèche pour les entreprises.

Dans les 12 jours qui ont suivi le bug, Crowdstrike a perdu 32% de sa valeur en bourse, passant de 83 milliards de dollars à 57 milliards. En conséquence, l’entreprise est poursuivie en justice par une partie de ses actionnaires, qui estiment que l’entreprise a fait de fausses déclarations au sujet de ses procédures qualité.
On ne peut pas vraiment leur donner tort…

Delta Airlines est la compagnie aérienne qui a perdu le plus d’argent suite au bug, avec plus de 5000 vols annulés. Elle menace de poursuivre Crowdstrike et Microsoft, en leur réclamant un dédommagement de 500 millions de dollars.
Crowdstrike aurait répondu être responsable vis-à-vis de Delta Airlines pour un montant maximal de 10 millions de dollars. Cela semble ridicule quand on sait que le groupe Air France-KLM-Transavia, qui a dû annuler une quarantaine de vols, estime avoir perdu environ 10 millions d’euros.
Crowdstrike et Microsoft mettent en cause la prétendue vétusté du parc informatique de Delta, indiquant que ce serait la raison pour laquelle l’entreprise aurait mis plus de temps que ses concurrents pour rétablir ses systèmes.

Ma vision des choses est différente. Pour l’expliquer, je vais faire une comparaison. Imaginons que vous soyez le maire d’une ville. Vous dépensez une partie de votre budget dans l’entretien du réseau d’eau potable. Comme vous le savez, on ajoute du fluor dans l’eau potable, pour diminuer les risques de caries. Imaginez que l’entreprise qui vous fournit le fluor se trompe et vous envoie du poison ; heureusement, vous le détectez avant qu’il n’ait tué des gens, mais vous devez purger tout votre réseau.
Il semble logique de vouloir envoyer la facture à l’entreprise qui a commis l’erreur (sans laquelle vous n’auriez jamais eu besoin de purger votre réseau d’eau potable). Et si l’entreprise en question ne voulait pas payer, sous prétexte qu’elle a déjà commis la même erreur avec une autre ville, et que celle-ci avait purgé son système bien plus vite que vous, vous lui répondrez que ça ne change absolument rien au fait que vous n’êtes pas responsable.
Là, c’est pareil. Sans le bug de Crowdstrike, causé par les mauvais processus de validation de l’entreprise, Delta Airlines n’aurait pas eu besoin d’annuler des vols, de rembourser des clients, de payer des chambres d’hôtel, etc. le temps de redémarrer ses systèmes.

D’ailleurs, il est assez amusant de voir que Microsoft et Crowdstrike marchent main dans la main face à Delta Airlines, alors qu’en début d’année George Kurtz tirait à boulets rouges sur Microsoft (citation : “What you are seeing here is systematic failures by Microsoft, putting the government at risk.”).

Je pense que ces histoires se démêleront sûrement en dehors des cours de justice, et il y a peu de chances que l’on connaisse le fin mot de tout ça.
Ce qui est intéressant, c’est de voir que Crowdstrike a anticipé ces questions. Dans la FAQ publiée sur la page consacrée au bug, il est indiqué qu’au 30 avril l’entreprise possédait 3,7 milliards de dollars en banque, plus une ligne de crédit de 750 millions de dollars. Il est aussi précisé que l’entreprise génère un flux de trésorerie annuel d’un milliard de dollars. Je pense que ces informations sont là pour dire “ne vous inquiétez pas, on a les reins solides, même si on est poursuivis on saura faire face”.
À mon avis, puisqu’ils se gargarisent d’avoir un tel trésor de guerre, ils feraient bien de l’utiliser pour couvrir les pertes de leurs clients, plutôt que de leur rejeter la faute.

Pour finir, il a été déterré le fait que l’antivirus McAfee avait connu un problème similaire en 2010 (le problème était aussi une mise à jour vérolée ; la solution était aussi de passer manuellement sur chaque ordinateur ; on parlait là de “seulement” plusieurs dizaines de milliers de PC touchés). En soi, rien d’amusant là-dedans, si ce n’est que le directeur technique de McAffee à l’époque n’était autre que George Kurtz !
On pourrait se dire qu’il s’agit d’une coïncidence, que chaque incident ne dépendait pas de lui directement. Je pense au contraire que c’est la direction qui crée la culture d’une entreprise, et qu’il n’a sûrement pas mis suffisamment l’accent sur une approche “qualité totale” dans les procédures de test et de validation.

Quels enseignements en tirer ?

Le pire, c’est qu’il n’y a rien de nouveau à apprendre. Juste du bon sens, et des choses qu’on savait déjà :

• Petit rappel, on ne met pas en production le vendredi, pour ne pas risquer de passer un week-end à résoudre des problèmes.
   
• Les tests unitaires automatisés, c’est bien, mais ce n’est pas suffisant. Vous pouvez avoir tout votre code qui est couvert par des tests unitaires, et malgré tout avoir un produit qui ne fonctionne pas comme prévu, soit parce que les tests sont bogués, soit à cause d’effets de bords entre les différents modules (une fois qu’ils interagissent). Rien ne remplace des tests d’intégration.
   
• Avant de déployer quelque chose en production, on le valide d’abord en préproduction (ou staging, ou qualification, appelez-le comme vous voulez). C’est-à-dire dans un environnement le plus proche possible de la production. Si quelque chose doit exploser en production, et que ça aurait explosé de manière identique en préprod, vous n’avez aucune excuse pour ne pas l’avoir détecté.
   
• Plus vous avez de moyens et/ou plus vos clients dépendent de vous, plus vous devez investir afin de proposer un produit stable et fiable. Faire un produit low cost sans garantie de service est acceptable ; faire un produit premium qui coûte cher mais avec des garanties élevées est acceptable ; faire un produit qui se présente comme premium, mais avec une qualité low cost pour maximiser les profits, ce n’est pas acceptable.
   
• La culture d’entreprise, c’est notamment choisir entre mettre l’accent sur la qualité ou sur les profits ; entre investir sur le support client ou sur le marketing. C’est le rôle de la direction. Et même si diriger est toujours une affaire de compromis, cela ne doit pas devenir une affaire de compromission.
   

Edit du 13 août : Manifestement, Crowdstrike fait des efforts de transparence. Comme je l’ai dit plus haut, ce n’est pas encore idéal à 100%, mais ils ont le mérite d’essayer (on en connait d’autres…). Leur président, Michael Sentonas, vient de se voir remettre le prix du “Most Epic Fail” à la conférence Def Con de Las Vegas. Plutôt que de la jouer profil bas, ils ont choisi une stratégie de communication proactive : ils reconnaissent leurs erreurs et disent qu’ils vont tout faire pour regagner la confiance de leurs clients. Même si on peut douter de la méthode, c’est ce qu’ils ont de plus intelligent à faire d’un point de vue marketing.