concernant la faille elle même, pour ceux qui pensent “encore une faille dans IE!”, gardez à l’esprit qu’il s’agit d’une attaque ciblée contre des entreprises ou des agences gouvernementales qui utilisent IE9/10 ou 11.

les hackers qui ont développé cet exploit ne se sont même pas donné la peine de rendre l’exploit compatible XP/IE6/7/8 parce qu’ils ont identifié que leur cible utilisait une version plus récente d’IE.



tout ça pour dire que dans le cadre d’attaques ciblées, peu importe le navigateur que vous utilisez, les hackers qui veulent vraiment s’en prendre à vous (si vous êtes une cible de grande valeur) développeront un exploit pour firefox/chrome si vous n’utilisez pas IE. Et à en juger par l’historique de sécurité de Firefox, je suis sûr que les hackers prefereraient que tout le monde migre vers Firefox, ça leur ferait moins de protections à contourner ;)

concept a écrit :



vu que windows, internet explorer, outlook et tous les produits microsoft contiennent une porte dérobée, je ne vois pas trop ce que cette faille va changer



ceux qui continuent à utiliser ces logiciels ne se préoccupent pas du tout de sécurité et je ne crois pas trop que cette news va les inquiéter







poursuis ton raisonnement jusqu’au bout et bannis également les produits open source.



après la faille OpenSSL restée ouverte deux ans, on voit bien que si le NSA le veut, elle a pu introduire des failles dans n’importe quelle appli open source sans que personne ne s’en aperçoive.



mais au final, est ce vraiment nécessaire d’introduire volontairement des failles quand on sait que la NSA achète régulièrement aux sociétés de recherche en sécurité des failles dans IE/chrome/safari/firefox avec les exploits qui vont avec pour windows/osx/linux?



au final les plus naïfs sont les gens comme toi qui croient qu’il y a des backdoors dans Windows et que l’open source est la réponse à tous leurs problèmes.



la NSA n’a probablement pas introduit la faille heartbleed dans OpenSSL, mais certains l’accusent de l’avoir découverte et d’en avoir profité pendant 2ans.

YesWeekEnd a écrit :



Il convient d’être moins catégorique.







tu connais des plugins grand public non compatibles EMET?



de ce que je sais, tous les plugins courant sont compatibles avec EMET, du moment que tu n’utilises pas des versions dépassées (mais si tu utilises encore Flash Player 8 tu as d’autres soucis à te faire ;) )

RaoulC a écrit :



SI je comprend bien, il ya une faille dans IE, qui est difficilement exploitable à cause de l’ASLR et du DEP.



Donc on se sert de Flash comme vecteur d’attaque.



Loin de moi l’idée de défendre IE mais vu qu’il existe des mesures de sécurité dans IE censées limiter l’exploitation d’une éventuelle faille… j’ai bien envie de taper sur Flash" />







pas directement la faute à Flash pour une fois.



mais disons que Flash est en train de devenir le moyen privilégié pour contourner ASLR et DEP.



techniquement, adobe pourrait améliorer flash Player pour rendre ce type de contournement plus compliqué à réaliser via flash.

Khalev a écrit :



Mais ça ne veut rien dire sur la sécurité du bouzin. Le plugin java n’avait pas été tenté non plus lors du concours.







le plugin Java n’a pas été hacké durant le dernier pwn2own pour une bonne raison: les règles du concours imposaient que l’exploit fonctionne sans intervention de l’utilisateur, et donc contourne le click to play introduit dans java7.



une contrainte assez extrême, puisque si les devs d’oracle ont fait leur boulot a peu près correctement, il est assez improbable qu’il y ait des failles permettant de bypasser le click to play tant la surface d’exposition aux failles est réduite.



mais pour info, vupen a déclaré avoir un exploit contre java 7. Mais pas de bypass pour le click to play.

RaoulC a écrit :



Hum, tu rêves tout éveillé.

Déjà que l’on se plaint de la conso CPU/RAM des navigateurs actuels, alors en demander encore plus " />



Après, tout dépend de ce que tu entend par “bon nombre”.

Les décideurs IT un peu sérieux, peut être (encore que…faut avoir la machine qui tient la charge supplémentaire et souvent c’est une question de moyen)

Les geeks (les vrais, pas “je suis geek a COD mdr xdr lol”) surement.



Mais la vaste majorité des gens, si ca bouffe plus de RAM /CPU, ca passe à la trappe. " />







c’est marrant mais je pense le contraire.



si on expliquait bien aux utilisateurs lambda qu’ils auront potentiellement moins de malwares, ils accepteraient une légère réduction de performance. Franchement, 30% d’usage cpu/ram en plus c’est que dalle quand tu vois des core i5 avec 4go de ram qui passent 95% de leur temps avec 2go de ram libre et un usage cpu moyen de 5% durant la navigation web.

il n’y aurait pas de différence visible aux yeux de l’utilisateur lambda.



par contre les gros geeks qui pensent uniquement à faire un gros score aux benchmarks voudront absolument avoir le browser le plus rapide.



quant aux entreprises, si ya pas un acteur majeur genre MS ou Google, même si c’est plus sécurisé, ils ne voudront pas d’un browser managé créé par un petit éditeur.

malock a écrit :



Si je veux bien croire qu’une exécution de code dans un programme qui le gère type VM limite (largement) les dépassements de tampons, il ne faut pas non plus oublier que ce programme peut lui aussi en contenir des failles…







en pratique, je ne me souviens pas avoir déjà vu de faille RCE dans le .net Framework ou java exploitable à travers une appli légitime (hors failles dans des composants natifs comme les decodeurs d’image) pendant son exécution.



l’immense majorité des failles dans java/.net sont exploitables via des applets java ou des assemblies “malveillants” qui ont pour but de sortir de la VM hébergée dans le navigateur ou en hosting web.

Pour info, IE Metro n’est pas affecté par l’exploit car l’Enhanced Protected Mode est actif par défaut.



IE Mobile pour wp7/8 n’est pas affecté par la faille car il ne supporte plus VML (qui est une technologie dépréciée)







La solution la plus efficace est d’utiliser temporairement un autre navigateur, même si des mesures spéciales peuvent être mises en place





la solution la plus efficace est plutôt d’installer EMET pour ceux qui ne l’ont pas déjà fait, et ce, même s’ils n’utilisent pas IE.



comme l’a montré le dernier concours de sécurité Pwn2Own, mieux vaut utiliser IE avec EMET malgré cette faille, plutôt que d’utiliser Firefox ou Chrome.



pour rappel, la seule cible à ne pas avoir été attaquée lors de ce concours était IE11 avec EMET, malgré les 150 000$ de recompense.

Firefox, lui, avait été hacké 5fois, et ChromeOS 2fois…



comme quoi Microsoft sait comment s’y prendre pour développer un navigateur sécurisé. Malheureusement, à cause de la volonté de continuer à supporter des vieux plugins utilisés dans certaines entreprise, MS ne peut pas inclure les protections apportées par EMET directement dans Windows.



plus d’infos sur EMET pour ceux qui ne connaissent pas encore le principe de cet outil:

http://www.julien-manici.com/blog/EMET-protection-against-flaws-Internet-Explore…

malock a écrit :



Étonnamment, face à un argument du type “en contrepartie, on vous garantie qu’il n’y a plus de failles permettant exécuter du code arbitraire”, je souris puis je m’en vais.







si ton code est 100% managé, il ne peut pas être vulnérable à des buffer overflows ou des use-after-free qui conduisent souvent à la possibilité d’executer du code.



après ton code peut toujours avec des failles d’autre nature, mais déjà les failles RCE les plus graves sont évitées.



mais par 100% managé, j’entend qu’il faut avoir sa propre implementation des librairies de décodage d’image ou de SSL en code managé, sinon le code est potentiellement vulnérable aux failles de l’OS sous-jacent (puisque le .net Framework utilise le GDI ou WIC pour traiter les images par exemple)

sniperdc a écrit :



Bon on patch, ça ne m’étonne même plus une faille dans IE.







parce que tu t’imagines que Firefox et chrome ont moins de failles?

c’est beau la naïveté

concept a écrit :



Ben voyons.



Je suis parfaitement au courant du programme “Bullrun and Edgehill” et il n’en reste pas moins que l’open est la seule et unique voie sure, car les failles dans les programmes à sources ouvertes si elles existent peuvent être facilement repérées par la plupart des développeurs.







comme l’a prouvé la faille OpenSSL qui est restée ouverte pendant deux ans malgré le fait qu’il s’agit d’une des lib open source les plus importantes et une des plus utilisées au monde, cet argument c’est juste du pipeau.



concrètement, la plupart des failles qui résident dans les produits open source sont découvertes des années, parfois 20ans, après leur introduction.





Dans les programmes à sources fermées c’est en revanche non seulement beaucoup plus difficile mais également à la portée d’un très petit nombre car nécessite des compétences beaucoup plus pointues.





c’est faux.

tu t’imagines peut être que ceux qui cherchent des failles dans les produits open source le font en lisant le code source?



eh ben non. La plupart des failles sont découvertes via des méthodes de fuzzing qui se font au moment de l’exécution, sur du code déjà compilé. Le fait que le code soit open source ou non n’a aucune importance.





Alors je ne vois pas très bien comment rester dans la configuration la moins fiable peut être la meilleure option, tu nous expliqueras ce trait de génie j’espère.



D’ici là je maintiens que cette news est inutile. Les personnes pour qui la sécurité importe n’utilisent pas IE et les autres se moquent bien des failles à mon avis. Tant qu’ils ne voient rien de concret, ça ne leur fait ni chaud ni froid.





les faits parlent d’eux même.



IE avec EMET5 (ou 4.1 avec deep hook actif): aucun exploit connu, ni en liberté, ni PoC.



chrome, Firefox, safari, peu importe la plateforme (win, Android, osx, linux) ont tous déjà eu des exploits 0day ou sous forme de PoC.



peut être que la NSA possède un exploit 0day qui marche contre EMET et IE11?

mais une chose est sûre, la NSA a déjà accès à des exploits 0day contre tous les navigateurs sur toutes les plateformes sans EMET, puisque des sociétés sont spécialisées dans la création et la revente d’exploits clefs en main.



les backdoors dans Windows, c’est un fantasme de libriste debile. S’il y avait des backdoors, on les aurait déjà trouvé.



les failles, en revanche, sont présentes dans tous les logiciels, et représentent la forme la plus discrète et la plus efficace de backdoor.



maintenant libre à toi de continuer à vivre dans l’ignorance et à penser que tu es plus en sécurité avec ton Firefox open source. Mais les faits ont montré le contraire.

Khalev a écrit :



C’est bien ce que je dis, le concours p2o ne permet pas de savoir ce qu’il en est concernant la sécurité de IE avec EMET. Juste que ça ne rentrait pas dans les cases du concours p2o.







bah en tout cas pour des sommes moins élevées que 150 000$, tous les navigateurs sans EMET se sont fait “pwner” à plusieurs reprises, y compris safari sous osx.



donc à choisir, mieux vaut faire confiance à EMET.



surtout que jusqu’ici, on a jamais vu d’exploit en liberté qui contourne EMET.

même sur des cibles de haute valeur dans le cadre d’attaque ciblées comme on a pu le voir ici.



évidemment EMET peut être contourné, c’est déjà arrivé dans le passé.



mais tout laisse à penser que les hackers ont beaucoup plus de mal à attaquer un navigateur protégé par EMET, que n’importe quel navigateur sous windows/linux/osx sans EMET.

cyrilleberger a écrit :



Ou personne n’ait essayé de développer un tel exploit parce que le nombre d’utilisateurs d’EMET est très faible. Et que donc, cibler IE+EMET n’est pas rentable.



D’une manière générale, il est vraisemblablement plus sécure d’utiliser un navigateur plein de failles, mais qui a peu d’utilisateurs qu’un navigateur avec peu de failles mais plein d’utilisateurs. Les pirates cibleront toujours celui avec plein d’utilisateurs, mais si c’est plus facile d’attaquer l’autre.







dans le cadre d’une attaque générique qui a pour but d’infecter un max d’utilisateurs, oui.



mais dans le cadre d’une attaque ciblée, non!



si une cible de valeur utilise un navigateur rarement utilisé, ça n’a aucune importance puisque le hacker cherche à infecter une cible spécifique, et non une large population.







Ce qui ne veut pas dire qu’IE+EMET n’est pas fiable. C’est juste une cible pas intéressante pour les pirates.





dans la population générale, l’utilisation d’EMET est assez rare en effet.



mais l’utilisation de chromeOS est encore plus rare, et pourtant deux équipes de hackers se sont donné la peine de le hacker lors du dernier pwn2own (même recompense que pour IE11/EMET: $150 000)



ce qui laisse penser que EMET apporte un réel plus niveau sécurité, c’est les attaques ciblées comme la faille dont il est question dans cet article.



EMET est de plus en plus utilisé en entreprise et dans les agences gouvernementales (qui sont justement les cibles de ces attaques 0day) car MS encourage fortement à son adoption, offrant même officiellement un support technique pour ce produit.



jusqu’ici on n’a entendu parler que d’un seul PoC contournant EMET4.1 (donc pas une attaque réelle), et aucun contournant EMET5 ou EMET 4.1 avec deep hook et anti détour activés.