IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Sécurité Discussion :

Une attaque JavaScript ciblant les unités de gestion de mémoire permet de contourner la protection ASLR


Sujet :

Sécurité

  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    Juillet 2013
    Messages
    2 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Data Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 2 875
    Points : 86 930
    Points
    86 930
    Billets dans le blog
    2
    Par défaut Une attaque JavaScript ciblant les unités de gestion de mémoire permet de contourner la protection ASLR
    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

    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 ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre régulier
    Femme Profil pro
    Architecte réseau
    Inscrit en
    Juin 2015
    Messages
    40
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Afrique Du Sud

    Informations professionnelles :
    Activité : Architecte réseau

    Informations forums :
    Inscription : Juin 2015
    Messages : 40
    Points : 78
    Points
    78
    Par défaut
    Je fais du JS tous les jours et j'ai rien compris mais je dois pas etre le seul

  3. #3
    Membre régulier Avatar de sitexw
    Homme Profil pro
    Développeur Web
    Inscrit en
    Février 2015
    Messages
    44
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Février 2015
    Messages : 44
    Points : 117
    Points
    117
    Par défaut
    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 ?

  4. #4
    Expert confirmé
    Avatar de TiranusKBX
    Homme Profil pro
    Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Inscrit en
    Avril 2013
    Messages
    1 476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2013
    Messages : 1 476
    Points : 4 805
    Points
    4 805
    Billets dans le blog
    6
    Par défaut
    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"
    Rien, je n'ai plus rien de pertinent à ajouter

  5. #5
    Expert confirmé
    Homme Profil pro
    Étudiant
    Inscrit en
    Juin 2012
    Messages
    1 711
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Juin 2012
    Messages : 1 711
    Points : 4 442
    Points
    4 442
    Par défaut
    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é.

  6. #6
    Membre chevronné
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2007
    Messages
    884
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Juillet 2007
    Messages : 884
    Points : 2 018
    Points
    2 018
    Par défaut
    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...
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  7. #7
    Membre éclairé Avatar de Beanux
    Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Octobre 2009
    Messages
    249
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Octobre 2009
    Messages : 249
    Points : 744
    Points
    744
    Par défaut
    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.

Discussions similaires

  1. Réponses: 5
    Dernier message: 02/11/2015, 01h15
  2. Réponses: 0
    Dernier message: 15/11/2010, 12h33
  3. appeler une javascript toutes les 5seconde?
    Par amine_en_france dans le forum Général JavaScript
    Réponses: 9
    Dernier message: 03/12/2007, 13h11
  4. Réponses: 2
    Dernier message: 09/03/2007, 17h52
  5. Réponses: 11
    Dernier message: 06/09/2006, 13h48

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo