LVI CVE-2020-0551 Cette nouvelle classe d'attaques repose sur des manipulations des mêmes structures microarchitecturales que celles des attaques
(Microarchitectural Data Sampling), Spectre et Meltdown Partiellement, la difficulté de bloquer ce problème est compensée par le fait qu'à l'heure actuelle, l'attaque a un caractère plus théorique que pratique (elle est théoriquement possible, mais très difficile à réaliser et ne peut être reproduite que dans des tests synthétiques).
a attribué
La société Intel a publié Le problème a été identifié en avril de l'année dernière par le chercheur Jo Van Bulck de l'Université de Louvain, après quoi, avec la participation de 9 chercheurs d'autres universités, cinq méthodes de base pour effectuer des attaques ont été développées, chacune admettant l'existence de variantes plus spécifiques.
Indépendamment, en février de cette année, des chercheurs de la société Bitdefender ont également l'une des variantes de l'attaque LVI et en ont informé Intel. Les variantes des attaques diffèrent par l'utilisation de diverses structures microarchitecturales, telles que le tampon de stockage (SB, Store Buffer), le tampon de remplissage (LFB, Line Fill Buffer), le tampon de commutation de contexte FPU et le cache de premier niveau (L1D), précédemment utilisés dans des attaques telles que LazyFP , , , , et .
La principale entre LVI et les attaques MDS est que MDS manipule la définition du contenu des structures microarchitecturales restantes dans le cache après un traitement spéculatif d'exceptions (fault) ou d'opérations de chargement et de stockage, tandis que
les attaques LVI permettent d'injecter des données de l'attaquant dans les structures microarchitecturales pour influencer l'exécution spéculative ultérieure du code de la victime. Grâce à ces manipulations, l'attaquant peut extraire le contenu des structures de données privées dans d'autres processus lors de l'exécution d'un certain code sur le cœur CPU cible.
Pour dans le code du processus victime des séquences de code particulières (gadgets), dans lesquelles une valeur contrôlée par l'attaquant est chargée, et le chargement de cette valeur entraîne la levée d'exceptions (fault, abort ou assist), qui rejettent le résultat et réexécutent l'instruction. Lors du traitement de l'exception, une fenêtre spéculative se crée, durant laquelle des données traitées dans le gadget fuient. En particulier, le processeur commence à exécuter en mode spéculatif un morceau de code (gadget), puis détermine que la prédiction était incorrecte et annule les opérations à leur état initial, mais les données traitées pendant l'exécution spéculative s'accumulent dans le cache L1D et les tampons microarchitecturaux et sont accessibles pour être extraites au moyen de méthodes connues de détection de données résiduelles par des canaux latéraux.
L'exception « assist », contrairement à la « fault », est traitée à l'intérieur du processeur sans appel aux gestionnaires de logiciels. Une assist peut survenir, par exemple, lorsqu'il est nécessaire de mettre à jour le bit A (Accessed) ou D (Dirty) dans la table des pages mémoire. La principale difficulté pour mener une attaque sur d'autres processus réside dans la manière d'initier la survenue d'une assist en manipulant le processus victime. Actuellement, aucune méthode fiable n'existe pour ce faire, mais il n'est pas exclu qu'elles soient découvertes à l'avenir. La possibilité de mener une attaque a jusqu'à présent été confirmée uniquement pour les enclaves Intel SGX, les autres scénarios étant théoriques ou reproductibles dans des conditions synthétiques (des gadgets spécifiques doivent être ajoutés au code)
Vecteurs d'attaques possibles :
- Fuite de données du noyau vers un processus au niveau utilisateur. La protection du noyau Linux contre les attaques de type Spectre 1, ainsi que le mécanisme de protection SMAP (Supervisor Mode Access Prevention), réduisent considérablement le risque d'attaque LVI. Un ajout de protection dans le noyau peut être nécessaire à l'avenir si des méthodes d'attaque LVI plus simples sont découvertes.
- Fuite de données entre différents processus. Une attaque nécessite la présence de fragments de code spécifiques dans l'application et la détermination de la méthode de levée d'exception dans le processus cible.
- Fuite de données de l'environnement hôte vers le système invité. L'attaque est considérée comme trop complexe, nécessitant l'exécution de diverses étapes difficiles à réaliser et des prévisions d'activité au sein du système.
- Fuite de données entre des processus dans différents systèmes invités. Le vecteur d'attaque est similaire à l'organisation d'une fuite de données entre différents processus, mais nécessite en plus l'exécution de manipulations complexes pour contourner l'isolation entre les systèmes invités.
Des chercheurs ont publié démontrant les principes de l'attaque, mais ils ne sont pas encore utilisables pour réaliser de véritables attaques. Le premier exemple permet de diriger l'exécution spéculative du code dans le processus cible de manière similaire à la programmation orientée sur le retour (, Return-Oriented Programming). Dans cet exemple, le processus ciblé est préparé spécifiquement, contenant les gadgets nécessaires (l'application de l'attaque à de véritables processus tiers est difficile). Le deuxième exemple permet de s'immiscer dans les calculs lors du chiffrement AES à l'intérieur de l'enclave Intel SGX et d'organiser une fuite de données durant l'exécution spéculative des instructions pour récupérer la valeur utilisée pour le chiffrement de la clé.
Source : opennet.ru
