Fiasco CrowdStrike : Microsoft persiste et signe, tout est la faute de l’Europe

Fiasco CrowdStrike : Microsoft persiste et signe, tout est la faute de l’Europe

Os à ronger

59

Fiasco CrowdStrike : Microsoft persiste et signe, tout est la faute de l’Europe

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.

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.

Commentaires (59)


À propos de la version Linux, j'ai vu passer ce message de Matthew Garrett ces derniers jours :

« 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…
Modifié le 23/07/2024 à 12h53

Historique des modifications :

Posté le 23/07/2024 à 12h53


À propos de la version Linux, j'ai vu passer ce message de Matthew Garrett ces derniers jours :


« 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…

Les kernels panic du mois dernier ne vont pas trop dans ce sens, sauf à ce que l'utilisation de ces hooks soit récente.

Et dans les commentaires, j'ai trouvé celui-ci très instructif :
ils l'utilisent (NdM: cette nouvelle implémentation), mais l'ancienne implémentation est toujours disponible (et documentée comme l'option à privilégier).


Bref, cela aurait très bien pu arriver sous Linux.

fdorin

Les kernels panic du mois dernier ne vont pas trop dans ce sens, sauf à ce que l'utilisation de ces hooks soit récente.

Et dans les commentaires, j'ai trouvé celui-ci très instructif :
ils l'utilisent (NdM: cette nouvelle implémentation), mais l'ancienne implémentation est toujours disponible (et documentée comme l'option à privilégier).


Bref, cela aurait très bien pu arriver sous Linux.
De ce que j’ai compris (à prendre avec des pincettes, donc), les kernels panic étaient avec l’implémentation eBPF _mais_, il s’agissait d’un backport d’eBPF par RedHat pour le vieux noyau utilisé du fait de leur politique LTS (la version majeure du noyau ne change pas mais il y a tellement de backports que ce n’est plus comparable à un noyau Linux vanilla).

Bref, le module eBPF de CrowdStrike aurait révélé un bug dans le backport d’eBPF, rapidement corrigé par RedHat.

Triton

De ce que j’ai compris (à prendre avec des pincettes, donc), les kernels panic étaient avec l’implémentation eBPF _mais_, il s’agissait d’un backport d’eBPF par RedHat pour le vieux noyau utilisé du fait de leur politique LTS (la version majeure du noyau ne change pas mais il y a tellement de backports que ce n’est plus comparable à un noyau Linux vanilla).

Bref, le module eBPF de CrowdStrike aurait révélé un bug dans le backport d’eBPF, rapidement corrigé par RedHat.
Sachant que la plupart des entreprises utilisent quasiment toujours des versions LTS ...

Triton

De ce que j’ai compris (à prendre avec des pincettes, donc), les kernels panic étaient avec l’implémentation eBPF _mais_, il s’agissait d’un backport d’eBPF par RedHat pour le vieux noyau utilisé du fait de leur politique LTS (la version majeure du noyau ne change pas mais il y a tellement de backports que ce n’est plus comparable à un noyau Linux vanilla).

Bref, le module eBPF de CrowdStrike aurait révélé un bug dans le backport d’eBPF, rapidement corrigé par RedHat.
D'autre part le panic ne venait pas directement de l'exécution du programme ebpf, mais de sa vérification au préalable, un programme ebpf be pouvant pas de lui-même provoquer un kernel panic.
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)
Dans l'ordre de responsabilité microsoft n'arrive, au pire, que troisième. Il y a d'abord CrowdStrike bien évidement mais aussi les responsables informatique des boites qui ne font pas tester pas les mise à jour avant de les déployer sur des systèmes aussi critiques. J'aurais compris sur un bug plus subtile mais pas dans ce cas là.

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 :bocul:
Modifié le 23/07/2024 à 13h46

Historique des modifications :

Posté le 23/07/2024 à 13h46


Dans l'ordre de responsabilité microsoft n'arrive, au pire, que troisième. Il y a d'abord CrowdStrike bien évidement mais aussi les responsables informatique des boites qui ne font pas tester pas les mise à jour avant de les déployer sur des systèmes aussi critiques. J'aurais compris sur un bug plus subtile mais pas dans ce cas là.

Coïncidence, hier j'ai essayé de jouer à Once Human et deux fois de suite crash/reboot du pc à cause d'un plantage totale du drivers graphique, cause différentes même résultat :bocul:

Ce n'est pas une question de mise à jour testée ou non, vu que c'est l'auto-update d'un fichier de configuration de la part de la solution CrowdStrike.
Les responsables informatiques ce font toujours taper dessus même si c'est pas de leur faute. En l’occurrence ici ce n'est pas possible de faire ce que tu dis, l'outil ce met à jour tout seul plusieurs fois par jour depuis les servers crowdstrike à la manière des définitions de virus pour un antivirus.

Concernant ton plantage graphique si t'es avec un cpu intel serie 13 ou 14 c'est potentiellement ton CPU qui commence à déconner.
https://www.youtube.com/watch?v=gTeubeCIwRw

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.

ashlol

Les responsables informatiques ce font toujours taper dessus même si c'est pas de leur faute. En l’occurrence ici ce n'est pas possible de faire ce que tu dis, l'outil ce met à jour tout seul plusieurs fois par jour depuis les servers crowdstrike à la manière des définitions de virus pour un antivirus.

Concernant ton plantage graphique si t'es avec un cpu intel serie 13 ou 14 c'est potentiellement ton CPU qui commence à déconner.
https://www.youtube.com/watch?v=gTeubeCIwRw

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.
Les responsables informatiques ont des choix à faire, et certains ne sont pas heureux, mais "errare humanum est". Pour Falcon Sensor de Crowdstrike ils ont accepté une solution avec mise à jour directe depuis le fournisseur. Le but: éviter un scénario à la "Wannacry" en réagissant le plus vite possible pour contrer une diffusion massive d'un vers ou d'un virus.
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.
L'implémentation de Falcon Sensor ne permet pas de faire de pré-tests, et c'est bien un des soucis - il n'y a qu'un canal de diffusion pour les mises à jour.
Merci pour cet article, complétant techniquement ce qu’on peut lire sur d’autres presses, notamment les aspects vs. Linux et macOS !
Ce qui serait bien c'est que du coup Microsoft fasse comme MacOS et ban tous les accès noyaux ce qui permettrait de virer tous ces rootkits et systeme anti triche des jeux du noyau. Mais bon ne vivant pas dans le monde des bisounours pas sûr que ça arrive un jour.
Moi je vois ça comme ceci: les clients sont libres d'installer n'importe quelle cochonnerie dans leurs serveurs, c'est donc en partie leur responsabilité.

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...

Visiblement CrowdStrike semble être un "standard de fait" dans énormément de boîtes donc je suppose que le choix a été réfléchi. On est loin du "n'miporte quelle cochonnerie" ici.

LostSoul

Visiblement CrowdStrike semble être un "standard de fait" dans énormément de boîtes donc je suppose que le choix a été réfléchi. On est loin du "n'miporte quelle cochonnerie" ici.
Un standard de fait est justement l'opposé d'une sélection réfléchie. Que le produit soit bon ou mauvais, le niveau de réflexion en entreprise se limite dans ce genre de situation à installer le truc populaire qui a le plus de partenaires sans faire d'analyse de risque.

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?

Modifié le 24/07/2024 à 18h32

Historique des modifications :

Posté le 24/07/2024 à 17h35


Un standard de fait est justement l'opposé d'une sélection réfléchie. Que le produit soit bon ou mauvais, le niveau de réflexion en entreprise se limite dans ce genre de situation à installer le truc populaire qui a le plus de partenaires sans faire d'analyse de risque.

Pourtant il y a des signaux qui devraient inciter à la prudence dans ce genre de cas (crowdstrike coche beaucoup de cases mais pas toutes):

- 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?

ragoutoutou

Un standard de fait est justement l'opposé d'une sélection réfléchie. Que le produit soit bon ou mauvais, le niveau de réflexion en entreprise se limite dans ce genre de situation à installer le truc populaire qui a le plus de partenaires sans faire d'analyse de risque.

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 produit tourne t'il dans le noyau et/ou avec les niveaux de privilège les plus élevés?
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.

LostSoul

- le produit tourne t'il dans le noyau et/ou avec les niveaux de privilège les plus élevés?
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.
C'était des critères généraux, j'ai déjà pu confronter Crowdstrike à ces critères...

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.

ragoutoutou

C'était des critères généraux, j'ai déjà pu confronter Crowdstrike à ces critères...

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.
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.


Je réagis juste sur la fin de ton commentaire (étant plutôt d'accord avec le reste). La différence majeure que je vois dans ton analogie, c'est qu'en informatique, les pirates et auteurs d'outils malveillants sont intéressés pour connaitre les mécanismes de détection mis en place, afin de pouvoir les contourner / éviter.

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.

fdorin

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.


Je réagis juste sur la fin de ton commentaire (étant plutôt d'accord avec le reste). La différence majeure que je vois dans ton analogie, c'est qu'en informatique, les pirates et auteurs d'outils malveillants sont intéressés pour connaitre les mécanismes de détection mis en place, afin de pouvoir les contourner / éviter.

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.
"La différence majeure que je vois dans ton analogie, c'est qu'en informatique, les pirates et auteurs d'outils malveillants sont intéressés pour connaitre les mécanismes de détection mis en place, afin de pouvoir les contourner / éviter."

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.

ragoutoutou

"La différence majeure que je vois dans ton analogie, c'est qu'en informatique, les pirates et auteurs d'outils malveillants sont intéressés pour connaitre les mécanismes de détection mis en place, afin de pouvoir les contourner / éviter."

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.
Ce que tu dis est vrai concernant la recherche de failles de sécurité.

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.

fdorin

Ce que tu dis est vrai concernant la recherche de failles de sécurité.

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.
"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."

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.

ragoutoutou

"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."

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.
"Eeeeeuuuuuh ... non, pas vraiment. Pas besoin du code source pour ça"

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.

fdorin

"Eeeeeuuuuuh ... non, pas vraiment. Pas besoin du code source pour ça"

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.
Honnêtement, je trouve que c'est plutôt à l'obscurité de prouver sa valeur ajoutée par rapport au préjudice de perdre la possibilité d'avoir de nombreux contrôles indépendants de haut niveau.

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.

ragoutoutou

Honnêtement, je trouve que c'est plutôt à l'obscurité de prouver sa valeur ajoutée par rapport au préjudice de perdre la possibilité d'avoir de nombreux contrôles indépendants de haut niveau.

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.
Je pourrais te dire la même chose concernant la disponibilité des sources :
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 ?

fdorin

Je pourrais te dire la même chose concernant la disponibilité des sources :
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 ?

1) A minima, pour l'mage de l'entreprise
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.

ragoutoutou

1) A minima, pour l'mage de l'entreprise
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.
1) donc non
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)
Après, pour aller dans le sens de Microsoft (ou des fois ça arrive), c'est un peu surréaliste de créer une faille juste pour ne pas être en position dominante.

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 ?
Sans vouloir spécialement taper sur crosoft, mais si pour répondre à la demande de l'Europe, ils avaient fournis des APIs pour accéder au kernel et que les EDR/AV (y compris celui de crosoft) étaient en user space et tapaient sur ces apis, le pb auraient surement été moins violent.
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.

Bourrique

Sans vouloir spécialement taper sur crosoft, mais si pour répondre à la demande de l'Europe, ils avaient fournis des APIs pour accéder au kernel et que les EDR/AV (y compris celui de crosoft) étaient en user space et tapaient sur ces apis, le pb auraient surement été moins violent.
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.
Et si cela implique une réécriture partielle du noyau ? Et de leur solution de sécurité ?

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.

fdorin

Et si cela implique une réécriture partielle du noyau ? Et de leur solution de sécurité ?

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.
"Et si cela implique une réécriture partielle du noyau ? Et de leur solution de sécurité ?

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...

Citan

"Et si cela implique une réécriture partielle du noyau ? Et de leur solution de sécurité ?

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...
J'avoue que ça me fatigue cet argument. C'est un GAFAM, donc ils peuvent se le permettre car ils ont l'argent. Ce n'est pas comme ça que les choses fonctionnent.

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 !

fdorin

J'avoue que ça me fatigue cet argument. C'est un GAFAM, donc ils peuvent se le permettre car ils ont l'argent. Ce n'est pas comme ça que les choses fonctionnent.

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 !
"J'avoue que ça me fatigue cet argument. C'est un GAFAM, donc ils peuvent se le permettre car ils ont l'argent. Ce n'est pas comme ça que les choses fonctionnent."

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.
Modifié le 12/09/2024 à 00h15

Historique des modifications :

Posté le 12/09/2024 à 00h14


"J'avoue que ça me fatigue cet argument. C'est un GAFAM, donc ils peuvent se le permettre car ils ont l'argent. Ce n'est pas comme ça que les choses fonctionnent."

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.

Verrouiller le kernel, c'est empêcher le développement sur l'OS de système matériel ou de hacking (émulation matériel) qui ne peuvent être autrement.
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.
C'est un eu cornélien comme choix : soit on tue l'industrie de l'antivirus, soit on s'oriente vers une solution potentiellement plus robuste, mais dépourvue de concurrence. A noter que s'il n'y a qu'un seul AV existant (genre celui de MS), ce dernier sera forcément celui qui sera ciblé pour ses failles.

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.
"L'OS devrait être le seul à accéder au kernel?"

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...

ragoutoutou

"L'OS devrait être le seul à accéder au kernel?"

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...

N'oubliez pas que toute surcouche type api, sandbox etc. induit d'office une perte de perfs, c'est entre autre pour ça que les drivers graphiques tournent au niveau kernel. Je ne sais pas quel est le degré d'impact mais visiblement c'est suffisamment significatif pour qu'on garde cette possibilité, je pense.

LostSoul

N'oubliez pas que toute surcouche type api, sandbox etc. induit d'office une perte de perfs, c'est entre autre pour ça que les drivers graphiques tournent au niveau kernel. Je ne sais pas quel est le degré d'impact mais visiblement c'est suffisamment significatif pour qu'on garde cette possibilité, je pense.
Attention à ce que l'on met derrière le mot perfs.

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.

LostSoul

N'oubliez pas que toute surcouche type api, sandbox etc. induit d'office une perte de perfs, c'est entre autre pour ça que les drivers graphiques tournent au niveau kernel. Je ne sais pas quel est le degré d'impact mais visiblement c'est suffisamment significatif pour qu'on garde cette possibilité, je pense.
Si la sécurité est trop chère, choisissez l'insécurité.

ragoutoutou

Si la sécurité est trop chère, choisissez l'insécurité.

ce n'est pas une question de sécurité mais de risque, tout le monde sait ça. C'est moins risqué d'avoir un agent qui est efficace 99.9% du temps et qui en plus n'est pas vindicatif qu'une intrusion par un agent malveillant.

LostSoul

ce n'est pas une question de sécurité mais de risque, tout le monde sait ça. C'est moins risqué d'avoir un agent qui est efficace 99.9% du temps et qui en plus n'est pas vindicatif qu'une intrusion par un agent malveillant.
Dans la mesure où le choix du produit n'est pas basé sur une analyse de rique mais parce-que c'est un standard comme tu l'as si bien stipulé plus haut, ...

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.

Article passionnant (comme les précédents sur le sujet). Bravo Next et Vincent.

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?
Modifié le 23/07/2024 à 14h50

Historique des modifications :

Posté le 23/07/2024 à 14h45


Article passionnant (comme les précédents sur le sujet). Bravo Next et Vincent.

Donc grosso modo, L'Europe a demandé à MS de donner les mêmes droits aux éditeurs tiers sur les accès que les siens. Au lien de développer une solution "sécurisée" permettant d'éviter qu'un outil, tiers ou non, ne fasse planter le système (grands pouvoirs, grandes responsabilités, tout ça), MS a juste ouvert les vannes et donné des accès haut niveau à tout le monde, quoi :-/
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... :censored:
CrowdStrike a bien fait planter Linux il y a quelques semaines ( https://www.neowin.net/news/crowdstrike-broke-debian-and-rocky-linux-months-ago-but-no-one-noticed/ ), comme quoi même en blindant l'approche ça n'évite pas d'avoir des problèmes similaires.

Max Damage

CrowdStrike a bien fait planter Linux il y a quelques semaines ( https://www.neowin.net/news/crowdstrike-broke-debian-and-rocky-linux-months-ago-but-no-one-noticed/ ), comme quoi même en blindant l'approche ça n'évite pas d'avoir des problèmes similaires.
Merci, je n'avais pas vu cette nouvelle. Pas bien rassurant sur la qualité des produits CrowdStrike, en tout cas.
Et cela prouve la nécessité de mieux gérer ce genre d'outils pour éviter des pannes catastrophiques en chaîne.

Max Damage

CrowdStrike a bien fait planter Linux il y a quelques semaines ( https://www.neowin.net/news/crowdstrike-broke-debian-and-rocky-linux-months-ago-but-no-one-noticed/ ), comme quoi même en blindant l'approche ça n'évite pas d'avoir des problèmes similaires.
D'ailleurs on voit vite la différence de traitement dans les médias entre linux (totalement passé à côté des médias mainstream) et win. Ca semblerait prouver aussi que les parts de marché linux restent faibles comparées aux parts de MS.

LostSoul

D'ailleurs on voit vite la différence de traitement dans les médias entre linux (totalement passé à côté des médias mainstream) et win. Ca semblerait prouver aussi que les parts de marché linux restent faibles comparées aux parts de MS.
En même temps, la mise à jour sous Linux n'ayant pas cloué au sol des avions ou reporté des opérations chirurgicales, elle a été beaucoup moins visible par le commun des mortels. C'est peut être ça aussi là cause du traitement radicalement différent entre les deux problèmes...

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é)..

fdorin

En même temps, la mise à jour sous Linux n'ayant pas cloué au sol des avions ou reporté des opérations chirurgicales, elle a été beaucoup moins visible par le commun des mortels. C'est peut être ça aussi là cause du traitement radicalement différent entre les deux problèmes...

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é)..
La question c'est "pourquoi linux n'est pas présent dans ces domaines?" alors qu'on sait bien que ca reste redoutablement stable, surtout pour du serveur applicatif... MS trop présent ? Trop de lobbyisme ? Pas assez d'équivalents sur linux pour les logiciels ? Dans les années 80/90 j'aurais pu admettre mais à l'heure des applis web, même les applis .net peuvent se passer de Windows, du coup ca reste inquiétant cette prédominance de Windows un peu partout (et je suis un dev Windows donc c'est pas un parti pris)

LostSoul

La question c'est "pourquoi linux n'est pas présent dans ces domaines?" alors qu'on sait bien que ca reste redoutablement stable, surtout pour du serveur applicatif... MS trop présent ? Trop de lobbyisme ? Pas assez d'équivalents sur linux pour les logiciels ? Dans les années 80/90 j'aurais pu admettre mais à l'heure des applis web, même les applis .net peuvent se passer de Windows, du coup ca reste inquiétant cette prédominance de Windows un peu partout (et je suis un dev Windows donc c'est pas un parti pris)
De ce que j'ai vu via la panne Crowdstrike (ou en tout cas, ce qui a été montré partout dans les média) se sont de beaux écrans bleus. Donc plutôt du frontend.

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

LostSoul

La question c'est "pourquoi linux n'est pas présent dans ces domaines?" alors qu'on sait bien que ca reste redoutablement stable, surtout pour du serveur applicatif... MS trop présent ? Trop de lobbyisme ? Pas assez d'équivalents sur linux pour les logiciels ? Dans les années 80/90 j'aurais pu admettre mais à l'heure des applis web, même les applis .net peuvent se passer de Windows, du coup ca reste inquiétant cette prédominance de Windows un peu partout (et je suis un dev Windows donc c'est pas un parti pris)
Il faut voir ce qui a planté exactement dans les entreprises. De nombreuses entreprises basent des services infrastructure critiques sur Active Directory (DNS, authentication) ou utilisent SLQ server pour la persistance. Avec simplement ces éléments, sans même parler des applicatifs, il y a déjà moyen de mettre de nombreuses infras par terre.
J’ai hâte d’avoir une compréhension encore plus technique de l’affaire, car c’est toujours pas clair pour moi comment on peut avoir une erreure de page mémoire d’un programme suite à la mise à jours de son fichier de conf.
calmez votre hâte au plus vite, vous n'en aurez pas.
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.
Simple, ces outils sont généralement composés de plusieurs couches:
- 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.

CrowdStrike, l'entreprise qui porte bien son nom 🤣
C'est vrai qu'au sens bowling, c'est efficace ....
Je peux te dire que ce jeu de mot a dû faire le tour des data centers :p
Méchante UE. À cause d'elle, Microsoft ne peut avoir le monopole pour tanker Windows.
Mais c'est l'UE qui empêche les redémarrages en mode sans échec si jamais on voit qu'on est dans une boucle ? Parce que certes le fautif est CrowsStrike, mais eux ils ont corrigé assez vite leur problème. Par contre ce qui coûte très cher à tout le monde, c'est que Windows s'est coincé au lieu de se remettre dans un état rendant possible un dépannage à distance.
Avec des VM ou des serveurs avec une interface de gestion à distance, ce n'est pas un gros problème. Le problème est plutôt si tu dois en dépanner 6000 à la main.
M$, ça ose tout : c'est à ça qu'on les reconnait
Fermer