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)
#1
Java : 20 000 dollars
Java trop facile
#2
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 ?
#3
#4
Sont où les chinois du FBI ?
" />
#5
Seul Safari reste donc dans la course pour l’instant
Il n’est pas question d’Opera ici ?
#6
#7
Merci
" />
#8
#9
Tiens Georges Hotz était de la partie.
" />
En tout cas Vupen font un massacre.
#10
#11
Pour Firefox, la faille est déjà corrigée. Ils ont été rapide sur le coup.
https://twitter.com/VUPEN/status/309867285219262464
#12
#13
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 ?
#14
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é !
#15
#16
#17
#18
#19
#20
Vupen : un peu des marchands d’armes virtuels :/
#21
#22
Il y a les temps qu’on mis ses équipes ou personne seul , pour faire tomber les navigateurs ?
#23
#24
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 ?
#25
@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)
#26
le jour ou ils développeront un navigateur sans failles je serait déjà mort.
" />
#27
#28
#29
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.
#30
#31
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.
#32
#33
#34
#35
#36
Chapeau à Vupen qui se fait remarquer à chaque fois.
#37
#38
Bordel, 20000$ pour Java.
" />
Dire que j’ai vendu il y a peu une faille Java avec exploit fonctionnel pour une fraction de ça.
#39
#40
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).
#41
#42
#43
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 ?
" />
#44
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é.
#45
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.
#46
…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.”
#47
#48
#49
#50
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).
#51
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.
#52
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.
#53
butineurs
LOL
(ceci était le commentaire constructif du jour, merci de votre attention)
#54
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.
#55
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.
" />
#56
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é :(