Lors de l’évènement MobilePwn2Own de la conférence PacSec qui se tenait à Tokyo, un chercheur a réussi à prendre le contrôle d’un appareil sous Android 6.0 en exploitant une unique faille. Le découvreur a indiqué que la brèche, qui s’appuie sur JavaScript, peut facilement être exploitée sur tout type d’appareil.
En fin de semaine dernière avait lieu la conférence PacSec à Tokyo. À cette occasion, des chercheurs étaient réunis pour l’évènement MobilePwn2Own qui, comme pour Pwn2Own, a pour but de chercher et exploiter des failles pour faire la démonstration d’une prise de contrôle d’appareil. La différence avec l’édition « classique » est évidemment qu’il concerne ici les plateformes mobiles. Et malheureusement pour Android, une importante faille dans Chrome permet d’exécuter du code arbitraire à distance.
Une faille 0-day dans la machine virtuelle JavaScript
Guang Gong, chercheur en sécurité pour la société Quihoo 360, a particulièrement marqué les esprits en prenant le contrôle d’un Nexus 6 de Google, équipé du dernier Android 6.0 alias Marshmallow. Il a pu installer à distance une application choisie arbitrairement (en l’occurrence BMX Bike), donc sans toucher à l’appareil. Pour ce faire, il s’est servi d’une faille résidant dans Chrome, plus particulièrement dans son moteur Javascript.
Comme l’indique à The Register l’organisateur de la conférence PacSec, Dragos Ruiu, la démonstration réalisée par Gong était remarquable : « Le plus impressionnant avec cette exploitation est qu’elle se réalise d’une traite. La plupart des gens aujourd’hui doivent exploiter plusieurs failles de sécurité pour obtenir un accès avec privilège et charger des applications sans interactions ». Toujours selon le responsable, la faille peut très facilement être adaptée pour tous les appareils Android où une version récente de Chrome (la dernière est vulnérable) est installée.
Le fait que la vulnérabilité réside dans le moteur JavaScript rend la faille évidemment très facile à exploiter. Il suffit de leurrer l’utilisateur et de l’amener à cliquer sur un lien menant vers un site malveillant. De là, la brèche va permettre de déclencher des actions à distance, jusqu’à l’installation d’une application sans que l’utilisateur ait son mot à dire. La faille permet également d’obtenir les droits root, ce qui permet à l’application d’être aussi malveillante qu’elle le souhaite,
On ne sait cependant pas exactement comment le chercheur s’y prend car s’il a fait la démonstration de sa technique, les détails n’ont pas été publiés et sont réservés aux organisateurs du concours, ainsi qu’à Google bien sûr.
Utiliser un autre navigateur en attendant que Chrome soit mis à jour
Un ingénieur de la firme de Mountain View était sur place, et on peut donc espérer qu’un correctif sera développé rapidement. Même si la faille est critique et particulièrement sérieuse, sa dangerosité reste moindre que celle de Stagefright. Dans les deux cas, les conséquences peuvent être catastrophiques, mais on parle ici d’une faille résidant dans un élément qui peut facilement être mis à jour, puisqu’il appartient à une application dépendant de la boutique Google Play.
En attendant, la solution la plus simple est d’utiliser un autre navigateur. Contrairement à une plateforme comme iOS, les butineurs peuvent embarquer leurs propres moteurs JavaScript et de rendu. Il est donc possible par exemple d’installer Firefox et de ne plus faire appel à la machine virtuelle JavaScript V8 livrée avec Chrome (et en fait souvent préinstallée sur les appareils Android). Cette recommandation est valable pour toutes les versions d’Android dès lors que Chrome est présent.
Commentaires (53)
#1
Être root via un simple lien ?
" />
#2
Chrome, le nouvel IE6 : compatible avec lui-même, gruyère de sécurité, omniprésent, hégémonique.
C’est là qu’on voit que les navigateurs sont créés par des humains : les mêmes fautes sont répétées à conditions de départ identiques. Une autre preuve que l’entropie s’applique au développement de logiciels.
#3
Chrome tourne avec quel utilisateur sous android " /> permettre une élévation de privilège c’est pas du tout normal/possible… sauf s’il tourne avec des droits élevés.
#4
Depuis qu’il a de très gros freezes chez moi, je ne l’utilise plus.
Mais j’avoue bel exploit du chercheur.
#5
Tu sembles oublier pourquoi Chrome a été créé…. tout comme IE a été créé….
Historiquement, IE a été conçu pour prendre la main sur Internet après le raté MSN. Chrome, c’est la même chose pour enfermer et forcer à faire transiter toutes les données de navigation par un outil Google et mieux les collecter !
Ceci explique cela….
#6
ouuh, c’est le genre d’infos a faire tourner auprès des fans de Chrome réfractaire de Firefox ça " />
#7
#8
Je suis passé récemment à Firefox (avec Duckduckgo en moteur de recherche) et je ne le regrette pas :)
#9
de toutes façons, utiliser java…
En plus, je suppose que le hacker qui utiliserait la faille aurait accès à tout si je comprend bien, y compris les informations biométriques?
#10
j’ai jamais dit que Firefox étais parfait, j’ai juste dit que y’a moyen d’embêter quelques fanas, ça aurait été Firefox, j’aurais dit la même chose au profit de Chrome, oui j’aime bien embêter les gens qui sacralise un logiciel ou un constructeur au détriment d’un autre.
#11
JS pas java…
#12
Oui c’est ça.
#13
C’est tout à fait possible.
C’est même ce que cherche à faire la plupart des attaques.
Le but est de trouver le service défaillant qui utilise lui des privilèges élevés pour fonctionner (gestion de la mémoire, driver quelconque etc …) et d’insérer l’exploit dedans.
#14
javascript n’est pas java, aucun rapport.
#15
" />
#16
#17
#18
mouais, aux royaumes des aveugles les borgnes sont rois et font peur facilement.
et j’éviterais de reprendre des articles du ‘Register’ avant d’en savoir plus…
#19
si tu es root, tu as accès à tout. tout.
#20
#21
si la clé de chiffrement est sur le tel, elle est accessible et donc exploitable. si c’est un mot de passe, ça peut être protégé, même de root.
#22
#23
#24
Non juste exécuter n’importe qu’elle soft avec l’utilisateur qui a lancé chrome (ce qui suffit à prendre le contrôle du système).
#25
La faille permet également d’obtenir les droits root, ce qui permet à l’application d’être aussi malveillante qu’elle le souhaite,
Entre installer une application, et lui faire obtenir les droits root il y a une différence, mais là boom " />
#26
De ce que j’en ai compris. C’est la ou iOS est mieux foutu. Les deux technos sont basé sur la “trustzone” d’ARM, mais Apple a pris soin de modifier son implémentation (appelé “Secure Enclave”) pour que cette partie de la mémoire soit uniquement accessible en write/request, et pas en read. Grace à un co-processeur dédié.
Coté Android, ils utilisent l’implémentation classique d’ARM (trustzone), et je n’ai rien trouvé indiquant qu’il était impossible de relire la mémoire.
Plus particulièrement, si j’ai bien compris, la trustzone est une facon de dédier temporairement un core en y mettant un “micro firmware” qui permet de write/request une zone mémoire sécurisé. Mais je pense qu’il serait possible, bien que complexe, d’y pousser un autre firmware permettant la lecture de cette zone sécurisé.
Si certain on des informations plus poussées, je suis à l’écoute.
Sinon concernant la forme de l’article, je trouve l’utilisation du mot 0day à tout va un peu marketeuse. Une faille est par définition 0day avant d’être publiée, donc à part faire dans le sensationnel avec des termes technique “fashion”, ca n’apporte rien de plus que dire que “Une importante faille a été trouvé dans Chrome pour Android”.
Pour être même un peu pointilleux, une faille 0day, c’est un état, donc une fois que la faille est publiée, instantanément, elle n’est plus 0day, donc le titre devient faux. Bref…
#27
La faille ne permet de devenir root.
C’est une fausse interprétation de nextimpact je pense.
Dans le cas contraire je veux bien la source.
#28
Oui mais non en fait.
#29
Moi aussi.
#30
FirefoxOS powa ! " />
Ou pas. " />
#31
#32
Tout ce que j’ai c’est ces recommandations :
http://www.androidpolice.com/2015/10/19/google-lays-out-requirements-for-fingerp…
MUST have all identifiable fingerprint data encrypted and cryptographically authenticated such that they cannot be acquired, read or altered outside of the Trusted Execution Environment (TEE) as documented in the implementation guidelines on the Android Open Source Project site [Resources, 96].
Ce qui semble impliquer que même en Root, les données ne sont pas accessibles.
#33
En tout cas la faille permet d’installer une application tierce sans action utilisateur :
http://www.theregister.co.uk/2015/11/12/mobile_pwn2own/
apres si ce n’est pas la définition exacte de Root … c’est déjà une énorme faille " />
#34
#35
Pour ma part, d’après ce que j’ai compris en lisant de la documentation sur la trustzone, c’est que le cpu est mutualisé entre l’OS et la trustzone (autrement dit, ce n’est pas un coprocesseur dédié, avec sa propre mémoire, etc…). Donc le “core” qui passe en mode secure effectue une sorte de context switch pour décharger un context lié à l’OS et charger son environement securisé. Mais du coup, ou est stocké ce context sécurisé? Jusqu’où est-il mutualisé? Est-ce que le microcode vient de l’OS? ou bien c’est harcodé dans le microprocesseur? Qui l’écrit? Si ca vient de l’OS, qu’est ce qui empèche de charger un microcode qui permet la lecture de la mémoire sécurisé?
Comme je n’ai rien trouvé indiquant que c’est vraiment indépendant, géré “hardwarement” et que même l’OS n’a pas son mot à dire, je pars du principe que ca n’est pas le cas.
#36
Si je comprend bien le concept tu as des espaces mémoire protégés en hardware contre la lecture si le processeur n’est pas en mode “trusted”, et le code exécutable en mode trusted doit être certifié (j’imagine par jeu de certificat).
Aussi, la pire faille serait d’avoir un code certifié “malveillant” ou avec une faille qui permet d’extraire le code, et de modifier l’OS pour modifier le micro-code ?
Mais ce genre d’attaque doit être limitée grâce aux certificats, non ? " />
(et j’admet humblement ne pas y comprendre grand chose " />)
#37
#38
Non être root c’est de pouvoir exécuter du code en tant qu’utilisateur root.
#39
En faite l’implémentation peut varier d’un fabricant à un autre suivant les possibilités offertes par le SoC.
Sur ARM cela repose en effet sur la ARM trust zone et secure boot pour le chargement de firmware.
La zone mémoire utilisé par la trust zone ne peut pas être accessible (lecture et écriture) par Linux (il y a tout de même en générale une zone partagé) de plus cette zone est chiffrée (l’ARM trust zone fonctionne avec la RAM chiffré).
#40
#41
L’escalade de droit est un classique. Car il y a beaucoup de services qui utilisent des droits supérieurs pour s’exécuter. Il suffit de trouver lesquels on peut atteindre via la VM Javascript.
Je penche pour l’allocation mémoire c’est LE grand classique.
#42
Non aucun rapport avec java désolé.
Javascript et Java sont deux langages très très différents.
#43
Oui je sais bien, mais théoriquement ca ne devrait pas être faisable avec un moteur javascript… celà dit la news comporte peut-être une erreur concernant l’élévation de privilège (au moins root)… va falloir attendre que google corrige pour avoir surement plus de précisions.
#44
Bien sur que si, javascript n’est plus interprété comme avant, mais tourne dans une VM maintenant.
Cette VM elle possède des points d’accès avec des droits privilégiés aux ressources du téléphone.
Le hacker n’a qu’a trouver la fonction qui a un soucis. C’est juste une question de temps et de méthode.
#45
#46
#47
Et pourtant si, une VM est un process qui va demander des accès privilégiés sur les ressources de l’appareil.
Regarde les droits d’accès de Chrome sur ton appareil Android.
Tout ce qu’il peut faire, est faisable en exploitant les failles.
#48
#49
Heu Pardon?? Je ne vois vraiment pas les points de comparaisons entre IE6 et Chrome. IE6 ne respectait pas les standard, et chrome le fait…Quand à la sécurité, c’est justement le thème de ce genre de concours Pwn2Own, permettant au éditeurs de corriger ces failles, et Chrome “desktop” est loin d’être le plus touché d’habitude http://www.nextinpact.com/news/93550-pwn2own-tous-navigateurs-sont-encore-tombes…
Au passage, les concours Pown2Own communique habituellement plus sur les “failles” en général, et pas sur un seul navigateur (même si celle ci est quand même énorme). Dommage de ne pas avoir de news sur ce qui a été trouvé (ou pas ) sur les autres….(même Dragos Ruiu ne fait pas de bilan dans sa timeline).
#50
#51
Sans être spécialiste IOS, il me semblait que le jailbreak permettait d’avoir un accès root…je ne vois pas ce qui est incomparable….(car qui dit accès root, dis que tu peux aussi faire n’importe quoi sur l’iphone , le site aurait pu t’installer autre chose qu’un Cydia)
A la base, c’était juste pour te signaler qu’un lien internet permettant de changer ton niveau d’accès , c’est pas si nouveau que ça ….
https://en.wikipedia.org/wiki/IOS_jailbreaking
#52
D’accord mais bon je ne vais pas comparer l’élévation de privilège de Windows et de Linux donc non plus d’iOS et Android.