Fiasco CrowdStrike : Microsoft persiste et signe, tout est la faute de l’Europe
Os à ronger
Même si Microsoft n’est pas directement responsable du fiasco CrowdStrike, l’éditeur est copieusement pointé du doigt. Le fait que Windows ait pu planter à cause d’un bug dans un logiciel tiers n’est-il pas la preuve flagrante que sa fiabilité et sa sécurité devraient être améliorées ? Face à la pression croissante et les questions incessantes, Microsoft a désigné une coupable : l’Europe.
Le 23 juillet à 12h35
8 min
Sécurité
Sécurité
La panne CrowdStrike n’en finit plus de créer des ondes de choc dans le monde informatique, les innombrables structures touchées, les clients et la classe politique. Rappelons qu’une mise à jour déployée dans l’outil de sécurité Falcon Sensor de CrowdStrike a provoqué des écrans bleus sur des millions de PC équipés de Windows. Nous nous sommes largement penchés sur les aspects techniques de cette affaire.
La panne, nous l’avons vu, vient d’un logiciel tiers. Dans un précédent article, nous avons d’ailleurs rappelé le fonctionnement des niveaux de privilèges dans Windows, ainsi que des espaces noyau et utilisateur. Mais la question demeure, entêtante : comment une simple mise à jour d’un produit tiers peut entrainer un plantage du noyau Windows, entrainant le reste du système avec lui ?
Une faiblesse inhérente à Windows ?
On lit régulièrement que la panne est l’illustration flagrante d’une faiblesse de Windows. Ainsi, le système ne devrait pas être conçu de manière à laisser une application tierce créer un tel bazar. N’est-ce pas la preuve qu’il est temps que Microsoft revoie l’organisation de son architecture et des API proposées aux développeurs tiers ?
« Ce que vous voyez ici, ce sont des défaillances systémiques de la part de Microsoft, qui mettent en danger non seulement leurs clients, mais aussi le gouvernement américain ». Tels étaient les propos de George Kutz, CEO de CrowdStrike, sur CNBC en janvier. Microsoft venait alors de confirmer que certains systèmes utilisés par des cadres de l’entreprise avaient été piratés par un groupe russe.
L’ironie de la situation est palpable, mais Microsoft a quand même un problème sur les bras. Que ce soit à travers une presse mal informée ou une récupération politique, l’entreprise est largement pointée du doigt. En France et en Europe, c’est pour certains la preuve que la souveraineté numérique doit être une priorité. Et ce, alors que l’origine d’un logiciel ne peut en garantir l’excellence technique.
Une situation complexe. Mais alors que la question doit se poser en interne chez Microsoft, la firme est soumise à une grande pression. On la somme de s’expliquer. Dans un développement surprenant, elle accuse l’Europe.
Sans l’Europe, Windows serait plus verrouillé
Face à cette pression, un porte-parole de Microsoft s’est expliqué auprès du Wall Street Journal. Selon nos confrères, « la société ne pouvait pas légalement cloisonner son système d'exploitation comme le fait Apple, en raison d'un accord conclu avec la Commission européenne à la suite d'une plainte ». Une posture pour le moins surprenante (nous allons y revenir), mais que nous a confirmée le service presse de Microsoft France.
En 2009 en effet, « Microsoft a accepté de donner aux fabricants de logiciels de sécurité le même niveau d'accès à Windows que celui dont bénéficie Microsoft », ajoute le Journal. L’accord en question est toujours disponible sur le site de Microsoft. Dans son communiqué du 16 décembre 2009, on peut y lire l’enthousiasme de l’entreprise :
« Nous nous réjouissons de la décision prise aujourd'hui par la Commission européenne, qui approuve la résolution finale de plusieurs problèmes de longue date en matière de droit de la concurrence en Europe. Nous sommes impatients de poursuivre le dialogue et la confiance qui ont été établis entre Microsoft et la Commission et d'étendre notre leadership industriel en matière d'interopérabilité ».
Il s’agissait à l’époque d’intervenir sur deux points majeurs. D’une part, l’arrivée d’un écran de sélection du navigateur dans Windows, pour mettre fin à la suprématie d’Internet Explorer. D’autre part, un engagement public de Microsoft couvrant l’interopérabilité des produits Microsoft avec les logiciels tiers. Les mesures prévues sont toujours listées dans un document dédié.
Ce document est important, car Microsoft s’engage à proposer aux développeurs tiers les mêmes API que celles utilisées par ses propres produits de sécurité. La Commission européenne avait demandé ce changement, car plusieurs éditeurs de solutions de sécurité avaient accusé Microsoft d’avantage injuste, en profitant de capacités qu’elle seule pouvait utiliser.
Il s’agirait du cœur du problème : l’accord avec l’Europe stipule que les logiciels tiers doivent avoir les mêmes capacités que les logiciels de Microsoft, notamment dans le domaine de la sécurité. Ce qui, à l’époque, avait été applaudi comme une règle de bon sens. Le ton même du communiqué de Microsoft était joyeux.
Pourquoi un tel revirement ?
Nous avons demandé à Microsoft les raisons de ce revirement, ainsi que des détails sur cet avis tranché. À l’heure où nous écrivons ces lignes, l’entreprise n’a pas répondu à nos sollicitations. La question reste donc entière : pourquoi accuser l’Europe d’un tel fiasco ?
La Commission européenne est bien à l’origine de la demande. Les modifications ont été décidées après de longues concertations entre les parties. Microsoft, à l’époque, évoquait même « un jour important et un grand pas en avant ». Pour ne pas être ensevelie sous une trop grande complexité, l’entreprise avait d’ailleurs répercuté ce changement dans tous les marchés. CrowdStrike, entreprise, américaine, en a donc profité.
L’attaque contre l’Europe semble donc bien malavisée. L’exigence de la Commission n’était pas en effet de donner aux éditeurs tiers un accès à l’espace noyau, mais de leur offrir les mêmes capacités que ses propres produits. Si ces derniers pouvaient passer par un pilote en espace noyau – comme Falcon Sensor de CrowdStrike et l’immense majorité des solutions de sécurité aujourd’hui sur Windows – alors les autres éditeurs devaient pouvoir en faire autant.
Y avait-il une autre solution ?
La déclaration de Microsoft au Wall Street Journal laisse à penser que sans cette décision de l’Europe, Windows serait aujourd’hui plus verrouillé. L’éditeur en aurait-il profité pour cloisonner définitivement l’espace noyau, y compris pour ses produits ? On peut en douter, car l'éditeur estimait alors être dans son bon droit en voulant sécuriser son propre système. Il se retrouvait, de fait, en concurrence directe avec toutes les sociétés de sécurité.
Cette déclaration ressemble davantage à un os négligemment jeté à la presse, mais l’argument est faible. Rien n’empêchait en effet depuis 15 ans de mettre en place une autre architecture et de revoir la manière dont les solutions de sécurité travaillaient sur Windows. Comme nous l’avons indiqué, ces dernières ont actuellement un grand pouvoir, car elles doivent avoir les privilèges nécessaires pour surveiller tout ce qui se passe sur la machine.
C’est précisément la voie empruntée par Apple en 2020 avec macOS Big Sur. La firme avait mis les kexts à la retraite. Les kexts, pour « kernel extensions », pouvaient être utilisés par les éditeurs tiers pour déposer des éléments en espace noyau. Apple a fermé cette porte, forçant les éditeurs tiers à s’adapter. En novembre 2020 d’ailleurs, CrowdStrike avait annoncé sa compatibilité avec Big Sur en grande pompe, précisant que la nouvelle mouture de Falcon gardait toutes ses capacités, sans impact sur les performances.
La version Mac de Falcon est, à ce jour, la seule version du logiciel à fonctionner en espace utilisateur. Sur Windows et Linux, le pilote en espace noyau est toujours présent. Sur Linux, CrowdStrike aussi avait provoqué différents problèmes, dont… des kernel panics, l’équivalent Linux de l’écran bleu. Les origines des pannes étaient autres, mais le résultat était le même, avec une interrogation identique sur les privilèges de ce type de logiciel. Au cours des derniers mois, on a ainsi pu voir des blocages complets se produire sur Debian et RockyLinux, et confirmés par RedHat.
Nous mettrons cette actualité à jour si Microsoft nous répond.
Fiasco CrowdStrike : Microsoft persiste et signe, tout est la faute de l’Europe
-
Une faiblesse inhérente à Windows ?
-
Sans l’Europe, Windows serait plus verrouillé
-
Pourquoi un tel revirement ?
-
Y avait-il une autre solution ?
Commentaires (59)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousModifié le 23/07/2024 à 12h53
« Linux would have prevented this!" literally true because my former colleague KP Singh wrote a kernel security module that lets EDR implementations load ebpf into the kernel to monitor and act on security hooks and Crowdstrike now uses that rather than requiring its own kernel module that would otherwise absolutely have allowed this to happen, so everyone please say thank you to him »
Cela ne contredit bien sûr pas la possibilité de kernel panics, mais cela devrait limiter le domaine des possibles…
Le 23/07/2024 à 13h54
Et dans les commentaires, j'ai trouvé celui-ci très instructif :
Bref, cela aurait très bien pu arriver sous Linux.
Le 23/07/2024 à 14h18
Bref, le module eBPF de CrowdStrike aurait révélé un bug dans le backport d’eBPF, rapidement corrigé par RedHat.
Le 24/07/2024 à 16h40
Le 25/07/2024 à 07h12
Donc le bug était côté linux/redhat.
Pour moi ça ne remet pas en cause la meilleure pertinence de l'approche ebpf/sandboxée, a l'opposé de ce que fait windows aujourd'hui. Évidemment il faut que le socle (côté linux/kernel) soit en béton armé, mais ça sécurise énormément les choses en cas de souci côté éditeur tiers.
(D'ailleurs ebpf pour windows existe, peut-être qu'il manque de maturité mais ça peut être la solution à l'avenir)
Modifié le 23/07/2024 à 13h46
Coïncidence, hier j'ai essayé de jouer à Once Human et deux fois de suite crash/reboot du pc à cause d'un plantage du drivers graphique, cause différentes même résultat
Le 23/07/2024 à 14h15
Le 23/07/2024 à 14h20
Concernant ton plantage graphique si t'es avec un cpu intel serie 13 ou 14 c'est potentiellement ton CPU qui commence à déconner.
YouTube
Et Windows est capable de se récupérer suite au plantage d'un driver graphique depuis quelques années car il n'est plus en mode noyau justement. Si t'as un crash/reboot c'est assez probablement hardware donc soit physiquement le gpu qui a crash (car t'as OC ou t'es trop chaud) soit le CPU (idem OC ou trop chaud) ou le nouveau problème des séries 13 et 14 qui est en train de prendre de l'ampleur depuis quelques mois.
Le 23/07/2024 à 19h46
Mais la suite "inventée" du dictons ci-dessus est: "... mais pour une véritable catastrophe, il faut un ordinateur". Il faut toujours trouver le juste milieu entre diffuser une correction au plus vite ou bien la tester correctement pour éviter les effets de bord.
La solution Crowdstrike semblait parfaite et sérieuse, et les responsables info poussés par la réputation du produit, une [trop ?] grande confiance et les pressions pour assurer la plus grande protection du parc ont pris un [gros] risque. Et le 19 juillet 2024, ben, ils ont perdu par la faute d'un fournisseur qui n'a pas été à la hauteur.
J'espère que cette expérience va permettre en retour d'améliorer la diffusion par lot de Falcon Sensor selon les décisions des clients.
Le 24/07/2024 à 16h41
Le 23/07/2024 à 14h05
Le 23/07/2024 à 14h29
Le 23/07/2024 à 14h30
Maintenant, c'est clair que Windows est très en retard sur le noyau Linux et son eBPF, mais ultimement, si les clients ne sont pas capables de réfléchir aux risques qu'ils prennent...
Le 24/07/2024 à 16h42
Modifié le 24/07/2024 à 18h32
Pourtant il y a des signaux qui devraient inciter à la prudence dans ce genre de cas (crowdstrike est en défaut sur un certain nombre de points ci-dessous):
- le produit tourne t'il dans le noyau et/ou avec les niveaux de privilège les plus élevés?
- le produit remplace ou désactive t'il un composant de sécurité standard?
- le produit utilise t'il un protocole de commande avec un processus serveur écoutant sur le réseau? Si oui, utilise t'il les mêmes privilèges que les processus d'opérations? (dédicace IBM)
- le code source est-il disponible à la consultation? Y a t'il des audits indépendants ? Les rapports sont-ils publics?
- la documentation est-elle publique?
- la communauté d'utilisateurs est-elle accessibles au public? Ou est-elle cantonnée au périmètre du support du produit?
Le 25/07/2024 à 09h07
Oui, le produit tourne en ring 0 donc au niveau du kernel
- le produit remplace ou désactive t'il un composant de sécurité standard?
Non, il ne remplace pas la bouse à Windows, c'est plus un outil type "forensics", c'est de l'analyse en temps réels de patterns, en gros ça intercepte tout et nawak et ça le compare avec les comportements "statistiquements normaux" pour détecter les comportements anormaux.
- le produit utilise t'il un protocole de commande avec un processus serveur écoutant sur le réseau? Si oui, utilise t'il les mêmes privilèges que les processus d'opérations? (dédicace IBM)
Pas à ma connaissance mais je ne suis pas expert. Le produit est "découpé" en deux, tu as le Falcon Senror qui fait l'interception et l'écriture de logs et tu as ce qu'ils appellent FFC qui fait la collecte le traîtement et l'envoi si j'ai tout suivi. Par contre les updates des modèles sont poussées par CrowdStike directement sur le sensor
- le code source est-il disponible à la consultation? Y a t'il des audits indépendants ? Les rapports sont-ils publics?
Bah non c'est une société privée :p C'est pas un produit opensource (de loin) et d'ailleurs c'est mieux comme ça vu que ça pourrait potentiellement donner les clés à des petits malins pour bypasser ou même utiliser le sensor à des fins litigieuses.
- la documentation est-elle publique?
Du code? Certainement pas :p
- la communauté d'utilisateurs est-elle accessibles au public? Ou est-elle cantonnée au périmètre du support du produit?
Voir au dessus - société privée, ils ne vont pas distribuer la liste de leurs clients vu que ça donnerait une info potentiellement utile à des hackers, donc non, c'est beaucoup trop sensible pour que ce soit public.
Le 25/07/2024 à 10h58
Je me permet d'être en désaccord avec ta remarque sur le code source, non ce n'est pas mieux d'avoir le code non audité et sans audit public.
De même, la documentation (je ne parlais pas du code) du produit n'est pas publique et la communauté utilisateur est sous cloche.
Dans l'ensemble c'est juste un nième produit de sécurité développé à la sauvage et qui garde tous ses cadavres sous le tapis. Il faut bien constater que les pratiques des années 90-2000 sont encore très vivaces, par contre les échelles des dégâts sont bien de 2024.
En fait, c'est formidable de voir que dans un domaine où l'adversaire démontre chaque jour des méthodes plus intelligentes et sophistiquées, les entreprises se cramponnent à des approches conservatrice reposant sur une confiance aveugle et ininformée à des entreprises pratiquant le charlatanisme.
On est pas supposés se soigner avec des molécules mystérieuses qui n'auraient pas été documentées et approuvées par des chercheurs et des autorités médicales, mais en informatique tout le monde fait ça tout le temps.
Le 25/07/2024 à 11h15
Un virus (biologique) n'a, à ma connaissance, pas de conscience lui permettant d'agir et d'anticiper en fonction de la molécule qui lui est foutu devant lui.
Ainsi, et malheureusement, c'est un peu le jeu du chat de la souris. Et qu'on le veuille ou non, la fermeture maximale des solutions n'a pas qu'une explication mercantile (ce qui n'enlève pas pour autant cet argument, juste que ce n'est pas le seul) mais aussi une explication d'efficience. C'est triste, mais c'est ainsi.
Le 25/07/2024 à 11h31
ce point a déjà fait l'objet de tant de littérature pour faire simple:
- le code source n'est pas nécessaire pour un attaquant motivé. La grande majorité des vulnérabilités exploitées concernent du logiciel dont le code source n'est pas public.
- le code visible publiquement n'est pas une garantie que l'on identifiera les vulnérabilités mais ça aide
- le code visible publiquement motive par contre les auteurs à en soigner la qualité, question d'image de l'entreprise.
Concernant le virus biologique, il mute continuellement et participe à un jeu de chat et de souris heuristique qui se déroule sur des dizaines de milliers d'années. Le terme technique pour ça est "évolution". Les bactéries suivent le même principe mais s'adaptent encore plus vite, c'est pour cela que l'introduction de contremesures radicales comme les antibiotiques se conclue presque irrémédiablement par l'émergence de bactéries résistantes.
Le 25/07/2024 à 12h01
Sauf que là, on ne parle pas de trouver une faille en tant que telle, mais de comprendre un mécanisme de détection pour éviter de le déclencher. C'est une complexité tout autre.
Pour le virus biologique, il n'y a aucune "reflexion" de sa part. Il mute (comme tout virus) plus ou moins régulièrement. Si une mutation lui donne un avantage (résistance à un médicament par exemple) et qu'il se trouve en présence d'un contexte dont il peut tirer avantage par rapport aux autres (présence dudit médicament) alors effectivement, il va proliférer, car la concurrence sera éliminée alors que lui non. C'est le principe d'évolution et notamment de la sélection naturelle évoquée par Darwin.
Du coup, le virus ne s'adapte pas en tant que tel (il n'y a aucune volonté). C'est le principe de sélection naturelle. Le hasard.
Si on en revient à son équivalent numérique, un virus détecté par une solution de sécurité, on va avoir plusieurs cas :
- le virus "mute" (nouvelle version) : peut être qu'il passera sous les radars, peut être pas. C'est au petit bonheur la chance
- le virus "mute", mais son créateur connait les mécanismes de défense mis en place par les solutions antivirus et assimilées : il peut "orienter" les mutations pour l'aider à passer outre. C'est beaucoup plus efficace que juste le petit bonheur la chance.
Le 25/07/2024 à 12h57
Eeeeeuuuuuh ... non, pas vraiment. Pas besoin du code source pour ça, il suffit de tester l'application "live" et de soumettre les systèmes à différents types d'attaque pour savoir où attaquer. On a déjà vu des attaques contre des antivirus où le virus en fait était conçu pour provoquer un dépassement de pile dans le moteur de scan de l'antivirus lui-même.
Les bons hackers appliquent la méthode scientifique pour attaquer et s'adaptent à leurs cibles, et les attaques sont d'autant plus facile si la cible développe un sentiment non-justifiée de sécurité en pensant que l'obscurité va constituer un frein majeur pour l'attaquant, quitte à se bander les yeux pour renforcer ce sentiment.
Pour le virus biologique j'ai parlé d'heuristique car le mécanisme de mutation aléatoire est bien conditionné par un système de succès /échec et que ces succès et échecs conditionnent des tendances d'accentuation de traits dans les générations successives. L'évolution peut être rationalisée en un système d'attaques par force brute aléatoires, arbitraires et parallélisées.
Le 25/07/2024 à 14h53
Je n'ai jamais dit que le code source était nécessaire. Je dis que l'accès au code source facilite la tâche par rapport à une décompilation ou une analyse de comportement.
"Les bons hackers appliquent la méthode scientifique pour attaquer et s'adaptent à leurs cibles, et les attaques sont d'autant plus facile si la cible développe un sentiment non-justifiée de sécurité en pensant que l'obscurité va constituer un frein majeur pour l'attaquant, quitte à se bander les yeux pour renforcer ce sentiment."
La sécurité ne reposant QUE sur l'obscurité est une hérésie. Là dessus, tout le monde est d'accord. Maintenant, rajouter de l'obscurité complique les choses pour les hackers, aussi bon soient-ils.
Tu pars du principe pour justifier l'ouverture que si le code est ouvert, alors il sera de meilleur qualité. C'est une assertion qui reste à prouver.
"L'évolution peut être rationalisée en un système d'attaques par force brute aléatoires, arbitraires et parallélisées."
On est d'accord. Mais si on peut orienter les recherches pour que ce ne soit plus de l'arbitraire, on gagne en efficacité. Ce qu'un accès au code source permet plus facilement.
Le 25/07/2024 à 16h39
Pour le reste, du code consultable mais de mauvaise qualité entrainera plus vite des réactions, quand on joue l'a transparence, on a généralement pas envie de se faire allumer parce-qu’on a laissé du code mal ficelé ici et là parce qu’on était à la bourre. Du code consultable, ça engage systématiquement l'image de l'entreprise.
Le 25/07/2024 à 20h49
1) est-ce prouvé que cela augmente la qualité du logiciel ?
2) est-ce prouvé qu'il y aura réellement plus d'audit indépendant ?
3) si avantages il y a, est-ce qu'ils compensent le préjudice que les hackers peuvent trouver en l'examinant directement ?
Le 25/07/2024 à 22h53
2) absolument, de nombreuses entreprises et organismes gouvernementaux organisent des audits de ce genre.
3) le nombre de technologies opensource utilisées pour les infrastructures du web et du cloud est un bon indicateur des gains de l'ouverture. En plus, ces dernières années nous avons vu de nombreux leaks de code source applicatif, et quand un code un peut trop obscure est soudainement révélé sans travail préparatoire, ça peut faire très mal.
Le 26/07/2024 à 08h22
2) source ? Car beaucoup de solutions non open-source sont également audités
3) le nombre de technologies opensource utilisées pour les infrastructures du web et du cloud est un bon indicateur des gains de l'ouverture en terme de part de marché. Est-ce parce que les solutions sont de qualité ? Peut-être. C'est sans doute un des facteurs. Est-ce parce que les solutions sont généralement gratuites ? Très certainement (ne pas oublier que la sécurité est un parent pauvre dans les entreprises !). Est-ce parce que cela offre une indépendance vis-à-vis du bon vouloir tarifaire des éditeurs ? Aussi (cf. récemment Broadcom et vmware par exemple)
Le 23/07/2024 à 14h39
L'OS devrait être le seul à accéder au Kernel, et si Microsoft intègre sa propre solution de sécurité qui est la seule à y accéder, ben c'est plutôt normal.
Vouloir que des solutions tierces y accèdent pour éviter un monopole est stupide...
Après, c'est une réflexion qu'il aurait fallu avoir en 2009, mais la cyber, c'était pas le truc dont on se préoccupait beaucoup.
Il faut voir la finalité: est-ce qu'on veut un OS robuste, ou est-ce qu'on veut vendre des EDR / antivirus ?
Le 23/07/2024 à 15h10
Plutôt que de donner à des tiers des clés trop puissantes, et pas obligatoirement avec toutes les infos nécessaires pour agir à ce niveau.
Le 23/07/2024 à 15h25
Vu la criticité de la chose, il n'y a rien d'étonnant à ce que cela n'ait pas été fait, sans compter les coûts induits par ce type de réécriture.
Microsoft n'a pas rien fait non plus, puisqu'il a mis en place un système de qualité pour les drivers en espace noyau.
Je pense qu'à l'époque, personne n'avait songé qu'un pilote puisse se retrouver à faire planter la moitié de la planète en 78 minutes dès lors qu'il était installé. On critique beaucoup Microsoft, mais le problème numéro 1 n'en reste pas moins qu'un fichier de définition en espace utilisateur n'aurait jamais du être capable de faire planter un driver en espace noyau.
Le 23/07/2024 à 16h47
Vu la criticité de la chose, il n'y a rien d'étonnant à ce que cela n'ait pas été fait, sans compter les coûts induits par ce type de réécriture. "
C'est vrai que ce serait vraiment chaud pour une petite boîte comme Microsoft d'assurer une réécriture propre et robuste avec toute la conduite de changement que cela impliquerait auprès des constructeurs de matériel et les éditeurs logiciels concernés de près ou de loin.
Au bas mot, 5 milliards de dollars sur 3 ans...
C'est vrai que MS ne fait que 20 milliards de bénéfices nets par trimestre...
Le 23/07/2024 à 17h05
Et franchement, si ça devait couter 5 milliards de dollars sur 3 ans, je prendrais le risque d'amende. Ça couterait moins cher, surtout en faisant trainer les choses !
Modifié le 12/09/2024 à 00h15
Passé un certain dimensionnement, si, justement.
Microsoft aurait techniquement les moyens de réécrire complètement Windows from scratch en 5 ans ET financer TOUS LES CONSTRUCTEURS / ÉDITEURS sur une refonte des couches nécessaires pour que les logiciels soient à nouveau compilables / exécutables.
Ils ont juste pas la compétence, ni le sens des responsabilités pour développer correctement. Et comme ils continuent d'engranger les thunes avec des petites caresses sur les mains en guise de punition effectivement aucune raison qu'ils changent.
Le 23/07/2024 à 18h07
Notamment passer outre des limitations purement commercial.
J'ai pas beaucoup d'exemples sous la main, mais winbtrfs utilise des fichiers ".sys"
Le verrouiller par défaut et ne pas signer les modules commerciaux, pourquoi pas.
Le 24/07/2024 à 15h30
L'exemple de CroundStrike montre aussi que d'avoir plusieurs concurrents a du bon : ceux qui profitaient d'une autre protection n'ont pas été dérangés outre mesure.
Le 24/07/2024 à 23h06
Euh... comment dire... les applications qui tournent ont besoin d'accéder au kernel pour fonctionner. On ne fait pas un malloc sans passer à un moment par le kernel.
Par contre, le kernel devrait avoir un périmètre robuste et empêcher des modules supplémentaires de commencer à accéder à tout et n'importe quoi.
Ce que Microsoft aurait dû faire il y a longtemps, c'est de travailler sur des accès officiels, via des api et des bacs à sable pour les outils désireux de faire de l'analyse ou de la surcharge en profondeur. Sous Linux, il y a eBPF qui permet de donner un certain niveau d'accès à des applications de monitoring et de sécurité, c'est puissant et largement utilisé tant pour apporter des fonctionnalités avancées (par exemple service mesh), que de l'analyse de paquet, du monitoring , le profilage applicatif, ...
La question est de savoir pourquoi Microsoft est tellement à la ramasse sur ce genre de sujet et pourquoi Windows est-il si fondamentalement dans le passé. Pour rappel, eBPF, c'est sorti en 2014...
Le 25/07/2024 à 09h09
Le 25/07/2024 à 10h10
Dans le cas d'un driver graphique, c'est du temps de réaction qu'il s'agit : il faut éviter de repasser en user space pour faire une partie des traitements suite à un événement qui est reçu dans le noyau, donc on choisit de rester dans le noyau pour enchaîner les traitements, mais au prix d'un risque accru pour la stabilité de l'OS. Le passage en user space puis ensuite à nouveau en mode noyau pour attaquer le matériel ferait bien des pertes de performance.
Dans le cas d'un outil comme celui-ci, il faut qu'il tourne dans noyau pour récupérer des infos de l'OS non disponibles ailleurs. Par contre, ces infos sont ensuite traitées et remontées aux serveurs par du logiciel en user space. La perte de perf liée au passage noyau user space existe de toute façon. Il n'y aurait pas de perte de perf supplémentaire. Remarque : dans une architecture de type eBPF, la recherche des paterns à surveiller serait faite dans le noyau par du code Windows (donc sans que tout soit passé en user space avant filtrage) commun à toutes les applications l'utilisant.
Le 25/07/2024 à 10h34
Le 06/08/2024 à 15h04
Le 06/08/2024 à 15h33
Et puis 99.9% du temps, c'est basé sur quoi, d'où sort ce chiffre d'efficacité? D'une étude indépendante avec une base scientifique ? D'une étude marketing? Du rêve des décideurs des entreprises?
Quand j'ai commencé à travailler dans la sécurité informatique dans les années 90, je voyais surtout de l'empirisme, du shamanisme, de l'homéopathie, du n'importe quoi... on est maintenant plus de 25 ans après et je vois toujours des chiffres bidons, des croyances, de la superstition, et même face à une catastrophe surpassant n'importe quel ddos dans l'histoire en terme de paralysie des systèmes, on continue à traiter ça sans la moindre rigueur, toujours sur des vœux pieux et des chiffres non étayés pour fourguer des produits de charlatans.
Modifié le 23/07/2024 à 14h50
La question que je me pose est qu'au-delà de la stabilité (en fermant l'accès noyau). Est-ce que les logiciels de sécurité seraient tout aussi efficaces sans cet accès? Au même titre que Windows Defender?
Le 23/07/2024 à 15h46
C'est une solution "quick and dirty" qui est entièrement de leur ressort (ils auraient pu faire autrement, comme Linux l'a fait, par exemple) mais évidemment, ça demande du travail...
Le 23/07/2024 à 16h09
Le 23/07/2024 à 16h17
Et cela prouve la nécessité de mieux gérer ce genre d'outils pour éviter des pannes catastrophiques en chaîne.
Le 24/07/2024 à 16h44
Le 24/07/2024 à 17h11
Après, si cela avait été traité par les médias "classiques", on aurait eu droit à "une mise à jour Linux fait planter tous les systèmes" au lieu d'une mise à jour Windows (et encore, le terme Linux étant inconnu de bon nombre de nos concitoyens, je ne suis même pas sûr que Linux aurait été cité)..
Le 25/07/2024 à 09h00
Le 25/07/2024 à 09h35
Niveau serveur, Linux a une très belle part de marché, supérieure à celle de Windows (il suffit de voir Azure :)).
Effectivement, le côté applis web change un peu la donne, dans le sens où il n'y a plus de dépendance forte à Windows comme auparavant. Mais quand il faut gérer l'inertie (que ce soit des utilisateurs ou des techniciens), l'homogénéité d'un parc (plus facile de ne gérer que du Windows ou qu'une seule version d'une distribution linux que 36000 versions différentes).
Sans compter que quand ça marche, pourquoi changer (coucou les aéroports non affectés qui tournaient sur du Windows 3.1 !)
Et pour les appli .Net, tant qu'elles ne sont pas graphiques oui, elles peuvent se passer de Windows. Avec .NET Maui, on a de bons portages sur Linux possible, mais c'est une techno assez récente (d'un point de vue industriel j'entends) et le support Linux est communautaire et non pas officiel (et ça en freine certains).
PS : je suis aussi dev Windows
Le 25/07/2024 à 11h08
Le 23/07/2024 à 15h50
Le 23/07/2024 à 17h54
c'est pas bénéfique à crowdstrike, qui est déjà dans une merde noire, à un pouce du démantellement (qui doit avoir lieu par mérite)
crowdstrike n'a rien à gagner (et tout à perdre) à afficher "en clair" les détails techniques du bug.
Ils ne le feront jamais, car t'façon à part quatre geeks, personne n'y comprends, ou ne veut y regarder.
Le 24/07/2024 à 23h27
- la couche agent qui s'occupe de la gestion de l'installation, de l'initialisation, des mises à jour de tous les modules
- une couche communication pour les métriques et le protocole de commande
- la couche moteur, qui est du code binaire exécutable chargé par l'agent. Le moteur est le composant qui fait les analyses. Dans le cas d'eBPF, la couche moteur tourne en usermode. Selon la tâche, certains outils peuvent faire tourner plusieurs moteurs différents en parallèle.
- la couche interface, qui fait le pont entre le moteur et le système. Dans le cas d'eBPF, le code qui va être injecté en sandbox, dans le cas windows, un pilote noyau avec des interceptions sur des fonctions précises
- la couche data: db contenant signatures, patterns, ... exploités par la couche moteur.
Quand un outil comme Crowdstrike se me à jour, il peut donc avoir de nouveaux binaires et de nouvelles données.
Pour avoir un problème d'adressage mémoire soudain, il peut y avoir:
- un bug dans le module moteur
- des données malformées ou corrompues menant à un plantage du moteur si celui-ci manque de robustesse.
Le 23/07/2024 à 17h24
Le 23/07/2024 à 17h44
Le 24/07/2024 à 16h45
Le 23/07/2024 à 18h07
Le 24/07/2024 à 00h37
Le 24/07/2024 à 18h34
Le 26/07/2024 à 13h17