L’incident où CrowdStrike a aussi endommagé Debian et Rocky Linux quelques mois plus tôt

• Indépendamment de la panne massive avec BSOD sous Windows, des mises à jour de CrowdStrike avaient déjà provoqué des interruptions de serveurs dans des environnements Debian et Rocky Linux
• En avril, dans un civic tech lab, tous les serveurs Debian Linux ont planté simultanément juste après une mise à jour et ont refusé de démarrer ; la restauration n’a été possible qu’après la suppression de CrowdStrike
• Cette configuration Debian était considérée comme prise en charge, mais elle n’était pas compatible avec la dernière version stable de Debian, et l’analyse de la cause racine a confirmé une absence dans la matrice de tests
• Des utilisateurs de Rocky Linux ont également indiqué qu’après la mise à niveau vers RockyLinux 9.4, les serveurs utilisant CrowdStrike plantaient à cause d’un bug du noyau, et le support de CrowdStrike a reconnu le problème
• Les organisations qui dépendent de CrowdStrike doivent traiter l’application des mises à jour avec davantage de prudence et disposer d’un plan d’urgence en cas d’incident

---

Des interruptions sous Linux avant la panne Windows

• Le vaste problème de Blue Screen of Death sur des PC Windows a perturbé les opérations de nombreux secteurs, notamment les compagnies aériennes, les banques et les prestataires de santé
  • La cause était un fichier de canal (channel file) problématique transmis par CrowdStrike via une mise à jour
  • CrowdStrike a confirmé que ce plantage n’affectait pas les PC Mac ni Linux
• Cependant, des utilisateurs de Debian et Rocky Linux ont aussi subi d’importantes interruptions dues à des mises à jour de CrowdStrike, ce qui suscite des inquiétudes concernant les procédures de mise à jour et de test
  • Cela peut représenter un risque potentiel pour les clients qui dépendent quotidiennement des produits CrowdStrike

Problèmes confirmés sur Debian et Rocky Linux

• Plantage simultané de serveurs Debian

  • En avril, dans un civic tech lab, une mise à jour de CrowdStrike a fait planter simultanément tous les serveurs Debian Linux et les a empêchés de démarrer
  • Cette mise à jour n’était pas compatible avec la dernière version stable de Debian, même si cette configuration Linux était considérée comme prise en charge
  • L’équipe IT a constaté que les machines démarraient après suppression de CrowdStrike, puis a signalé l’incident

• Réponse tardive et tests manquants

  • Un membre de l’équipe impliquée dans l’incident a exprimé son mécontentement face à la lenteur de la réponse de CrowdStrike
  • CrowdStrike a reconnu le problème un jour plus tard, mais il a fallu plusieurs semaines pour obtenir une analyse de la cause racine
  • L’analyse a montré que la configuration Debian Linux n’était pas incluse dans la matrice de tests de CrowdStrike
  • Le membre de l’équipe a critiqué l’approche en déclarant : « Le modèle de Crowdstrike semble consister à pousser du logiciel sur vos machines quand nous le voulons, que ce soit urgent ou non, testé ou non. »

• Plantages après la mise à niveau vers Rocky Linux 9.4

  • Des utilisateurs de Rocky Linux ont indiqué qu’après la mise à niveau vers RockyLinux 9.4, les serveurs utilisant CrowdStrike plantaient à cause d’un bug du noyau
  • Le support de CrowdStrike a reconnu ce problème
  • La répétition de problèmes de compatibilité sur différents systèmes d’exploitation révèle un schéma de tests insuffisants et de manque de prudence

Ce que les organisations doivent prévoir

• Pour réduire les problèmes similaires à l’avenir, CrowdStrike doit donner la priorité à des tests plus rigoureux pour toutes les configurations prises en charge
• Les organisations doivent appliquer les mises à jour de CrowdStrike avec prudence et préparer un plan d’urgence pour atténuer les interruptions potentielles
• Sources associées
  • Ycombinator
  • RockyLinux

[click]

On dirait que l’IA a résumé la publicité au lieu du corps de l’article.

[xguru]

Le site Neowin a une structure HTML étrange, si bien que toutes les publicités de la barre supérieure sont reconnues comme faisant partie du corps de l’article. J’ai corrigé cela.

[GN⁺]

Avis de Hacker News

• Il est étonnant de voir que l’écosystème OSS/Linux, bien qu’il soit souvent constitué d’amas de code assemblés gratuitement par des groupes indépendants et vaguement coordonnés, est souvent plus robuste que des logiciels produits par des entreprises valant des milliards de dollars.
  L’une des raisons pourrait être que les programmeurs système OSS lavent leur linge sale en public. C’est moins « avec suffisamment d’yeux, tous les bugs deviennent superficiels » que « le mauvais code devient honteux dès que quelqu’un risque de le voir ».
  Je m’apprête à publier en open source un projet commercial, et avant de rendre le code source public, il faut pas mal de nettoyage : améliorer la documentation, trier les TODO/FIXME, vérifier les commentaires, etc. Mais dans des codebases commerciales fermées, j’ai vu des choses bien pires, et j’imagine que la plupart des logiciels d’entreprise sont à peu près du même niveau.

  • Les logiciels OSS ont très peu de motivation par le profit : ils sont écrits pour « fonctionner », plutôt que pour « vendre » quelque chose.
    La pression du temps est aussi moindre : si une release prend du retard, cela n’affecte pas les résultats trimestriels. Je vois le logiciel commercial moins comme un travail d’ingénierie que comme un travail marketing.
  • Linus ne serait probablement pas d’accord, et il y a une raison pour laquelle le noyau maintient toujours d’énormes barrières. Il rejetterait, à juste titre, la majeure partie du code en espace utilisateur.
    Le simple fait que ce qui est hors du noyau fonctionne tient du miracle ; cela se voit à la fréquence à laquelle tout casse à chaque mise à jour de distribution, et à celle à laquelle il faut tout reconstruire pour que ça remarche. En production, les mises à jour sont une procédure extrêmement stressante.
    Je n’ai même pas encore parlé de l’audio et de la vidéo, et si l’on ajoute Wayland par-dessus, c’est un cauchemar à part entière. C’est pourquoi, à bien des égards, Windows me paraît proche d’un standard : il est malmené dans tous les sens, mais accomplit chaque jour des tâches critiques sur d’innombrables machines.
    Le fait d’être rémunéré ou non n’est pas ce qui compte ; la profondeur de décision que l’on voit dans les textes de Raymond Chen et d’autres est très rare même dans le monde OSS.
  • Les choses faites contre rémunération, mais où les MBA prennent les décisions finales, sont souvent médiocres par rapport aux projets de hobby ou de passion.
    Je ne pense pas être le seul à le constater, et j’espère qu’il continuera d’exister des communautés qui créent des choses utiles et des outils qu’elles peuvent contrôler.
  • Les délais sont probablement aussi un facteur important. Beaucoup de développeurs OSS créent des projets sur leur temps libre, pour eux-mêmes et pour les autres ; quand c’est un projet de passion, on peut être plus fier de son travail.
    Le logiciel commercial donne souvent l’impression d’être assemblé au ruban adhésif pour respecter l’échéance d’un manager, ce qui mène à un « peu importe » général et à la satisfaction d’avoir simplement terminé.
  • Je ne pense pas que qualifier les gens qui écrivent le code d’amateurs soit une bonne description. La plupart sont probablement des personnes expérimentées et très techniques, et le fait d’être « vaguement coordonné » s’applique aussi à beaucoup d’entreprises.
    Ce qui compte, dans l’open source, c’est que les gens qui codent le font souvent par intérêt. Si l’on veut rendre quelque chose bon, fonctionnel et ingénieux, on a plus de chances de réussir que si l’on le fait simplement parce qu’on est payé ou pour éviter d’avoir honte.

• Commentaire connexe dans le gros fil CrowdStrike d’hier : « CrowdStrike nous a fait ça le 19 avril sur notre parc Linux de production, et depuis j’avais envie de pousser ce coup de gueule » [1]
  S’ensuit un coup de gueule de plusieurs paragraphes.
  [1] https://news.ycombinator.com/item?id=41005936

  • Dans l’analyse des causes racines publiée quelques semaines plus tard, le scénario que nous utilisions n’était toujours pas dans leur matrice de tests. Et ce alors même que cela semblait être une configuration prise en charge, exécutant la version n-1 sur Debian stable.
    Leur propre post-mortem ne contenait pas non plus de méthode réellement capable d’empêcher que la même chose se reproduise. Parce que l’architecture était : « nous poussons des logiciels sur vos machines quand nous le voulons, sans test, que ce soit urgent ou non ».
  • Ce n’est pas seulement un commentaire connexe : on dirait que ce fil HN a été utilisé comme source principale de l’article.

• Quand je travaillais dans ce domaine, je me demandais toujours : « est-ce que ces trucs sont vraiment utiles ? »
  C’est une question difficile, mais je me demande s’il existe des études tierces qui valident l’efficacité de produits comme CrowdStrike. Ou bien si tout le monde ne se rend pas simplement la vie plus difficile au nom du théâtre sécuritaire.

  • C’est un peu comme essayer d’étudier l’efficacité des antivirus. Mais en fait, vous avez déjà donné la réponse : du moment qu’on peut produire des indicateurs que la direction peut digérer, c’est considéré comme ayant de la valeur.
    Je me demande comment on peut justifier d’ajouter quelque chose d’aussi intrusif. Dans les années 90, les éditeurs d’antivirus créaient parfois des virus, diffusaient leurs propres créations sur les réseaux, puis empêchaient magiquement leurs abonnés d’être infectés.
  • Je me demande si quelqu’un les a déjà vus bloquer réellement quelque chose. L’entreprise qui fabrique cet outil devait évidemment utiliser son propre produit.
    Si l’on demande à tout le Web mondial « quelqu’un en a-t-il été témoin ? », quelqu’un finira bien par se manifester ; mais les personnes qui ont subi des failles de sécurité à cause de ces outils sont extrêmement nombreuses, et celles qui ont connu des problèmes de stabilité et de disponibilité sont pratiquement aussi nombreuses que les utilisateurs de ces outils.

• La qualité des produits est en chute libre, de l’aéronautique au logiciel. Ces temps-ci, tout le monde ne se soucie que des revenus additionnels, si bien que le manque de QA est devenu la norme

  • Notre économie a été min-maxée pour optimiser les profits, et on dirait qu’on entre maintenant dans la phase de récolte
    C’est aussi pour cela qu’on n’arrive pas à produire assez d’obus pour l’Ukraine, à rapatrier la fabrication de puces, ni à construire des navires
  • Le fait que des personnes non techniques prennent les décisions, et aillent même jusqu’à développer des programmes techniques, est aussi une cause
    Il y a 15 ans, la plupart des gens du secteur voulaient vraiment y être, à quelques exceptions près. Désormais, c’est devenu un métier comme un autre : la majorité des développeurs ne s’intéressent guère à ce qu’ils produisent, et le résultat finit par être catastrophique
    Ces dernières années, je n’ai presque jamais rencontré de développeur sous le niveau senior qui teste réellement son propre code pourri
  • Le coût économique d’une erreur est inférieur aux bénéfices engrangés. Tant que cela ne changera pas, rien ne changera
  • Ce n’est pas seulement un problème de qualité produit
    C’est une structure où des influenceurs qui sentent le marketing, sans savoir ce qu’ils font, vendent de la camelote à des gens qui essaient de couvrir par des cases de conformité une paranoïa induite par les fournisseurs. Ils ne connaissent ni la modélisation des menaces, ni le fonctionnement d’un système d’exploitation
    Vu sous l’angle de la triade CIA, ils ont complètement abandonné la disponibilité, ont sacrifié une partie de la confidentialité en envoyant chaque mouvement du système à une entreprise de cloud, et cherchent à obtenir un faux sentiment de sécurité autour d’une intégrité que le fournisseur ne garantit même pas. Je n’ai vu presque aucune preuve que ce produit fasse réellement quoi que ce soit dans une architecture de sécurité correctement stratifiée
    C’est l’exact opposé d’une proposition de sécurité. Un château de cartes bâti sur le mensonge et l’incompétence, et littéralement proche de la définition d’un malware. Il exfiltre des données incontrôlables, peut faire tomber des systèmes via des fonctions de commande et contrôle à distance, et exécute du code entièrement arbitraire en ring 0
    En mars 2023, j’avais qualifié tout cela de risque métier majeur, mais les personnes ci-dessus l’ont imposé. J’ai enregistré les objections, et je compte maintenant m’en servir pour leur rendre la monnaie de leur pièce
    Si les gens l’achètent, peu importe que ce soit fait comme de la merde. Sauf que c’est effectivement fait comme de la merde
  • C’est triste. Cela varie selon les entreprises, et personnellement c’est l’un des aspects que je préfère dans l’ingénierie logicielle, mais beaucoup de grandes entreprises suppriment la QA dès qu’elles en ont l’occasion

• Il y a aussi eu des signalements selon lesquels CrowdStrike injectait une DLL boguée dans des applications Windows, ce qui pouvait les faire planter même si l’application elle-même n’avait rien fait de mal
  https://x.com/molecularmusing/status/1808756095860543916

  • C’est une tout autre affaire. La DLL injectée est une fonctionnalité optionnelle désactivée par défaut, et les administrateurs sont explicitement avertis qu’ils doivent vérifier sa compatibilité avec leur parc avant déploiement
    Il existe quatre niveaux de hooks applicables, de plus en plus instables, avec des avertissements répétés dans l’interface et la documentation. Par exemple, XUMD permet au capteur de surveiller des informations en chargeant une bibliothèque dans les processus en cours d’exécution et en hookant plusieurs API en mode utilisateur
    Une partie de la télémétrie endpoint ne peut être collectée qu’au moyen de hooks en mode utilisateur. XUMD fournit des informations sur les API utilisées par un processus, et ces informations servent à plusieurs mécanismes de prévention du capteur, sur la base des comportements cumulés observés
    Contrairement à AUMD, le cloud peut modifier dynamiquement la visibilité XUMD sans mise à jour du capteur. Les réglages sont Disabled, Cautious, Moderate, Aggressive et Extra Aggressive ; plus on avance, plus les risques de problèmes de performance ou de compatibilité applicative augmentent, et ils ne sont pas recommandés en production
    Comme XUMD est chargé dans des processus utilisateur avec lesquels il n’a pas été développé à l’origine, cela peut provoquer des plantages, des échecs au démarrage ou des baisses de performance, en particulier dans les environnements où d’autres produits de sécurité sont installés. Pour voir quels processus ont chargé la DLL XUMD, on peut exécuter tasklist /m csxumd* en ligne de commande

• Tout cela arrive parce que les entreprises peuvent se soustraire par contrat à la responsabilité pour dommages indirects
  De même qu’on ne peut pas exclure contractuellement la responsabilité indirecte en cas de perte de vies humaines, il faudrait rendre ces clauses inapplicables, ou au moins les limiter

  • N’est-ce pas ce que la directive sur la cybersécurité européenne cherchait à faire ? Celle qui avait mis tout le monde en colère, jusqu’à ce qu’une exception pour le FOSS soit ajoutée

• Les passages “la mise à jour n’était pas compatible avec la dernière version stable de Debian, alors que cette configuration Linux était indiquée comme prise en charge” et “l’analyse a montré que la configuration Debian Linux ne figurait pas dans la matrice de tests” semblent assez proches d’une véritable fraude
  C’est déclarer que la configuration X est prise en charge, tout en ne testant en réalité jamais la configuration X. C’est comme dire qu’une voiture a une ceinture de sécurité sans jamais vérifier, à aucun moment du processus de fabrication, que cette ceinture est installée et fonctionne
  Si un constructeur automobile faisait cela, j’ai l’impression qu’il serait poursuivi. Je ne vois pas pourquoi CrowdStrike ne le serait pas. Je peux comprendre qu’on ne prenne pas en charge certaines versions de Linux, mais si l’on annonce qu’elles sont prises en charge sans même les tester, c’est au minimum une négligence volontaire, voire une fraude flagrante

• Dire que “personne ne l’a remarqué” ressemble à une jolie façon de dire que CrowdStrike a fait en sorte que la presse ne le remarque pas. Le jour du bug, il y avait sur HN des commentaires de gens disant qu’ils essayaient de signaler le problème depuis des mois
  Même l’article est rédigé comme si des gens avaient bien remarqué le problème. Alors, qui ne l’a pas remarqué ? Ou bien ces problèmes n’étaient-ils simplement pas assez connus pour ne pas être ignorés ?

  • Tu penses que CrowdStrike a étouffé la couverture médiatique ? Je suis curieux de savoir si tu imagines qu’ils ont envoyé des chèques au NY Times, au WaPo et aux grandes chaînes de télévision
    Les médias ne s’intéressent pas à quelques serveurs qui tombent, à moins que cela ne se voie dans le monde réel, comme avec l’arrêt d’opérations aériennes
  • Je me souviens avoir vu quelque chose à l’époque, mais je pensais que très peu de gens installeraient ce genre de logiciel sur Linux. Et en pratique, très peu d’entreprises le font
    Le rayon d’explosion était faible, probablement même plus faible que celui d’un mauvais pilote Nvidia

• S’il y a ici des personnes qui utilisent CrowdStrike, je suis curieux de savoir ce que ça fait exactement. Je vois que c’est qualifié d’« antivirus », mais quand je le vois installé sur un ordinateur portable professionnel, ça ressemble à un keylogger et un moniteur d’activité
  On peut dire qu’on « n’a rien à cacher », mais ça reste dérangeant que les super-utilisateurs de l’entreprise puissent me surveiller

  • Ça permet d’obtenir le coup de tampon des équipes sécurité, conformité et juridique
  • Il existe une meilleure solution que de qualifier les solutions antivirus/EDR de malware ou de spyware : ne pas utiliser son appareil professionnel pour des activités personnelles.
    Cet appareil appartient à l’entreprise et sert à accéder à son environnement ; c’est donc un point de responsabilité susceptible de causer des dommages si un vrai malware s’y introduit. Si l’on a besoin de vie privée, mieux vaut utiliser un appareil distinct

• Dans certaines entreprises, CrowdStrike serait déployé sur tous les endpoints, mais quelqu’un dit avoir pu le faire tourner uniquement dans une machine virtuelle aux ressources limitées sans que personne ne dise rien. Il dit aussi avoir vu des machines virtuelles tomber en panne vers cette période.
  Un ancien collègue dans une autre grande entreprise m’a également raconté que l’IT avait tout simplement renoncé à faire appliquer la conformité sur les endpoints Linux. Certains administrateurs IT semblent appliquer de fait une politique de type « ne rien demander, ne rien dire ».
  En gros, si vous assemblez vous-même une stack de remplacement, que vous ne faites pas de vagues et que vous ne mentez pas, ils vous laissent faire. Si la motivation de l’application est surtout une conformité à cases à cocher, c’est assez logique.
  Je me demande à quel point cette forme de conformité malveillante est répandue, et dans quelle mesure elle a contribué à ce que l’incident d’avril ne fasse pas davantage la une.