Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 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.
8  1 
Avatar de vanskjære
Membre averti https://www.developpez.com
Le 23/04/2015 à 10:14
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.
7  0 
Avatar de DarkHylian
Membre habitué https://www.developpez.com
Le 23/04/2015 à 14:39
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...
6  1 
Avatar de BufferBob
Expert éminent https://www.developpez.com
Le 22/04/2015 à 18:31
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 ?
4  0 
Avatar de RyzenOC
Inactif https://www.developpez.com
Le 22/04/2015 à 16:54
J'suis tranquille, mon processeur est un amd
2  0 
Avatar de quicky2000
Membre habitué https://www.developpez.com
Le 30/04/2015 à 16:48
J 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 comprendre
2  0 
Avatar de BufferBob
Expert éminent https://www.developpez.com
Le 02/05/2015 à 3:17
Citation Envoyé par Jipété Voir le message
On 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.
ben c'est tout le propos du pdf lié à l'article en fait, tu devrais peut-être y jeter un oeil

extrait :
"This allows an attacker to craft a “spy” process which can measure and make inferences about the internal state of a secure process through their shared use of the cache.
First identified by Hu in 1992, several results have shown how the cache side-channel can be used to recover AES keys, RSA keys, and even allow one virtual machine to compromise another virtual machine running on the same host."
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.
si tu connais le principe des injections sql en aveugle, c'est un peu le même principe, on ne lit pas l'information directement, on se contente d'accéder à toute la panoplie d'informations qu'on sait avoir mis en cache, et on mesure leurs temps d'accès respectifs, évidement et de ce que j'ai compris il ne s'agit pas simplement de faire un time() avant/après, il y a derrière tout un algo/une méthode permettant d'affiner le résultat
(ps: quand je parlais de la mémoire physique c'était par opposition à la mémoire virtuelle, gérée par le noyau !)

le cache dont on parle, il est intégré dans le processeur, depuis des années, non ? (...) Alors pour aller intervenir dans le proc pour en sortir les données cachées, euh...
oui oui, c'est du cache processeur dont il est question

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 !
eh ben crois le ou non mais ça a sacrément évolué depuis les stack overflows de papa et les rootkits qui se contentaient de remplacer quelques binaires comme ps et netstat, en l’occurrence en évoquant les techniques de rootkit hyperviseur je faisais notamment référence à des choses comme Blue Pill qui date pourtant déjà de 10 ans en arrière
2  0 
Avatar de
https://www.developpez.com
Le 22/04/2015 à 19:19
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 ?
1  0 
Avatar de RyzenOC
Inactif https://www.developpez.com
Le 22/04/2015 à 20:00
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.
2  1 
Avatar de quicky2000
Membre habitué https://www.developpez.com
Le 30/04/2015 à 16:58
Citation Envoyé par transgohan Voir le message
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.
Il 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 info
1  0