+ Répondre à la discussion Actualité déjà publiée
  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Consultant
    Inscrit en
    juillet 2013
    Messages
    1 329
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : Côte d'Ivoire

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

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 329
    Points : 36 202
    Points
    36 202
    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 ?
    Cdlt!
    M.K

  2. #2
    Membre à l'essai
    Homme Profil pro
    Développeur Web
    Inscrit en
    juin 2015
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : juin 2015
    Messages : 14
    Points : 20
    Points
    20

    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 du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2015
    Messages
    17
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : février 2015
    Messages : 17
    Points : 42
    Points
    42

    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
    Inscrit en
    avril 2013
    Messages
    1 352
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Seine et Marne (Île de France)

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

    Informations forums :
    Inscription : avril 2013
    Messages : 1 352
    Points : 4 492
    Points
    4 492
    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"

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

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2012
    Messages : 1 659
    Points : 4 193
    Points
    4 193

    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 éclairé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    465
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    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 : 465
    Points : 726
    Points
    726

    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
    248
    Détails du profil
    Informations personnelles :
    Âge : 29
    Localisation : France

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

    Informations forums :
    Inscription : octobre 2009
    Messages : 248
    Points : 754
    Points
    754

    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, 00h15
  2. Réponses: 0
    Dernier message: 15/11/2010, 11h33
  3. appeler une javascript toutes les 5seconde?
    Par amine_en_france dans le forum JavaScript
    Réponses: 9
    Dernier message: 03/12/2007, 12h11
  4. Réponses: 2
    Dernier message: 09/03/2007, 16h52
  5. Réponses: 11
    Dernier message: 06/09/2006, 12h48

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