Des chercheurs découvrent une faille dans la mémoire cache
Permettant à un code JavaScript d'infecter les ordinateurs pourvus de processeurs Intel
Le 2015-04-21 23:00:41, par Olivier Famien, Chroniqueur Actualités
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 ?
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 ?
-
NeckaraInactifBonjour,
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.
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.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.
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.le 22/04/2015 à 9:42 -
vanskjæreMembre avertiJe 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. »
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.le 23/04/2015 à 10:14 -
DarkHylianMembre habitué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
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...le 23/04/2015 à 14:39 -
BufferBobExpert éminentdu 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 ?le 22/04/2015 à 18:31 -
RyzenOCInactifJ'suis tranquille, mon processeur est un amdle 22/04/2015 à 16:54
-
quicky2000Membre actifJ ai lu le papier et franchement le resume de l info est tres trompeur. A aucun moment ils ne disent qu ils arrivent a avoir acces au contenu de la memoire cache. Ils savent juste si quelqu un d autre l a utilise entre temps en se basant sur le temps mis pour obtenir l acces mais les donnees qu ils lisent sont bien les leur..
La partie surveillance des interactions de l utilisateur avec la souris et le reseau sont aussi tres limites. cela leur permet juste de savoir qu il y a une activite mais en aucun cas de savoir ce qui se passe reellement.
En revanche ce que j ai trouve beaucoup plus bluffant c est la partie de l article qui explique comment un mouchard local peut arriver a transmettre des infos indirectement au code javascript en generant des caches miss.
Bref il vaut bien mieux lire l article source de l information que le resume si l on veut comprendrele 30/04/2015 à 16:48 -
JavaScript n'est décidément pas un processus de type machine virtuelle au niveau du navigateur ?le 22/04/2015 à 19:19
-
RyzenOCInactifPuisque 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.le 22/04/2015 à 20:00 -
quicky2000Membre actifIl n y a pas de vrai dump de trame ou de mouvement de souris. il sait juste qu il y a une activite souris ou reseau mais sans details
En fait la chose la plus applicable qu ils indiquent c est d utiliser le profilage pour faire passer des infos entre un mouchard situe sur la machine et le code javascript : le mouchard local genere des patterns d acces memoire que le javascript analyse. le pattern sert a encoder de l infole 30/04/2015 à 16:58 -
JipétéExpert éminent séniorOn est bien d'accord. Sauf que pour récupérer des données dans un cache, à moins de poser une sonde numérique étudiée pour sur les composants du cache pour pouvoir intervenir sur son mécanisme, je ne vois pas trop comment faire autrement.
Un peu comme les calculos d'il y a 50 ans, qui avaient une clé "run/halt" qui permettait d'arrêter l'horloge et donc figer la machine pour pouvoir la dépanner à l'oscilloscope.
Voir le point précédent : les données sont dans le cache ; pour les en extraire il faut autopsier l'engin, et sans couper le courant, donc sondes partout, il me semble.
Vi, mais comme tu le dis, pour dealer avec la mémoire physique il existe des instructions : tu peux la peeker et la poker. Le cache, non. Pour y accéder il faudrait prendre le contrôle des lignes hardware qui le pilotent, et tout ce genre de choses, en gros une usine à gaz posée à côté d'une machine deskop et avec plein de fils qui vont de l'une à l'autre, pas très discret
Un dernier point (je suis un peu déconnecté du hard actuel) : le cache dont on parle, il est intégré dans le processeur, depuis des années, non ? (j'ai le souvenir de barrettes à rajouter sur les cartes-mères qui supportaient les... 486 !) Alors pour aller intervenir dans le proc pour en sortir les données cachées, euh...
Sinon, vi, les rootkits et tout ce genre de choses, à une époque je lisais des choses là-dessus, y avait des magazines papier, on jouait à coder des exploits, des fois ça fonctionnait des fois on mettait la machine en vrac (toujours les miennes, jamais à autrui, jamais à l'extérieur), on rigolait bien !
Citations :
Les caches se sont rapprochés progressivement du die du processeur à mesure que la finesse de gravure diminuait et permettait de placer plus de transistors sur le die. Initialement la mémoire cache se trouvait sur la carte mère.Et vu que notre processeur ne peut pas gérer lui-même le cache, on se doute bien que notre cache se "gère tout seul" : il possède un ou plusieurs circuits électroniques conçus pour gérer le cache automatiquement.le 01/05/2015 à 22:57