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 2017-02-16 18:25:25, 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 ?
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 ?
-
TiranusKBXExpert confirmé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"le 17/02/2017 à 4:30
-
poma88Membre régulierJe fais du JS tous les jours et j'ai rien compris mais je dois pas etre le seulle 16/02/2017 à 21:44
-
sitexwMembre régulierPour 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 ?le 17/02/2017 à 0:17 -
IradrilleExpert confirmé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é.le 17/02/2017 à 7:10 -
abriotdeMembre chevronné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...le 17/02/2017 à 15:05 -
BeanuxMembre éclairéSur Vusec en source de l'article: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é.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.
La suite décrit ce qu'ils en font et comment exploiter ces infos.le 17/02/2017 à 16:41