Un groupe de chercheurs de l'Université libre d'Amsterdam a identifié plusieurs nouvelles vulnérabilités de type Spectre-v2, publiées sous le nom de code Training Solo, permettant de contourner les mécanismes d'isolation mémoire. Dans le contexte des systèmes de virtualisation, ces vulnérabilités permettent de déterminer le contenu de la mémoire de l'environnement hôte depuis les systèmes invités, et dans le contexte des serveurs — d'identifier le contenu de la mémoire du noyau lors de l'exécution d'un exploit dans l'espace utilisateur. Des exemples d'exploits pour réaliser de telles attaques sont publiés sur GitHub. Les exploits présentés permettent d'extraire des données arbitraires de la mémoire du noyau à une vitesse de 17 Ko/s, et de la mémoire de l'hyperviseur — 8,5 Ko/s.
Dans les attaques de type Spectre-v2, la fuite de données est organisée par l'injection de valeurs dans le tampon d'adresses de branchement (Branch Target Buffer) ou le tampon d'historique de branchement (Branch History Buffer), utilisés pour prédire la prochaine opération de branchement. À travers des manipulations de l'historique de branchement, des conditions de prédiction incorrecte de branchement sont créées lors de l'exécution spéculative des instructions. La tâche de l'attaquant est de s'assurer que lors de l'opération spéculative de branchement, l'adresse de branchement provienne de la zone mémoire souhaitée. Après l'exécution du branchement spéculatif, l'adresse de branchement lue de la mémoire reste dans le cache processeur (sous la forme d'adresse, les données nécessaires à l'attaquant sont lues depuis la mémoire). Pour extraire des informations du cache, l'une des méthodes de détermination du contenu du cache peut être utilisée sur la base de l'analyse des variations de temps d'accès aux données mises en cache et non mises en cache.
Les méthodes d'attaque Training Solo visent à contourner les mécanismes d'isolation des domaines d'exécution (domain isolation), tels que IBPB, eIBRS et BHI_NO, utilisés pour bloquer les attaques de type Spectre-v2. Par exemple, l'instruction IBPB (Indirect Branch Prediction Barriers) réinitialise l'état du bloc de prédiction de branchement à chaque changement de contexte — lors du passage de contrôle entre l'espace utilisateur et le noyau ou entre le système invité et l'environnement hôte. La réinitialisation de l'état bloque la possibilité d'utiliser un code propre pour influencer le comportement du bloc de prédiction des branches indirectes.
Les différences des méthodes Training Solo résident dans le fait que, pour influencer le bloc de prédiction des transitions, il est proposé de ne pas exécuter de code contrôlé par l'attaquant, mais d'utiliser du code déjà présent du côté de la zone d'exécution privilégiée (noyau ou hyperviseur), dont l'attaquant parvient à obtenir des fuites. Pour le reste, les méthodes ressemblent à l'attaque classique Spectre-v2. En outre, les chercheurs ont identifié deux problèmes matériels (CVE-2024-28956 et CVE-2025-24495), permettant de contourner complètement l'isolation des zones d'exécution et de réaliser des fuites issues des processus d'autres utilisateurs, d'autres systèmes invités ou de l'environnement hôte.
Trois types d'attaques Training Solo ont été proposées :
- Distorsion de la logique de prédiction des transitions en appelant des séquences de commandes (gadgets) déjà existantes dans le noyau, influençant le contenu du tampon d'historique des transitions. Comme gadgets, il est proposé d'utiliser le mécanisme de restriction d'accès aux appels système SECCOMP, permettant grâce à l'insertion de ses propres filtres BPF d'obtenir un faux saut indirect en mode spéculatif (les filtres dans SECCOMP étant spécifiés par le classique cBPF, activé par défaut contrairement à l'eBPF). Lors des tests sur les CPU Intel Tiger Lake et Lion Cove, la vitesse de fuite avec cette méthode était de 1,7 Ko/sec.
- Utilisation des collisions d'IP (Instruction Pointer) dans le bloc de prédiction des transitions. L'attaquant peut créer des conditions dans lesquelles l'adresse pour un saut spéculatif sera choisie uniquement sur la base de l'adresse de saut déjà présente dans le tampon, sans tenir compte de l'historique des transitions. L'idée est qu'une opération de saut indirect peut influencer une autre, si une collision se produit lors du stockage des hachages de leurs adresses dans le BTB (Branch Target Buffer).
- Utilisation de l'influence des sauts directs sur la prédiction des sauts indirects. Un tel comportement est causé par deux vulnérabilités matérielles : CVE-2024-28956 — ITS (Indirect Target Selection) et CVE-2025-24495 — un problème dans les CPU Intel avec des cœurs Lion Cove. La vitesse de fuite de données de la mémoire avec cette méthode était de 17 Ko/sec. Dans l'exploit démontré pour déterminer le hachage du mot de passe de l'utilisateur root, sauvegardé en mémoire après l'exécution de la commande « passwd -s », il a fallu 60 secondes.
Une attaque altérant le tampon d'historique des sauts concerne tous les CPU Intel, y compris ceux des familles Coffee Lake et Lion Cove, qui prennent en charge le mécanisme eIBRS. Pour bloquer cette vulnérabilité, Intel a publié une mise à jour du microcode avec la nouvelle instruction IBHF (Indirect Branch History Fence), qui doit être indiquée après le code affectant le tampon d'historique des sauts. Pour les anciens CPU Intel, une méthode logicielle de nettoyage de l'historique des sauts est recommandée. Une modification a été acceptée dans le noyau Linux, ajoutant à la fois des solutions logicielles et matérielles. la protection contre les attaques, réalisées en utilisant cBPF. AMD a déclaré que cette méthode d'attaque n'affecte pas ses CPU. ARM a également rapporté que le problème ne concerne que les anciens processeurs ARM vulnérables aux attaques Spectre-v2 et ne prenant pas en charge les extensions FEAT_CSV2_3 et FEAT_CLRBHB.
La vulnérabilité Indirect Target Selection (ITS, CVE-2024-28956) concerne les CPU Intel Core de 9e à 11e génération (Cascade Lake, Cooper Lake, Whiskey Lake V, Coffee Lake R, Comet Lake, Ice Lake, Tiger Lake et Rocket Lake) et les Intel Xeon de 2e et 3e génération. La vulnérabilité CVE-2025-24495 se manifeste sur les CPU basés sur les microarchitectures Lunar Lake et Arrow Lake. Les problèmes ont été résolus dans la mise à jour du microcode d'hier. Une modification a été acceptée dans le noyau Linux, bloquant le problème en déplaçant les sauts indirects vers le haut de la ligne de cache.
Source : opennet.ru
