Début novembre, Microsoft annonçait le retrait de son outil de sécurité EMET à la fin de son cycle actuel de vie, soit en juillet 2018. Un outil apprécié dont certains craignent déjà le départ. Des chercheurs demandent ainsi à l’éditeur de renoncer à cette retraite.
La sécurité de Windows est probablement l’un des sujets les plus débattus et les plus riches. Avec une part de marché écrasante, le poids pesant sur les épaules de Microsoft est difficilement comparable à celui des autres systèmes. Non qu’il faille plaindre l’entreprise : elle a œuvré dans ce sens. Mais en 2004 et 2005, quand son Windows XP a commencé à crouler sous les attaques, elle a dû changer son fusil d’épaule.
La marche continue (et forcée) de la sécurité sous Windows
L’explosion d’Internet au début des années 2000 a largement simplifié l’exploitation des failles. Il n’était plus vraiment question de circulation de CD ou de DVD, mais d’une activation distante. Ce fut notamment la grande époque des vers Blaster et Sasser, qui pouvaient attaquer en quelques minutes n’importe quel Windows XP connecté et qui n’avait pas la mise à jour idoine. À tel point que Microsoft avait pratiquement stoppé le développement de Vista pour se concentrer sur le Service Pack 2 de XP.
Depuis, chaque Windows a intégré un nombre croissant de protections. Le SP2 avait par exemple implémenté une version maison du « NX bit », la DEP (Data Execution Prevention). Vista est allé plus loin avec l’un des principaux apports dans ce domaine, l’ASLR (Address space layout randomization), qui permet d’affecter des zones mémoire aléatoires à des composants clés afin que les malwares ne puissent plus les chercher sur cette seule information.
EMET, l'outil d'atténuation des risques
Cependant, et c’est ici qu’EMET (Enhanced Mitigation Experience Toolkit) intervient, il existe une limite à ce que peut faire un système d’exploitation – dans l’état actuel des choses – sans rendre l’utilisation du produit plus « pénible » pour l’utilisateur. C’est la difficile thématique du curseur se déplaçant entre la sécurité et la facilité d’utilisation.
EMET est donc un outil proposé depuis longtemps par Microsoft pour ceux qui veulent renforcer la sécurité, au détriment parfois de la simplicité. Il permet de forcer différents niveaux de protection sur les composants et logiciels, en forçant par exemple ces derniers à utiliser des techniques comme le DEP et l’ASLR, même quand ils n’ont pas été prévus pour. Avec parfois bien sûr un risque de mauvais fonctionnement, mais une barrière plus ou moins forte en cas de faille 0-day contre un élément n'ayant encore aucun correctif.
Microsoft veut arrêter EMET, l'université Carnegie Mellon pointe le danger
Or, Microsoft veut se débarrasser d’EMET. Pourquoi ? Parce que Windows 10 est arrivé entre temps. Dans son billet du 3 novembre, l’éditeur fait la liste des protections intégrées au système et qui n’étaient pas présentes avant, notamment dans Windows 7 qui sert souvent pour les comparaisons. Conscient toutefois de la grogne des utilisateurs d’EMET, la firme avait indiqué que la date initiale d’arrêt, le 27 janvier prochain, avait été repoussée au 31 juillet 2018.
Pour les chercheurs de l’université de Carnegie Mellon, ce n’est pas suffisant. Leur CERT (Computer emergency response teams) a publié récemment un véritable plaidoyer pour que Microsoft revienne sur sa décision. Pourquoi ? Parce que Windows, même dans sa version 10, sera toujours beaucoup mieux protégé avec EMET que sans. D’ailleurs, dans un tableau qui fait l’inventaire des fonctionnalités, on voit clairement que Windows 7 avec EMET reste bien mieux protégé qu’un Windows 10 classique (mais moins qu’un Windows 10 avec EMET).
Les chercheurs accusent Microsoft de mentir quand elle explique que Windows 10 n’a plus besoin d’EMET et que toutes les protections ont été intégrées. Ce qui est vrai pour le « tronc principal », mais l’entreprise omet un point important : la possibilité de forcer ces sécurités pour chaque application. Windows 10 n’offre effectivement par cette capacité, à moins justement qu’on ne lui adjoigne EMET.

Le problème des sécurités forcées
Le CERT de l’université tient à faire le distinguo sur l’importance de l’outil. Les chercheurs reconnaissent que Windows 10 intègre effectivement de très bons outils de sécurité et autres mesures d’atténuation des risques, mais les logiciels doivent avoir été spécifiquement compilés pour en tirer parti. EMET, à l’inverse, force automatiquement les mesures, au risque de créer parfois une incompatibilité.
En prévoyant l’arrêt du support d’EMET pour juillet 2018, Microsoft laisse certes 18 mois supplémentaires aux entreprises pour s’y adapter. Mais les chercheurs pointent le danger inhérent à ce recul : quand le support s’arrêtera, d’autres logiciels de Microsoft, notamment Office 2007, ne seront plus supportés non plus. D’où l’intérêt de continuer à proposer l’outil, qui atténue sérieusement le risque de voir des failles 0-day exploitées.
Certaines mesures peuvent être manuellement appliquées
L’université précise cependant plusieurs points. D’abord, que l’arrêt du support d’EMET ne signifie pas qu’il arrêtera de fonctionner. Il ne sera cependant plus mis à jour, Microsoft ne fournira plus d’aide, et il sera sans doute plus difficile à télécharger. Ensuite, que d’un simple point de vue atténuation des risques, migrer vers Windows 10 est une bonne idée, de même qu’installer EMET tant que c’est possible (et si le besoin s’en fait sentir).
Enfin, que certaines actions accomplies par EMET peuvent être réalisées manuellement. C’est notamment le cas de l’activation du DEP et de l’ASLR à l’échelle du système entier. Les chercheurs fournissent la marche à suivre, qui passe par une commande et l’édition du registre. Mais attention, certains logiciels peuvent ne pas être compatibles, auxquels cas ils ne fonctionneront plus. Il n’y aura alors pas de solution miracle : désactiver la protection « fautive » ou se passer du logiciel.
Commentaires (40)
Putain le sous titre
" />
" />
" />
" />
La news n’a pas la moindre importance auj regard de ce sous titre
Ah EMET ! Un outil Microsoft qui arrivait à faire planter toutes mes appli Office 365 quand je les lançais. Vite désinstallé à l’époque.
Si j’ai bien compris EMET force la sécurité quand des logiciels ont conçus sans cette optique et les utilisateurs râlent car son abandon signifie qu’il faudrait demander à tous les éditeurs de se remettre à concevoir leur logiciel dans un soucis de sécurité.
Je comprends que MS souhaite se débarrasser de sa dette historique et il faudrait que les utilisateurs l’acceptent aussi: windows XP ne marchera pas Ad vitam æternam et les logiciels basé sur win32 n’ont plus.
Ah les bonnes références!
EMET est une plaie à configurer. Je conseille MalwareBytes anti Exploit et un firewall avec HIPS.
Jamais eu de pb avec EMET depuis 4 ans que je l’utilise avec tout à max… sauf une fois sur win2003 avec office 2003. Réduire les réglages a suffi
Oui, mais EMET dédoigne les éditeurs de concevoir des logiciels qui intègre la sécurité dès sa conception.
Et sa suppression obligerait les éditeurs à se bouger le cul.
Je ne connaissais pas EMET, comme sans doute 99% des utilisateurs Windows. C’est vraiment utile ? ou bien un truc plus chiant à configurer qu’autre chose ?
Plus chiant à configurer qu’autre chose… Mais c’est comme ça.. Généralement une bonne sécurité implique de mettre les mains dans le cambouis et de pas tout laisser en conf par défaut…
sous titre de compétition
" />
Ce sous titre de la folie ! Un bon 12.21 / 10 !
“Ce qui est vrai pour le « tronc principal », mais l’entreprise omet un point important : la possibilité de forcer ces sécurités pour chaque application. Windows 10 n’offre effectivement par cette capacité, à moins justement qu’on ne lui adjoigne EMET justement.”
Justement.
C’est un vrai retour vers le futur cette news…..
Bravo le sous titre….
Pareil, j’ai pas lu la news, je ne sais même pas ce qu’est EMET, mais le sous titre mérite le détour
" />
Bon je lirais ça demain quand même.
À propos de win32 :
Jamais il ne sera abandonné, il y a trop de logiciels pro qui tournent là-dessus. Si un jour microsoft sort une version de windows qui ne supporte pas win32 ce sera un échec commercial, comme windows rt.
Recoder toutes ces applications prendrait des années pour un gain de productivité nul. En 2100 il y aura encore des applications win32.
Oùlà, ça pique ! Dédouane s’il vous plaît !
Sinon, oui EMET est un très bon outils et en le mettant à fond, je n’ai jamais eu de problème non-plus.
Ce n’est pas une conversion, juste un encapsulage pour rajouter la sécurité inhérente au Store à des applications win32.
L’étape suivante, ça sera d’utiliser des contenaires win32 qui seront isolés du reste du système. Et à terme, tout en UWP.
pour ça que j’ai mis convertir entre guillemets :p
Merci, enfin un post correctif juste ^^!
D’accord que la sécurité n’est pas donné par un outil magique, mais je trouve que certains éditeurs sont plus que léger quand ils conçoivent leur logiciel qui manipule des données destinées à être confidentiel.
Nom de zeus!
" />
Non, on ne met pas un Arduino, on sépare l’application et le driver. Bref, on fait du logiciel, pas de la bidouille.
[…] mais les logiciels doivent avoir été spécifiquement compilés pour en tirer parti.
Quelqu’un peut m’en dire plus à ce sujet ? Les applications développées sous la plateforme .NET en bénéficie automatiquement ?
En fait EMET fournit des algorithmes améliorés de DEP/ASLR. Ce sont toutes des technologies qui luttent contre les buffer overflow. A moins que tu es spécifiquement intégré du code unsafe. Les applications .NET ne sont pas concernées. Tu n’as pas de buffer overflow possible en .NET.
Merci pour ta réponse. Donc toutes les applications .NET fonctionnent automatiquement avec EMET ? C’est bon à savoir.
Elles ne fonctionnent pas avec EMET. C’est juste qu’il est inutile pour ces applications.
tu ne devrais pas plutôt dire “elle ne tire aucun parti de EMET”? là ça donne l’impression qu’activer EMET va empecher toutes applis .NET de fonctionner
" />
Oui en effet ma phrase laissait à désirer
" />
fatigue^^
Possible si on ne veut plus changer l’application. Mais qu’est-ce que le développeur va faire pour sa prochaine mise à jour ? Utiliser win32 ou bien faire un frankenstein win32/uwp ? Probablement pas.
Oui on peut “encapsuler” win32 certes, mais ce sera toujours du win32 qu’il faudra utiliser et coder.
Très bon article
" />