Dans le article , le PoC place le code de la victime et de l'attaquant dans le même processus.
Le le code est comme ceci:
if (x < array1_size) y = array2[ array1[x] * 256 ];
Ainsi, l'attaquant et la victime peuvent utiliser le même array2 (car ils sont dans le même code, processus). p >
Mais dans le monde réel, l'attaquant et la victime sont séparés (ce sont des processus différents), ils ne peuvent donc pas partager array2 .
Voici donc ma question, dans dans ce cas, comment l'attaquant peut-il mesurer le temps d'accès à array2 ?
Comment l'attaquant peut-il connaître l'adresse de array2 ?
Je n'ai aucune idée de comment accéder à un attaquant à array2 . Qu'est-ce qui est mal compris ici?
3 Réponses :
Pour attaquer sur les espaces d'adressage sans mémoire partagée, vous avez besoin d'un canal secondaire différent.
Peut-être que le gadget spectre entraînerait une éviction de l'une des lignes de votre tableau, vous devez donc chronométrer des groupes de 8 entrées (qui indexent toutes le même ensemble dans le cache) à la place de 1 à la fois, car l'expulsion aurait pu être n'importe quelle ligne d'un ensemble.
Le code de la question fait référence à Spectre Variant 1, également connu sous le nom de contournement de la vérification des limites .
Qu'est-ce qui est mal compris ici?
Au lieu de penser à la variante 1 en termes de processus victime et de processus de l'attaquant, considérez-la comme un code d'attaquant en bac à sable, dont le but est de lire la mémoire en dehors de son bac à sable.
En d'autres termes, l'attaquant contrôle du code qui s'exécute dans un sandbox logiciel, et ce sandbox logiciel imposerait normalement que chaque domaine de code n'accède qu'à ses propres données. Cependant, Spectre permet au code de l'attaquant de contourner les mises en œuvre de ces sandbox.
Par exemple, l'attaquant fournit du code Javascript pour un site Web malveillant qui sera sandboxé par l'interpréteur Javascript lors de son exécution.
L'interpréteur Javascript vérifierait que le code tel que y = array2 [array1 [x] * 256] ne peut s'exécuter que si x x ) peut effectuer une erreur de prédiction de branche conditionnelle en demandant à son propre code d'entraîner le prédicteur de branche à prendre la branche if (x x sur une valeur désirée, hors limites qui, à cause de Spectre, lui permettra de contourner la vérification des limites du bac à sable et de lire la mémoire à partir de l'espace d'adressage du processus du navigateur.
En résumé, l'attaquant contrôle ici le code d'un site Web (en bac à sable) et Spectre lui permet de lire la mémoire du navigateur où le site est ouvert (ce qui serait normalement empêché par le bac à sable).
Le deuxième exemple utilise eBPF, où l'attaquant injecte et exécute du code à partir du noyau Linux. L'interface eBPF permet aux utilisateurs non privilégiés de le faire. Ce code serait normalement exécuté dans une VM / sandbox dans le noyau qui effectue des vérifications de limites pour empêcher le code chargé de lire une mémoire arbitraire. Cependant, Spectre permet à un attaquant de violer ce sandbox en dehors du sandbox BPF et de fuir de la mémoire arbitraire. En résumé, l'attaquant ici est un utilisateur non privilégié de l'hôte et Spectre leur permet de lire de la mémoire arbitraire sur l'hôte!
Mais dans le monde réel, l'attaquant et la victime sont séparés (ce sont des processus différents)
Pas dans ce cas. Comme expliqué ci-dessus, dans Spectre Variant 1, le "code de la victime" encapsule le "code de l'attaquant" dans le même processus. Le code de l'attaquant serait normalement isolé par la victime à l'aide d'un sandbox logiciel, mais Spectre permet de contourner cela et de lire n'importe quelle mémoire dans l'espace d'adressage de la victime.
Ainsi, if (x
Ou vous voulez dire if (x y = array2 [array1 [x] * 256]; est le code javascript?
Oui, if (x y = array2 [array1 [x] * 256] serait le code de l'attaquant dans l'exemple de l'article.