Une équipe de chercheurs de plusieurs universités américaines, israéliennes et australiennes a développé trois attaques exécutées sur les navigateurs Web pour extraire des informations sur le contenu du cache du processeur. Une méthode fonctionne dans les navigateurs sans JavaScript, et les deux autres contournent les méthodes de protection existantes contre les attaques par canal secondaire, notamment celles utilisées dans le navigateur Tor et DeterFox. Le code de démonstration des attaques, ainsi que les composants serveur nécessaires aux attaques, sont publiés sur GitHub.
Pour analyser le contenu du cache, toutes les attaques utilisent la méthode Prime+Probe, qui consiste à remplir le cache avec un ensemble standard de valeurs et à détecter les changements en mesurant le temps d'accès à celles-ci lors de leur remplissage. Pour contourner les mécanismes de sécurité présents dans les navigateurs qui interfèrent avec la mesure précise du temps, dans deux options, on fait appel à un serveur DNS ou WebSocket contrôlé par l'attaquant, qui tient un journal de l'heure des requêtes reçues. Dans un mode de réalisation, un temps de réponse DNS fixe est utilisé comme référence temporelle.
Les mesures effectuées à l'aide de serveurs DNS ou WebSocket externes, utilisant un système de classification basé sur l'apprentissage automatique, étaient suffisantes pour prédire les valeurs avec une précision allant jusqu'à 98 % dans le scénario le plus optimal (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.
La première variante de l'attaque DNS Racing utilise une implémentation classique de la méthode Prime+Probe utilisant des tableaux JavaScript. Les différences se résument à l'utilisation d'un minuteur DNS externe et d'un gestionnaire d'erreurs, qui se déclenche lorsqu'une tentative est effectuée pour charger une image à partir d'un domaine inexistant. Un minuteur externe permet une attaque Prime+Probe sur les navigateurs qui limitent ou désactivent complètement l'accès aux minuteurs JavaScript.
Pour un serveur DNS situé sur le même réseau Ethernet, la précision du timer est estimée à environ 2 ms, ce qui est suffisant pour mener une attaque par canal secondaire (à titre de comparaison, la précision du timer JavaScript standard dans le navigateur Tor est réduite à 100 ms). Pour une attaque, le contrôle du serveur DNS n'est pas requis, car le temps d'exécution de l'opération est choisi de manière à ce que le temps de réponse du DNS soit le signe d'une vérification plus précoce (selon que le gestionnaire d'erreurs a été déclenché ou non). plus tôt ou plus tard, une conclusion est tirée sur la rapidité de l'opération de vérification avec le cache) .
La deuxième méthode d'attaque, "String and Sock", vise à contourner les techniques de sécurité qui restreignent l'utilisation de bas niveau des tableaux en JavaScript. Au lieu de tableaux, String et Sock utilisent des opérations sur de très grandes chaînes dont la taille est choisie pour que la variable couvre tout le cache LLC (Cache de dernier niveau). Ensuite, à l'aide de la fonction indexOf(), une petite sous-chaîne est recherchée dans la chaîne, qui est initialement absente dans la chaîne source, c'est-à-dire l'opération de recherche entraîne une itération sur la chaîne entière. Étant donné que la taille de la ligne correspond à la taille du cache LLC, l'analyse vous permet d'effectuer une opération de vérification du cache sans manipuler les tableaux. Pour mesurer les délais, au lieu du DNS, un appel est effectué vers un serveur WebSocket contrôlé par l'attaquant - avant et après la fin de l'opération de recherche, des requêtes sont envoyées dans la ligne, sur la base desquelles le serveur calcule le délai utilisé pour analyser le cache Contenu.
La troisième variante de l'attaque « CSS PP0 » est implémentée via HTML et CSS et peut fonctionner dans les navigateurs avec JavaScript désactivé. La méthode est similaire à "String and Sock", mais n'est pas liée à JavaScript. Lors de l'attaque, un ensemble de sélecteurs CSS est généré qui effectue une recherche par masque. La grande chaîne initiale qui remplit le cache est définie en créant une balise div avec un très grand nom de classe. À l’intérieur se trouve un ensemble d’autres div avec leurs propres identifiants. Chacun de ces divs imbriqués a son propre style avec un sélecteur qui recherche une sous-chaîne. Lors du rendu d'une page, le navigateur tente d'abord de traiter les div internes, ce qui entraîne une opération de recherche sur une grande ligne. La recherche s'effectue à partir d'un masque volontairement manquant et conduit à itérer sur toute la ligne, après quoi la condition « non » est déclenchée et une tentative de chargement d'une image de fond référençant des domaines aléatoires est effectuée : #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»);} … X X ...
Les sous-domaines sont desservis par le serveur DNS de l'attaquant, qui peut mesurer les délais de réception des requêtes. Le serveur DNS émet NXDOMAIN pour toutes les requêtes et tient un journal de l'heure exacte des requêtes. À la suite du traitement d'un ensemble de div, le serveur DNS de l'attaquant reçoit une série de requêtes, dont les délais sont en corrélation avec le résultat de la vérification du contenu du cache.
Source: opennet.ru