Récemment une équipe de chercheurs de l'Université de Technologie de Graz (Autriche) et le Centre Helmholtz pour la sécurité de l'information (CISPA) a publié des informations sur une vulnérabilité (CVE-2021-26318) sur tous les processeurs AMD ce qui pourrait permettre des attaques par canal latéral de classe Meltdown.
Face aux informations personnelles divulguées de AMD a fait savoir qu'il jugeait inapproprié de prendre des mesures spéciales pour bloquer le problème, puisque la vulnérabilité, comme une attaque similaire détectée en août, est de peu d'utilité en conditions réelles, puisque mentionne qu'il est limité par les limites actuelles de l'espace d'adressage du processus et nécessite des séquences d'instructions (gadgets) dans le noyau. Pour démontrer l'attaque, les chercheurs ont chargé leur propre module de noyau avec un périphérique ajouté artificiellement. Dans la vraie vie, les attaquants peuvent, par exemple, régulièrement utiliser des vulnérabilités du sous-système EBPF pour remplacer les séquences nécessaires.
D'un point de vue pratique, l'attaque peut être utilisée pour organiser des canaux de transmission de données secrets, surveiller l'activité dans le noyau ou obtenir des informations sur les adresses dans la mémoire du noyau pour éviter la protection basée sur la randomisation des adresses (KASLR) dans le processus d'exploitation des vulnérabilités du noyau.
Nous avons découvert des variations de temps et de puissance de l'instruction de prélecture qui peuvent être observées à partir d'un espace utilisateur non privilégié. Contrairement aux travaux précédents sur les attaques de prélecture chez Intel, nous avons montré que l'instruction de prélecture chez AMD filtre encore plus d'informations. Nous démontrons l'importance de ce canal secondaire avec de multiples études de cas dans des contextes du monde réel. Nous démontrons la première panne de la microarchitecture KASLR.
Pour se défendre contre cette nouvelle attaque, AMD a recommandé l'utilisation de techniques de cryptage sécurisées qui aident à bloquer les attaques Meltdown, comme utiliser les instructions LFENCE. Les chercheurs qui ont identifié le problème recommandent d'activer une isolation plus stricte de la table des pages de mémoire (KPTI), qui n'était auparavant utilisée que pour les processeurs Intel.
Au cours de l'expérience, les chercheurs ont réussi à divulguer des informations du noyau à un processus dans l'espace utilisateur.ou à une vitesse de 52 octets par seconde, s'il existe un périphérique dans le noyau qui effectue l'opération, plusieurs méthodes ont été proposées pour extraire les informations stockées dans le cache lors de l'exécution spéculative via des canaux tiers.
La première méthode est basée sur l'analyse des écarts de temps d'exécutionn pour l'instruction processeur et la seconde pour la variation de la variation de la consommation d'énergie lorsque "PREFETCH" (Prefetch + Power) est exécuté.
Nous surveillons l'activité du noyau, par exemple si l'audio est lu via Bluetooth, et nous établissons un canal secret. Enfin, nous avons même filtré la mémoire du noyau à 52.85 B/s avec de simples périphériques Spectre sur le noyau Linux. Nous montrons qu'une isolation plus forte des tables de pages doit être activée par défaut sur les processeurs AMD pour atténuer nos attaques soumises avec succès.
Rappelons que la vulnérabilité Meltdown classique est basée sur le fait que pendant exécution spéculative d'instructions, le processeur peut accéder à une zone de données privée puis rejeter le résultat, car les privilèges établis interdisent un tel accès à partir du processus utilisateur. Dans le programme, le bloc exécuté de manière spéculative est séparé du code principal par une branche conditionnelle, qui, dans des conditions réelles, est toujours déclenchée, mais du fait que la déclaration conditionnelle utilise une valeur calculée que le processeur ne connaît pas lors de l'exécution précoce du code. , l'exécution spéculative de toutes les options de branchement est effectuée.
Étant donné que les opérations spéculatives utilisent le même cache que pour les instructions normalement exécutées, il est possible pendant l'exécution spéculative de mettre en cache des marqueurs qui reflètent le contenu binaire fichiers individuels dans une zone de mémoire fermée, puis dans le code normalement exécuté pour déterminer leur valeur par le temps, l'analyse accède aux données mises en cache et non mises en cache.
Enfin si vous souhaitez en savoir plus, vous pouvez vérifier les détails dans le lien suivant.