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

Actualités Discussion :

Des chercheurs découvrent une faille dans la mémoire cache

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Webmaster
    Inscrit en
    Janvier 2014
    Messages
    1 089
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : Janvier 2014
    Messages : 1 089
    Points : 26 554
    Points
    26 554
    Par défaut Des chercheurs découvrent une faille dans la mémoire cache
    Des chercheurs découvrent une faille dans la mémoire cache
    permettant à un code JavaScript d'infecter les ordinateurs pourvus de processeurs Intel

    Un groupe de chercheurs de l’université de Colombia aux États-Unis vient de découvrir une faille exploitable à partir de la mémoire cache des ordinateurs pourvus de processeurs Intel. Comme le souligne le rapport produit par les chercheurs « contrairement à d’autres travaux de ce genre, cette attaque ne nécessite pas de l’attaquant qu’il installe un logiciel sur la machine de la victime — pour faciliter l’attaque, la victime n’a besoin que de parcourir une page Web non sécurisée avec le contenu contrôlé par l’attaquant ».

    Dans le principe, les attaques side channel ou canal auxiliaire en français permettent aux attaquants d’extraire des données cachées dans des équipements en analysant les signaux physiques tels que la chaleur, la lumière, les radiations … Cela signifie que les attaques ne sont pas menées directement en cherchant une faille logicielle, mais plutôt exploite une faille matérielle peu commune. Il faut également préciser que ce type d’attaques vise généralement à détecter les clés cryptographiques sur un terminal. S’appuyant donc sur les possibilités de faille exploitable à ce niveau, les chercheurs ont réussi non pas à casser une clé de chiffrement, mais à suivre toutes les activités sur l’équipement infecté, en surveillant simplement le cache du processeur avec un algorithme JavaScript conçu au préalable.

    Pour que l’attaque puisse réussir, certaines conditions doivent être réunies. L’ordinateur ciblé doit être pourvu d’un processeur Intel assez récent et le navigateur doit être compatible avec la norme HTML5. Une fois que ces conditions sont remplies et que l’internaute visite une page web contenant le malware dissimulé, par exemple, dans une publicité, le code malicieux se répand sur l’ordinateur de la victime.

    À partir de cette étape, l’attaquant accède à un ensemble d’emplacements de la mémoire. Celui-ci permet de prendre le contrôle de la mémoire cache en y accédant. En utilisant le code dans les emplacements mémoires, la mémoire cache serait contrainte de passer à un état bien défini. L’étape suivante consiste à attendre que l’utilisateur déclenche un évènement avec le clavier ou la souris pour que la personne mal intentionnée sonde le cache à partir des emplacements mémoires qui avaient été créés.

    L’attaquant peut maintenant suivre les faits et gestes de l’utilisateur. Et puisque le dernier niveau de la mémoire cache est partagé avec tous les noyaux du processeur, des utilisateurs, des traitements et des dispositifs de protection, la personne malveillante a accès à l’ensemble des informations systèmes détaillées de la machine infectée.

    Un temps d’accès à cette mémoire assez bas suggère que les données ou le code de l’attaquant sont toujours dans la mémoire cache, tandis qu’un temps d’accès plus élevé présuppose que la mémoire cache est utilisée par les données de la victime, ce qui donne à l’attaquant l’état de l’ordinateur de la victime.

    Les expériences ont été effectuées sur des ordinateurs Intel utilisant des processeurs Ivy Bridge, Sandy Bridge et de familles de processeurs Haswell avec les dernières versions de navigateurs Safari et Firefox sur les systèmes d’exploitation Mac OS Yosemite et Ubuntu 14.04 LTS. Le code malicieux JavaScript de moins de 500 lignes fut capable d’accéder à plus de 25 % de la mémoire cache en mois de 30 secondes. Et vu que les processeurs Intel équipent la majorité des ordinateurs, les chercheurs affirment que les attaques peuvent s’étendre à des millions d’ordinateurs.

    Toutefois, en raison de l’architecture des processeurs AMD, cette attaque ne serait pas applicable à cette plateforme.

    Source : rapport des chercheurs (PDF)

    Et vous ?

    Que pensez-vous de ces attaques ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Expert éminent Avatar de BufferBob
    Profil pro
    responsable R&D vidage de truites
    Inscrit en
    Novembre 2010
    Messages
    3 035
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : responsable R&D vidage de truites

    Informations forums :
    Inscription : Novembre 2010
    Messages : 3 035
    Points : 8 400
    Points
    8 400
    Par défaut
    typiquement le genre d'attaque de haut-vol intéressante pour les cyber-espions, manquerait plus qu'on utilise de plus en plus javascript partout (à tel point qu'il y a pleins de sites qu'on ne peut simplement pas consulter sans avoir javascript activé), que les failles XSS soient encore parmi les failles les plus courantes et qu'on puisse embarquer du javascript dans d'autres supports comme des pdf...

  3. #3
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    Bonjour,

    Personnellement, je n'ai rien compris.
    Ne serait-il pas possible d'avoir un petit schéma ?


    Donc si j'essaye de comprendre, on utilise un code JavaScript pour lire des données "physiques tels que (la chaleur, la lumière, les radiations…)".
    Et on peut à partir de JavaScript accéder à ces données et elles sont suffisantes pour en déduire le contenu du cache ?

    Ensuite, il demande à lire des emplacements mémoires pour forcer la mise à jour du cache et mettre le cache dans un état connus.
    On ne prend donc pas le contrôle de la mémoire cache de manière directe.

    L’étape suivante consiste à attendre que l’utilisateur déclenche un évènement avec le clavier ou la souris pour que la personne mal intentionnée sonde la cache à partir des emplacements mémoires qui avaient été créés.
    Si je comprend bien, c'est là qu'on a une faille ?
    Dans le cache, A = emplacement_de_la_souris.
    On fait des accès mémoire et maintenant A = espace_mémoire_attaquant
    Sauf que A est toujours considéré comme emplacement_de_la_souris, c'est là que ce situe la faille ?

    Donc dès qu'il y a un mouvement de souris, on écrit dans A et pourra être récupéré par l'attaquant vu que c'est espace_mémoire_attaquant.
    Alors pourquoi cette histoire de "attaques side channel ou canal auxiliaire" ? On n'analyse pas de signaux physique ici non ?

    la personne malveillante a accès à l’ensemble des informations systèmes détaillées de la machine infectée.
    À moins que ce soit avec les "informations systèmes détaillées" qu'on récupère les mesures des signaux physiques ?

    Un temps d’accès à cette mémoire assez bas suggère que les données ou le code de l’attaquant sont toujours dans la mémoire cache, tandis qu’un temps d’accès plus élevé présuppose que la mémoire cache est utilisée par les données de la victime, ce qui donne à l’attaquant l’état de l’ordinateur de la victime.
    Quelle mémoire ? Accès pour récupérer quoi ?
    Ne serait-ce pas plutôt le temps d'accès moyen de la mémoire cache ?
    S'il est remplit par les données de l'attaquant, on a beaucoup de cache miss donc il faut rechercher les données en RAM ?


    Bon, je viens juste de me lever, j'ai un peu du mal à tout comprendre.

  4. #4
    Membre extrêmement actif
    Homme Profil pro
    Graphic Programmer
    Inscrit en
    Mars 2006
    Messages
    1 537
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Graphic Programmer
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2006
    Messages : 1 537
    Points : 3 909
    Points
    3 909
    Par défaut
    J'ai rien comprit non plus.

    js n'est t'il pas sencé etre un langage de haut niveau ? comment ce fait t'il qu'on puisse accéder a la mémoire cache du cpu avec un langage de haut niveau ??

  5. #5
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    Juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2013
    Messages : 3 715
    Points : 1 184
    Points
    1 184
    Billets dans le blog
    9
    Par défaut
    J'suis tranquille, mon processeur est un amd

  6. #6
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    26
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2009
    Messages : 26
    Points : 38
    Points
    38
    Par défaut
    Idem je n'ai rien compris, cette étape est un peu magique pour moi:
    À partir de cette étape, l’attaquant accède à un ensemble d’emplacements de la mémoire. Celui-ci permet de prendre le contrôle de la mémoire cache en y accédant. En utilisant le code dans les emplacements mémoires, la mémoire cache serait contrainte de passer à un état bien défini.
    j'espère que quelqu'un de plus éclairé sera en mesure de nous expliquer tout ça. ^^

  7. #7
    Nouveau Candidat au Club
    Homme Profil pro
    Analyse système
    Inscrit en
    Mars 2014
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France

    Informations professionnelles :
    Activité : Analyse système

    Informations forums :
    Inscription : Mars 2014
    Messages : 1
    Points : 1
    Points
    1
    Par défaut
    Je pense qu'un langage soit de haut niveau n’empêche pas d’accéder à la mémoire cache, les instructions du langage seront toujours exécutées par le processeur a un moment et donc passerons à priori par le cache, JS est un langage interprété et donc c'est le navigateur qui transforme le "texte" en instructions, et si on sait comment il fait on doit pouvoir écrire un ensemble de commandes JS qui une fois interprétées donnent un ensemble d'instructions bas niveau accédant au cache...

    Enfin j'imagine, ce n'est pas une affirmation mais une intuition...

  8. #8
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    Janvier 2011
    Messages
    3 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 146
    Points : 9 386
    Points
    9 386
    Par défaut
    J'ai parcouru un peu le pdf mais je n'ai pas tout compris.

    En utilisant une liste chaînée ils mappent une partie du cache à priori. Et ils annoncent qu'il y a un lien entre des accès concurrents en mémoire.
    Si on accède à une adresse A1 l'accès à une adresse A2 (proche ou non je ne comprends pas la relation) entraînera un temps plus important que si l'on n'avait pas accédé à l'adresse A1.
    Le cache L3 étant partagé avec tout le monde on peut donc espionner l'activité de tout ce qui se passe.

    Du coup après ils regardent le temps d'accès à leurs adresses pour obtenir un graph d'utilisation des secteurs de la mémoire.

    Je me suis arrêté au moment où ils expliquent qu'ils dumpent les trames TCP/IP et les mouvements de souris avec des logiciels tierces pour enregistrer les temps et qu'ils font coïncider ces temps avec le graph qu'ils génèrent.
    Cela leur permet de cibler les zones mémoires impactées par ces deux actions.

    Sauf que je ne vois pas trop comment c'est applicable... S'ils n'avaient pas eu leurs logiciels tierces...
    Ils n'auraient eu qu'un graph d'utilisation de la mémoire sans savoir ce qu'il y a derrière....
    Et puis ils se concentrent sur les accès réseau et les déplacements de souris, mais pourquoi un autre process ne travaillerai pas ? (accès disque dur, ect)

    Je n'ai pas poursuivi la lecture qui m'est difficile, mais je ne vois pas grand chose d'applicable/utilisable si ce n'est la relation entre le temps d'accès à une adresse qui indique qu'une autre adresse est accédée.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  9. #9
    MikeRowSoft
    Invité(e)
    Par défaut
    La réponse d'Intel à se sujet s'il vous plait.

  10. #10
    MikeRowSoft
    Invité(e)
    Par défaut
    Citation Envoyé par cuicui78 Voir le message
    js n'est t'il pas sencé etre un langage de haut niveau ? comment ce fait t'il qu'on puisse accéder a la mémoire cache du cpu avec un langage de haut niveau ??
    Oui, cela ne manque pas de pertinence. Surtout si l'OS "s'étale" sur tous les cores, au lieu d'en utiliser un et de se servire des autres sous forme de "coprocesseurs". Le langage et l'OS ont sûrement une profonde "complicité". Le test Microsoft va vraiment être décisif.

  11. #11
    Membre extrêmement actif
    Homme Profil pro
    Graphic Programmer
    Inscrit en
    Mars 2006
    Messages
    1 537
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Graphic Programmer
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2006
    Messages : 1 537
    Points : 3 909
    Points
    3 909
    Par défaut
    ca me rappelle le système tempest.

    Et si c'est donc une technique d'analyse des effets de bords, il va falloir conduire des test sur de très nombreux Systems pour pouvoir reconstituer avec un certain niveau de confiance ce qui se trouve dans le cache et distinguer l'information dans du bruit.

    dans le pdf ils expliquent que pour éviter ce problème, il faudrait que le navigateur demande l'autorisation a l'utilisateur pour que la fonction timer soie utilisée par le site....
    A mon avis c'est intéressant mais pas réellement dangereux, c'est trop expérimental.

  12. #12
    Expert éminent Avatar de BufferBob
    Profil pro
    responsable R&D vidage de truites
    Inscrit en
    Novembre 2010
    Messages
    3 035
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : responsable R&D vidage de truites

    Informations forums :
    Inscription : Novembre 2010
    Messages : 3 035
    Points : 8 400
    Points
    8 400
    Par défaut
    Citation Envoyé par transgohan Voir le message
    J'ai parcouru un peu le pdf mais je n'ai pas tout compris.
    du peu que j'ai compris -ou cherché à comprendre- il s'agit d'une side channel attack qui utilise une méthodologie de type PRIME+PROBE, ce type d'attaques ont très longtemps été du domaine du théorique, et depuis peu on voit fleurir tout un tas d'exploitations pratiques, la page Wikipedia nous informe par ailleurs qu'un certain Serge Vaudenay avait déjà mené une attaque par canal auxiliaire avec succès contre AES, déclenchant ainsi une mise à jour jugée critique à l'époque (de PGP, OpenSSL etc. sous-entendu)

    la description très technique, très poilue, peut être trouvée ici https://www.cs.unc.edu/~reiter/papers/2012/CCS.pdf
    sinon un slide "for dummies" -dont je fais humblement partie- et plus simple à lire ici http://www.cs.unc.edu/~reiter/course...deChannels.pdf

    donc au delà du comment, le propos est pour l'attaquant d'injecter du code javascript qui va s'exécuter en local sur la machine, espionner le cache L3, typiquement à la recherche de la partie privée du certificat du navigateur de la victime par exemple (permettant ainsi de déchiffrer ses communications https)
    les possibilités de javascript permettent ensuite de faire sortir les informations de manière assez discrète, combien de plugins navigateur effectuent des requêtes dont on ignore l'existence sans jamais lever la moindre alerte antivirus ou autre ?
    enfin ça a l'avantage de pas pouvoir être patché (à moins de changer de CPU), de pouvoir être propagé massivement à l'aveuglette comme dans le cas d'une faille XSS, ou au contraire de cibler précisément à travers un fichier PDF spécialement conçu

    c'est très précisément le propos du cyber-arsenal des Etats dont on parle ces temps ci dans les différentes actus, qui n'a toujours pas fait le lien avec la news sur la loi de renseignement ?

  13. #13
    MikeRowSoft
    Invité(e)
    Par défaut
    Citation Envoyé par BufferBob Voir le message
    du peu que j'ai compris -ou cherché à comprendre- il s'agit d'une side channel attack qui utilise une méthodologie de type PRIME+PROBE, ce type d'attaques ont très longtemps été du domaine du théorique, et depuis peu on voit fleurir tout un tas d'exploitations pratiques, la page Wikipedia nous informe par ailleurs qu'un certain Serge Vaudenay avait déjà mené une attaque par canal auxiliaire avec succès contre AES, déclenchant ainsi une mise à jour jugée critique à l'époque (de PGP, OpenSSL etc. sous-entendu)

    la description très technique, très poilue, peut être trouvée ici https://www.cs.unc.edu/~reiter/papers/2012/CCS.pdf
    sinon un slide "for dummies" -dont je fais humblement partie- et plus simple à lire ici http://www.cs.unc.edu/~reiter/course...deChannels.pdf

    donc au delà du comment, le propos est pour l'attaquant d'injecter du code javascript qui va s'exécuter en local sur la machine, espionner le cache L3, typiquement à la recherche de la partie privée du certificat du navigateur de la victime par exemple (permettant ainsi de déchiffrer ses communications https)
    les possibilités de javascript permettent ensuite de faire sortir les informations de manière assez discrète, combien de plugins navigateur effectuent des requêtes dont on ignore l'existence sans jamais lever la moindre alerte antivirus ou autre ?
    enfin ça a l'avantage de pas pouvoir être patché (à moins de changer de CPU), de pouvoir être propagé massivement à l'aveuglette comme dans le cas d'une faille XSS, ou au contraire de cibler précisément à travers un fichier PDF spécialement conçu

    c'est très précisément le propos du cyber-arsenal des Etats dont on parle ces temps ci dans les différentes actus, qui n'a toujours pas fait le lien avec la news sur la loi de renseignement ?
    JavaScript n'est décidément pas un processus de type machine virtuelle au niveau du navigateur ?

  14. #14
    Expert éminent sénior

    Homme Profil pro
    pdg
    Inscrit en
    Juin 2003
    Messages
    5 749
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : Juin 2003
    Messages : 5 749
    Points : 10 666
    Points
    10 666
    Billets dans le blog
    3
    Par défaut
    Cela m'a rendu curieux moi aussi et en creusant un peu j'apprends qu'il s'agit d'une amélioration d'un principe d'attaque qui semble avoir au moins 10 ans. La vidéo suivante explique (à partir de la 5eme minute) le principe général ainsi que son application pour cibler GnuPG:
    https://www.usenix.org/conference/us...entation/yarom

    La faiblesse général qui est exploitée est celle du partage : le speaker conclut en disant que dès qu'on partage quelque chose, on partage en fait beaucoup plus que ce que l'on croit, que ce soit dans un cache processeur ou sur Facebook.

  15. #15
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    Juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2013
    Messages : 3 715
    Points : 1 184
    Points
    1 184
    Billets dans le blog
    9
    Par défaut
    Puisque les navigateurs n'ont pas le même moteur js, j'imagine qu'ils ne sont pas tous contournée.

    De plus, si cette faille s'avère critique, je pense que qu'ils (les fabriquant de navigateurs) nous ferons une maj en 1-2 semaine.

    Pour l'heure, je ne pense pas qu'il faut paniquer et désactiver js.

  16. #16
    MikeRowSoft
    Invité(e)
    Par défaut
    Citation Envoyé par sazearte Voir le message
    Puisque les navigateurs n'ont pas le même moteur js, j'imagine qu'ils ne sont pas tous contournée.

    De plus, si cette faille s'avère critique, je pense que qu'ils (les fabriquant de navigateurs) nous ferons une maj en 1-2 semaine.

    Pour l'heure, je ne pense pas qu'il faut paniquer et désactiver js.
    Les spécialistes en sécurité comme Norton ou ZoneAlarm ou autres vont vraiment adorer faire payer se genre de chose, des navigateurs...
    Ou il va falloir éviter les codes JavaScript comme pour les pubs.
    Le remplacent de JavaScript est déjà là ?

  17. #17
    Membre averti
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2013
    Messages
    106
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Bâtiment

    Informations forums :
    Inscription : Avril 2013
    Messages : 106
    Points : 373
    Points
    373
    Par défaut
    Je rejoins l’avis général qui est : « euh…j’ai pas compris le lien entre la température et le cache mémoire du processeur. »

    Citation Envoyé par sazearte Voir le message
    J'suis tranquille, mon processeur est un amd
    Ca me fait penser au sketch de Gad Elmaleh dans lequel il raconte ce que les enfants rencontre comme énoncé de problème en mathématiques.

    « Si je remplis ma baignoire à 18h30 avec un débit de # dL à la minute et qu’un trou dans la baignoire laisse s’écouler #cL à la minute. Sachant que je bouche la moitié du trou avec mon doigt à 18h38, quel heure la baignoire sera pleine ? »
    -Le père : Et tu as répondu quoi ?
    -l’enfant : Je veux prendre une douche.

  18. #18
    MikeRowSoft
    Invité(e)
    Par défaut
    Citation Envoyé par vanskjære Voir le message
    Je rejoins l’avis général qui est : « euh…j’ai pas compris le lien entre la température et le cache mémoire du processeur. »
    Bienvenue dans le club des gravures de SoC parfaites... Les analyseurs de spectres et les communications exploitant les contrôles de CRC ou autres sont beaucoup plus complexe à "schématiser" à un niveau aussi proche de la "couche matériel registre". Encore un truc pour astronaute ou de responsabilités civiles élevés, voir même militaire.
    Dernière modification par MikeRowSoft ; 23/04/2015 à 14h37.

  19. #19
    Membre habitué
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2013
    Messages
    53
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 53
    Points : 168
    Points
    168
    Par défaut
    De ce que j'ai compris vite fait, en lisant en diagonal le pdf :
    creating an eviction set for one or more relevant cache sets, priming the cache set, triggering the victim operation and finally probing the cache set again
    Le code Javascript effectue des allocations mémoires (ils ont mis en place un procédé très détaillé)
    Chaque allocation occupe un espace mémoire spécifique, normalement en RAM.
    Plus on accède souvent à un ensemble de donnée, plus cet ensemble est susceptible d'être laissé dans le cache L3 du CPU.
    Pour rappel, le L3 est lié à la RAM, tout ce qui est manipulé répétitivement en mémoire se passe dans ce cas en L3 (L2 et L1 successivement selon les besoins).

    Le script après avoir fait ses allocations les libères, en conservant les pointeurs de données qui vont bien.
    Régulièrement, il tente d'y accéder
    Si l'accès est très rapide, il tombe nez à nez avec son propre code d'execution présent dans le cache.
    Si l'accès est plus lent, c'est que le cache L3 a été utilisé en cours par un autre processus -> dans ce cas, on accède à d'autres données que celles prévues par le script (notamment des données utilisateurs voir du code executable)

    (je synthétise tellement que ça peut en être faux)

    ... Ptin, en lisant un peu plus, c'est vachement futé comme technique. Je pensais pas qu'on pouvait aller aussi loin avec du Jscript...

  20. #20
    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 Quel belle faille
    Techniquement ce n'est pas très intéressant de savoir comment elle fonctionne. Il est certains que la sécurité s'améliorant, les ordinateurs et l'informatique se complexifiant, les attaques informatiques sont de plus en plus complexes. Si aujourd'hui il peut apparaître complexe de les exploiter au final un hackeur digne de ce nom (c'est a dire aujourd'hui une organisation professionnel) arrive assez aisément a les exploiter. Cela me rappel le buffer-over flow. Typiquement dans ce genre de cas on risque simplement de faire planter un programme, mais un hackeur sait lancé le programme avec les bon paramètres et le bon contexte pour obtenir bien plus.

    Si Javascript est, un langage de haut niveau, il est néanmoins optimiser pour ne pas rester trop haut niveau. Je m'explique : un langage de haut niveau c'est un langage facile a utiliser et sécurisé par un ensemble de fonctionnalité. Néanmoins un langage de haut niveau est lent et consomme beaucoup de ressources... alors on l'optimise et donc on utilise des "astuces" pour qu'il puisse travailler assez bas niveau. C'est en partie l'intérêt du HTML5 (objet de la faille). Pour résumer jusqu'à IE6 javascrip était de très haut niveau mais très lent (il comportait que des failles de haut niveau), Google l'a optimisé avec Chrome et HTML5 le rends plus puissant et optimisé... Cela le rends aussi plus complexe et donc beaucoup plus difficile à hacker quelques part mais aussi beaucoup plus complexe a sécurisé.

    La faille est réelle même si elle est tout de même encore surtout théorique c'est que la grande majorité des PC utilise des processeur Intel récent (Les PC lâche au bout de 3-5 ans) avec un navigateur récent donc ayant HTML5. D'ailleurs Internet Explorer, Safari, Chrome, Chromium et Firefox ne sont disponible dans leur version à jour qu'avec HTML5 activé par défaut...
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

Discussions similaires

  1. Réponses: 9
    Dernier message: 05/10/2017, 20h40
  2. Des chercheurs trouvent une faille dans l’algorithme RSA
    Par Hinault Romaric dans le forum Sécurité
    Réponses: 12
    Dernier message: 09/12/2016, 10h32
  3. Des chercheurs découvrent plusieurs vulnérabilités dans Windows
    Par Francis Walter dans le forum Sécurité
    Réponses: 0
    Dernier message: 26/02/2014, 10h07
  4. Réponses: 1
    Dernier message: 14/01/2014, 12h31
  5. Des chercheurs découvrent une faille de sécurité critique dans SSL
    Par Hinault Romaric dans le forum Sécurité
    Réponses: 26
    Dernier message: 04/10/2011, 12h04

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