Concours Pwn2Own : Internet Explorer, Chrome et Firefox sont tombés
Et ce n'était que le premier jour
Comme chaque année, le concours de sécurité Pwn2Own rassemble les experts et hackers autour de la défense des navigateurs. Et comme à chaque nouvelle édition de l’évènement, tous les butineurs sont tombés sous les coups portés à leurs protections.
Année 2013, nouvelle hécatombe
Internet Explorer, Chrome, Firefox et Safari sont allés comme chaque année subir les assauts puissants perpétrés par les hackers et experts de sécurité. Le concours Pwn2Own, qui prend place durant la conférence CanSecWest, réunit tous ceux qui veulent tester les défenses des butineurs, avec à la clé des récompenses sonnantes et trébuchantes. Et jusqu’à présent, tous les navigateurs ont d’ailleurs toujours trébuché.
Microsoft, Google, Mozilla et Apple savent que le concours est un temps fort, car les investissements en sécurité dans leurs produits vont être mis à rude épreuve. Aucun navigateur n’est jamais ressorti indemne de ce concours et cette année ne fait pas exception, les deux premiers jours ayant été une véritable hécatombe. Presque toutes les dernières moutures sont tombées, les règles considérant une victoire lorsqu’un code arbitraire parvient à être exécuté sans que le navigateur ne puisse en limiter l’impact.
Voici les prix prévus pour chaque cas :
- Navigateurs
- Google Chrome sur Windows 7 : 100 000 dollars
- Internet Explorer :
- Version 10 sur Windows 8 : 100 000 dollars
- Version 9 sur Windows 7 : 75 000 dollars
- Firefox sur Windows 7 : 60 000 dollars
- Safari sur OS X (Mountain Lion) : 65 000 dollars
- Plug-ins dans Internet Explorer 9 sur Windows :
- Adobe Reader XI : 70 000 dollars
- Adobe Flash : 70 000 dollars
- Java : 20 000 dollars
Les sommes sont censées représenter le degré de difficulté de chaque épreuve. On remarque donc que les deux plus grosses récompenses concernent Chrome sous Windows 7 et Internet Explorer 10 sous Windows 8. À l’inverse, la plus petite somme est pour Java, ce qui n’étonnera pas ceux qui ont suivi la longue série d’actualités sur les failles à répétition de cet environnement multiplateformes.
Internet Explorer 10 et Chrome tombés au combat
Les évènements marquants concernent donc les butineurs de Microsoft et Google. C’est notamment le cas d’Internet Explorer 10 sur Windows 8, du fait de sa relative nouveauté sur le marché. L’équipe qui en a percé les défenses est française : la société de sécurité Vupen. Il a fallu passer les défenses du navigateur mais également celles du système, ces dernières étant nombreuses avec notamment l’ASLR complet (Address Space Layout Randomization), qui change d’emplacement mémoire les composants importants d’une fois sur l’autre.
Pour y parvenir, l’équipe a utilisé en fait un assemblage de plusieurs vulnérabilités 0day. Autrement dit, des failles dont les experts étaient au courant, qui pouvaient être exploitées et dont Microsoft ne connaissait pas l’existence. Deux brèches en particulier ont été utilisées sur une Surface Pro pour qu’un code arbitraire soit exécuté en dehors de la sandbox, c’est-à-dire l’espace mémoire isolé dans lequel sont normalement cantonnées les instructions. On notera que la démonstration a été réalisée le premier jour et qu’elle a permis la prise de contrôle de la machine.
Chrome est également tombé dès la première journée. Comme pour Internet Explorer, il s’agit d’une synergie de plusieurs failles pour percer les défenses. Une technique de plus en plus utilisée d’ailleurs. Sur son blog, l’équipe de MWR Labs explique que l’exploitation peut se faire via une page web. L’exécution de code peut alors se faire, là encore, en-dehors de la sandbox du navigateur. L’élévation des privilèges pour le code se fait pour sa part au travers d’une faille dans le noyau.
Seul Safari reste dans la course
Le concours n'est pas terminé puisqu'il reste encore la journée d'aujourd'hui pour abattre le dernier navigateur encore en lice. Car si Internet Explorer 10 et Chrome ont été vaincus, il en est de même pour Firefox, via Vupen à nouveau. Seul Safari reste donc dans la course pour l’instant. Toutefois, même s'il reste une journée, les organisateurs indiquent qu'aucune démonstration n'est prévue pour le navigateur d'Apple. Ils ne semblent d'ailleurs pas comprendre pourquoi : trop complexe ? Récompense pas assez intéressante ? Manque d'intérêt ? De fait, Safari pourrait bien être vainqueur, mais sans avoir mené une seule bataille.
Du côté des plug-ins, tous ont été vaincus, et notamment Java, qui a fait l'objet de quatre démonstrations séparées et toutes réussies, dont une encore une fois par les français de Vupen.
On rappellera que le concours est particulièrement important pour les éditeurs. Chaque fois qu’un navigateur tombe au combat, les auteurs de l’attaque fournissent tous les détails aux développeurs. Il s’agit d’une règle du Pwn2Own et y manquer empêche de toucher la récompense. Notez en outre que Chrome et Firefox ont déjà été mis à jour pour tenir compte des corrections.
Rendez-vous donc les prochains jours pour savoir si les quelques compétiteurs en lice réussiront à s’en sortir indemnes.
Commentaires (56)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 08/03/2013 à 10h27
Seul Safari reste donc dans la course pour l’instant
Il n’est pas question d’Opera ici ?
Le 08/03/2013 à 10h29
Le 08/03/2013 à 10h30
Merci
" />
Le 08/03/2013 à 10h31
Le 08/03/2013 à 10h36
Tiens Georges Hotz était de la partie.
" />
En tout cas Vupen font un massacre.
Le 08/03/2013 à 10h36
Le 08/03/2013 à 10h37
Pour Firefox, la faille est déjà corrigée. Ils ont été rapide sur le coup.
Twitter
Le 08/03/2013 à 10h40
Le 08/03/2013 à 10h47
Firefox et Safari sont considérés plus faciles à faire tomber ? Donc moins sécurisés que Chrome et IE10 ?
" />
Comment ils décrètent ça en fait ?
Le 08/03/2013 à 10h51
N’empêche quand on connaît la politique de Vupen, c’est pas très surprenant : ne pas déclarer les failles aux éditeurs, et les vendre au plus offrant. Quelle belle mentalité !
Le 08/03/2013 à 10h51
Le 08/03/2013 à 10h54
Le 08/03/2013 à 10h56
Le 08/03/2013 à 10h57
Le 08/03/2013 à 10h58
Le 08/03/2013 à 10h58
Vupen : un peu des marchands d’armes virtuels :/
Le 08/03/2013 à 11h12
Le 08/03/2013 à 11h15
Il y a les temps qu’on mis ses équipes ou personne seul , pour faire tomber les navigateurs ?
Le 08/03/2013 à 11h19
Le 08/03/2013 à 11h23
En effet si IE et Chrome sont considérés comme plus sûr c’est parce qu’ils possèdent une sandbox pouvant limitée pas mal de failles mais bon là pour le coup elles sont trouées ^^ D’ailleurs est ce que la sandbox de IE10 (en mode sécurité avancée) est la même que celle des apps WinRT ?
Le 08/03/2013 à 11h25
@Elwyns c’est difficile à estimer car il y a déjà un travail de fait en amont du concours (surtout que là ils jouent sur plusieurs failles différents pour arriver à leur fin)
Le 08/03/2013 à 11h54
le jour ou ils développeront un navigateur sans failles je serait déjà mort.
" />
Le 08/03/2013 à 11h56
Le 08/03/2013 à 12h04
Le 08/03/2013 à 12h30
Ce qui aurait été intéressant est qu’ils testent la même chose sous Linux pour voir s’ils arrivent à faire tourner du code arbitraire, et avec quel niveau de privilèges, à partir d’un navigateur.
Le code noyau étant ouvert, a priori les failles potentielles sont plus facilement repérées/corrigées.
Le 08/03/2013 à 13h02
Le 08/03/2013 à 13h05
Huhu… ce qui est marrant, c’est qu’il y a encore des gens pour douter des passoires de nos navigateurs… ça me fait doucement rigoler…
" />
Et encore, ce genre de conf… n’est qu’un petit aperçu…
La morale: malgré la complexité malsain de la tonne de mécanisme de sécurisation, cela n’arrête tout bonnement… rien. C’est même pire, c’est elle qui amène des failles…
Dans la sécurité des softs, il faut aussi faire des efforts sur l’abaissement de la complexité/taille de la stack logicielle dans son ensemble. Par exemple, la complexité/taille d’un renderer www moderne… est juste du foutage de gueule.
Ça à cause du javascript et du layout css.
Le 08/03/2013 à 13h08
Le 08/03/2013 à 13h08
Le 08/03/2013 à 13h13
Le 08/03/2013 à 13h20
Le 08/03/2013 à 13h23
Chapeau à Vupen qui se fait remarquer à chaque fois.
Le 08/03/2013 à 16h52
butineurs
LOL
(ceci était le commentaire constructif du jour, merci de votre attention)
Le 08/03/2013 à 18h36
Surtout la différence avec les éditions précédentes c’est que Safari n’inclut plus aucun plugin, et c’était des portes d’entrée de luxe pour les hackers
c’est surtout chrome qui a souvent été hacké à cause de flash
lors des précédentes éditions, Charlie Miller exploitait uniquement des failles de webkit et osx.
mais depuis deux ans il a déclaré qu’il ne participait plus au concours p2own à cause des changements de règle, et ce malgré le fait qu’il possédait déjà un exploit fonctionnel qui lui aurait permis de gagner le concours.
Le 09/03/2013 à 00h32
utiliser un de ces navigateurs internet est clairement un défaut de sécurité, selon la loi très intelligente, vous êtes donc responsable de toute usurpation d’IP pour faire des actions illégales sur internet.
" />
Le 10/03/2013 à 14h44
Java, qui a fait l’objet de quatre démonstrations séparées et toutes réussies
C’est bon c’est bon, arrêtez, on avait dit une ça suffit, pitié :(
Le 08/03/2013 à 10h22
Java : 20 000 dollars
Java trop facile
Le 08/03/2013 à 10h22
Les sommes sont censées représenter le degré de difficulté de chaque épreuve.
Comme par hasard, c’est Java qui a la plus petite dotation
EDIT : Grillé
Du coup question : ce concours s’attaque-t-il aussi aux versions mobiles de ces navigateurs ?
Le 08/03/2013 à 10h24
Le 08/03/2013 à 10h27
Sont où les chinois du FBI ?
" />
Le 08/03/2013 à 13h25
Le 08/03/2013 à 13h26
Bordel, 20000$ pour Java.
" />
Dire que j’ai vendu il y a peu une faille Java avec exploit fonctionnel pour une fraction de ça.
Le 08/03/2013 à 13h29
Le 08/03/2013 à 13h40
Dans quel mode était IE10 ? Modern UI ou Bureau ? Car en bureau, la sécurité est plus basse (même si elle peut être forcée au même niveau qu’en Modern UI).
Le 08/03/2013 à 13h51
Le 08/03/2013 à 14h00
Le 08/03/2013 à 14h20
20 000 dollars pour Java c’est pas plutôt pour réussir a faire fonctionner le plugin sans planter le navigateur, et non l’inverse ?
" />
Le 08/03/2013 à 14h44
Dans la sécurité des softs, il faut aussi faire des efforts sur l’abaissement de la complexité/taille de la stack logicielle dans son ensemble. Par exemple, la complexité/taille d’un renderer www moderne… est juste du foutage de gueule.
ça ne changerait pas grand chose. Même si on arrivait à diviser par 3 la surface d’exposition en sacrifiant des tas de fonctionnalités, au final il resterait toujours suffisamment de failles pour rendre possible le fait de trouver de nouvelles failles 0day.
c’est donc sur la sécurité des sandbox et des protections mémoire qu’il faut se concentrer.
une autre solution serait de supprimer tout bonnement javascript (et les plugins comme flash qui permettent l’exécution de scripts).
sans possibilité de faire du script, pas de possibilité de contourner ASLR et DEP.
ça ferait pas plaisir aux webmasters, mais un web sans javascript serait bénéfique pour les utilisateurs: chargements plus rapides, meilleure autonomie sur batterie, moins de risque de sécurité.
Le 08/03/2013 à 14h54
D’ailleurs est ce que la sandbox de IE10 (en mode sécurité avancée) est la même que celle des apps WinRT ?
oui, c’est la même (appcontainer).
par contre je n’ai pas vu la confirmation qu’il s’agit bien de la nouvelle sandbox qui a été percée (seule l’ancienne est active par défaut sur IE10 desktop). Mais bon je présume que c’est le cas.
Ce qui aurait été intéressant est qu’ils testent la même chose sous Linux pour voir s’ils arrivent à faire tourner du code arbitraire, et avec quel niveau de privilèges, à partir d’un navigateur.
pour Firefox, pas besoin d’attaque noyau puisqu’il n’y a pas de sandbox.
donc l’attaque de Firefox doit fonctionner aussi sous linux/osx
pour chrome, il faut trouver un autre moyen de contourner la sandbox, mais cela n’a rien d’impossible.
rien que l’an dernier a plusieurs reprises sans exploiter de faille noyau des hackers ont réussi à sortir de la sandbox de chrome grâce à une faille dans le process broker.
Le code noyau étant ouvert, a priori les failles potentielles sont plus facilement repérées/corrigées.
webkit aussi est ouvert et pourtant on y trouve plein de failles.
tout ça c’est juste un mythe.
il n’y a aucune réalité technique qui ferait que les failles sont plus facile à trouver et à éliminer dans un projet open source.
Le 08/03/2013 à 15h05
…qu’aucune démonstration n’est prévue pour le navigateur d’Apple. Ils ne semblent d’ailleurs pas comprendre pourquoi : trop complexe ? Récompense pas assez intéressante ? Manque d’intérêt ? De fait, Safari pourrait bien être vainqueur, mais sans avoir mené une seule bataille.
Charlie Miller ne participe hélas plus à ce concours à cause de l’obligation de dévoiler les failles utilisées (en vigueur depuis deux ans). C’est un des rares hackers qui s’intéresse à la sécurité d’osx.
safari en lui même n’offre pas une sécurité supérieure, au contraire il a beaucoup de failles en commun avec chrome à cause de l’utilisation de webkit.
mais évidemment l’exploitation de la sandbox de safari/osx est différente de celle de chrome (cette partie de l’exploit est totalement différente).
citation intéressante d’un membre de vupen:
“Chrome is probably the most hard to attack because of the sandbox. The weakness in Chrome is Webkit and the strength is the sandbox. Probably one of the reasons Chrome is so secure is that the Google guys don’t just fix vulnerabilities but they’re proactive in fixing techniques and sandbox bypasses.”
Le 08/03/2013 à 15h09
Le 08/03/2013 à 15h32
Le 08/03/2013 à 15h38
Le 08/03/2013 à 16h04
Bien sûr que si.
Il existe des outils d’analyse du code, et n’importe qui d’extérieur au projet peut les utiliser.
La faille use-after-free de Firefox trouvée par Vupen en est un exemple parfait.
les hackers n’utilisent en général pas d’outil d’analyse de code vu que ce genre d’outil est déjà utilisé par Microsoft, Mozilla, Google, adobe,… avant la diffusion de leur produit. Je doute fort qu’ils laissent des failles qui pourraient être trouvées avec ce genre d’outil aussi “simplement”.
les failles sont principalement trouvées grâce à des outils de fuzzing qui fonctionnent grâce au code compilé, en exécution. Le code source n’est absolument pas nécessaire pour trouver des failles (et il ne rend pas le travail plus simple non plus).
Le 08/03/2013 à 16h16
Si c’est pour le memory disclosure => certes la grande majorité est exécutée grâce à du script quel qu’il soit, mais ça n’empêche pas de le récupérer d’une autre manière.
Du coup, tu peux détailler à quoi tu pensais exactement
il y a peut être un risque théorique, mais je n’ai jamais vu d’exploit arrivant à contourner ASLR et DEP sans utiliser de JS ou de plugin capable d’exécuter du code
même si en théorie ça reste possible, un tel exploit devrait rester exceptionnel. Là actuellement malgré aslr/dep et d’autres protections mémoire intégrées à IE/Chrome, les hackers arrivent toujours après plusieurs mois de travail à contourner ces protections.
ça leur rend la vie plus difficile, heureusement, mais ça ne réduit plus le risque autant qu’on ne le pensait il y a encore 4ans.
mais bon ce débat n’a guère d’intérêt puisque de toutes façons javascript est là pour rester.
Le 08/03/2013 à 16h38
De fait, Safari pourrait bien être vainqueur, mais sans avoir mené une seule bataille.
En même temps si aucun hacker n’a trouvé de faille ils vont pas venir faire une tentative qui va échouer devant tout le monde hein, faut rester logique
Ça prouve que dalle
Surtout la différence avec les éditions précédentes c’est que Safari n’inclut plus aucun plugin, et c’était des portes d’entrée de luxe pour les hackers.