Une attaque JavaScript ciblant les unités de gestion de mémoire permet de contourner la protection ASLR
Sur au moins 22 microarchitectures de CPU

Le , par Michael Guilloux, Chroniqueur Actualités
Cinq chercheurs de l'Université de Vrije aux Pays-Bas ont mis en place une attaque via JavaScript capable de contourner la protection ASLR sur au moins 22 microarchitectures de processeur de fournisseurs tels que Intel, AMD, ARM, Allwinner, Nvidia et bien d'autres.

L’Address Space Layout Randomization (ASLR) ou distribution aléatoire de l'espace d'adressage est un mécanisme de protection de la mémoire déployé avec tous les principaux systèmes d'exploitation. Il s'agit en quelque sorte d'une première ligne de défense contre les attaquants ciblant les internautes. L'ASLR rend en effet aléatoire l'emplacement du code et des données d'une application dans l'espace d'adressage virtuel afin de rendre plus difficile pour les attaquants de voler ou manipuler les données ou réutiliser le code afin de compromettre l'application.

L'attaque mise au point par les chercheurs, baptisée ASLR⊕Cache ou AnC, se concentre sur l'unité de gestion de mémoire (MMU pour memory management unit), un composant de nombreuses microarchitectures de CPU, chargé d'améliorer les performances des opérations de gestion de cache.

Une unité de gestion mémoire permet de contrôler les accès d'un processeur à la mémoire de l'ordinateur dans lequel elle est placée. Son utilisation la plus courante et connue est la protection de plages mémoire. Un programme donné ne doit pas pouvoir accéder (en lecture ou écriture) à la mémoire utilisée par un autre programme, voire par le système d'exploitation lui-même. D'une manière simple, chaque programme exécuté par le système d'exploitation se voit attribuer une zone mémoire protégée, dans laquelle aucun autre programme ne peut écrire. Ce principe de protection mémoire est la caractéristique la plus cruciale pour bénéficier d'un système d'exploitation stable.

« L'unité de gestion de mémoire (MMU) des processeurs modernes utilise la hiérarchie de cache du processeur afin d'améliorer la performance des déplacements de tables de pages. Ceci est fondamental pour l'exécution efficace du code dans les processeurs modernes », expliquent les chercheurs. « Malheureusement, cette hiérarchie de cache est également partagée par des applications non fiables, telles que du code JavaScript exécuté dans le navigateur », ajoutent-ils. Cela signifie qu'il est possible pour des attaquants d'envoyer du code JavaScript malveillant ciblant spécifiquement cet espace mémoire partagé et tenter de lire son contenu. C'est d'ailleurs ce qu'ont fait les chercheurs en mettant au point une attaque par canal auxiliaire, et plus précisément, une attaque de cache EVICT+TIME.

Dans le domaine de la sécurité informatique, une attaque par canal auxiliaire (Side channel attack) désigne une attaque informatique qui, sans remettre en cause la robustesse théorique des méthodes et procédures de sécurité, recherche et exploite des failles dans leur implémentation, logicielle ou matérielle. La technique de l’EVICT+TIME fait partie des méthodes d'attaque par canal auxiliaire, en particulier, celles qui visent les caches L1 et L2 et qui se basent que sur la mesure de leur activité.

Cette attaque AnC peut contourner la protection ASLR et permettre à l'attaquant de lire des portions de la mémoire de l'ordinateur, qu'il pourrait ensuite utiliser pour lancer des exploits plus complexes et augmenter l'accès à l'ensemble du système d'exploitation. En contournant ce mécanisme de protection, un attaquant va savoir où le code s'exécute et préparer une attaque qui cible la même zone de la mémoire, pour voler des informations sensibles stockées dans la mémoire du PC.

Les chercheurs ont testé avec succès les attaques JavaScript AnC via Chrome et Firefox sur 22 modèles de processeurs et microarchitectures, même en dépit de plusieurs protections intégrées à ces navigateurs.

Il faut préciser que d'autres microarchitectures pourraient également être vulnérables, car toutes n'ont pas été testées. Les chercheurs s'inquiètent encore du fait que ces attaques AnC peuvent être utilisées pour redonner vie à des attaques de cache que les fournisseurs pensaient avoir atténuées. La seule façon pour les utilisateurs de se protéger contre ces attaques AnC est d'utiliser des extensions comme NoScript qui empêchent l'exécution de code JavaScript non approuvé dans le navigateur.

Sources : VUSec, ASLR on the Line: Practical Cache Attacks on the MMU, Reverse Engineering Hardware Page Table Caches Using Side-Channel Attacks on the MMU

Et vous ?

Qu’en pensez-vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de poma88 poma88 - Membre à l'essai https://www.developpez.com
le 16/02/2017 à 21:44
Je fais du JS tous les jours et j'ai rien compris mais je dois pas etre le seul
Avatar de sitexw sitexw - Membre du Club https://www.developpez.com
le 17/02/2017 à 0:17
Pour ma part, j'ai compris ce qu'il on fait, mais je suis très curieux de voir la tête du JS qui réalise cette exploit. Car malgré les explications, je ne vois pas trop ce qu'il utilise pour y parvenir.
Mais est-ce que c'est comparable à un dépassement de tampon ?
Avatar de TiranusKBX TiranusKBX - Expert confirmé https://www.developpez.com
le 17/02/2017 à 4:30
Sans la publication de l'exploit JS il m'est difficile de juger mais de mon avis personnel il y a un certain nombre de fonction JS qui devraient ne pas être en accès libre, tel que celles de l'objet global "performance"
Avatar de Iradrille Iradrille - Expert confirmé https://www.developpez.com
le 17/02/2017 à 7:10
Citation Envoyé par sitexw Voir le message
Mais est-ce que c'est comparable à un dépassement de tampon ?
Non.

Quand tu veux utiliser une fonction d'une DLL, tu l'appelles via son adresse. L'adresse de la fonction est : adresse de chargement de la DLL (= adresse de base) + offset de la fonction dans la DLL. L'ASLR rend l'adresse de base aléatoire; et donc l'adresse de la fonction aléatoire.
Si tu arrives à faire exécuter ton code à Firefox, tu ne pourra pas trouver les adresses des différentes fonctions système, et donc tu ne peux pas les utiliser.

L'ASLR est là pour rendre les failles (type buffer overflow) plus compliquées à exploiter; mais seul, cet exploit ne présente aucun risque.

Par contre cet un "problème" (enfin, plutôt un choix d'implémentation pour des raisons de performance) coté matériel; ça ne sera jamais corrigé. L'ASLR c'est maintenant du passé.
Avatar de abriotde abriotde - Membre éclairé https://www.developpez.com
le 17/02/2017 à 15:05
Je serais aussi curieux d'en savoir plus parce que j'ai du mal a comprendre comment du code interprété peux effectuer une attaque aussi bas niveau.

Ce que j'ai compris de l' "attaque par canal auxiliaire" c'est une attaque qui comme expliquer exploite une faille d'implémentation. J'ai en tête une faille qui utilisait une propriété physique de la mémoire ou les bits sont juxtaposé et par effet électroniques possédaient une certaine "sensibilité" au trafic électrique voisin.

Et on comprends qu'ici la faille est lié au matériel et plus spécialement à la MMU. J'imagine donc une attaque qui arrive à comprendre via un procédé physique quel est l'adresse voisine et donc la récupérer. Par exemple en comprenant la suite de pointeurs que renvois la MMU...
Avatar de Beanux Beanux - Membre éclairé https://www.developpez.com
le 17/02/2017 à 16:41
Sur Vusec en source de l'article:

We are releasing the native version of AnC as a library to reverse engineer page table caches.
We are not going to release the JavaScript version of AnC in order to protect Internet users from the AnC attack.
However, we predict that any sufficiently advanced adversary can replicate our results in a few weeks with the knowledge from our NDSS’17 paper.
Dans le document décris (2ème lien), par exemple avec performance.now(), selon le temps de réponse, on sait si on est dans le cache du processeur ou dans la mémoire. (bon c'est plus compliqué, vu que les navigateurs ont baissé la précision pour éviter des attaque basé la dessus), mais page 5 tu as une bonne explication de la méthode utilisé.
La suite décrit ce qu'ils en font et comment exploiter ces infos.
Offres d'emploi IT
Ingénieur développement fpga (traitement vidéo) H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY
Ingénieur intégration, validation, qualification du système de drone H/F
Safran - Ile de France - Éragny (95610)
Architecte technique des systèmes d'information H/F
Safran - Ile de France - Évry (91090)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil