Des chercheurs découvrent une faille dans la mémoire cache
Permettant à un code JavaScript d'infecter les ordinateurs pourvus de processeurs Intel

Le , par Olivier Famien

0PARTAGES

9  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de BufferBob
Expert éminent https://www.developpez.com
Le 22/04/2015 à 8:21
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...
Avatar de Neckara
Expert éminent sénior https://www.developpez.com
Le 22/04/2015 à 9:42
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.
Avatar de Aiekick
Membre extrêmement actif https://www.developpez.com
Le 22/04/2015 à 16:23
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 ??
Avatar de RyzenOC
Inactif https://www.developpez.com
Le 22/04/2015 à 16:54
J'suis tranquille, mon processeur est un amd
Avatar de Le_CuLtO
Nouveau membre du Club https://www.developpez.com
Le 22/04/2015 à 16:56
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. ^^
Avatar de neoarkadia
Nouveau Candidat au Club https://www.developpez.com
Le 22/04/2015 à 17:03
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...
Avatar de transgohan
Expert éminent https://www.developpez.com
Le 22/04/2015 à 17:06
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.
Avatar de
https://www.developpez.com
Le 22/04/2015 à 17:38
La réponse d'Intel à se sujet s'il vous plait.
Avatar de
https://www.developpez.com
Le 22/04/2015 à 17:59
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.
Avatar de Aiekick
Membre extrêmement actif https://www.developpez.com
Le 22/04/2015 à 18:16
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.
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web