web-dev-qa-db-fra.com

Quelles sont les nouvelles attaques MDS et comment les atténuer?

Plusieurs nouveaux canaux latéraux matériels ont été découverts appelés attaques MDS , qui permettent la lecture de mémoire arbitraire, comme Meltdown. De nombreuses atténuations existantes sont inutiles contre eux. Les CVE concernés sont:

  • CVE-2018-12126 - Échantillonnage de données de mémoire tampon de microarchitecture (MSBDS)
  • CVE-2018-12130 - Échantillonnage de données de tampon de remplissage microarchitectural (MFBDS)
  • CVE-2018-12127 - Échantillonnage de données de port de charge microarchitectural (MLPDS)
  • CVE-2019-11091 - Mémoire non mise en cache d'échantillonnage de données microarchitecturales (MDSUM)

Un peu plus d'informations sont données sur CPUFail , documentation Linux , et un article de blog RedHat .

Ma compréhension actuelle est que la mise à jour du microcode modifie le comportement de l'instruction VERW obsolète de sorte qu'elle provoque un vidage de divers tampons de processeur internes, et que la mise à jour logicielle (dans Linux au moins ) oblige le système d'exploitation à émettre cette instruction à tout changement de contexte (par exemple, entrer et quitter des appels système). CVE-2018-12130 (MFBDS), cependant, ne peut pas être atténué de cette façon car le tampon est partagé entre des cœurs logiques (mais pas physiques). Il est nécessaire de désactiver SMT (Hyper-Threading).

CVE-2018-12130 (MFBDS) ne peut être que partiellement atténué en désactivant SMT, selon n article de blog approfondi . Certaines informations peuvent toujours être divulguées via un changement de contexte pendant les appels système. Les mises à jour du microcode et du logiciel décrites ci-dessus, en plus de désactiver SMT, sont-elles suffisantes pour complètement l'éviter?

Enfin, l'installation de la dernière mise à jour du microcode et du système d'exploitation et la désactivation de SMT sont-elles suffisantes pour complètement atténuer toutes ces attaques microarchitecturales nouvellement découvertes, y compris ZombieLoad?

hardwarethreat-mitigationside-channelintel
10
forest

Ma compréhension actuelle est que la mise à jour du microcode change le comportement de l'instruction VERW obsolète de sorte qu'elle provoque un vidage de divers tampons internes du processeur

Le nouveau comportement de l'instruction VERW est décrit dans l'article this . En particulier:

  • L'instruction VERW conserve la même fonctionnalité existante, c'est-à-dire qu'elle vérifie si le segment spécifié est accessible en écriture à partir du niveau de privilège actuel.
  • Seule la variante opérande mémoire de l'instruction est garantie pour écraser les tampons exploités par MDS. La variante d'opérande de registre peut ou non exécuter la fonctionnalité d'écrasement du tampon.
  • La fonctionnalité d'écrasement de la mémoire tampon se produit quel que soit le résultat de la vérification de l'autorisation d'écriture de segment (y compris une exception).

L'exécution de l'instruction VERW n'empêche pas à elle seule l'exécution d'instructions ultérieures avant que tous les tampons affectés par MDS ne soient écrasés. Par conséquent, il est nécessaire de placer une instruction de sérialisation (Intel appelle une barrière à la spéculation) après VERW. Prenons l'exemple du même article:

Code region A (victim accessing secret data)
VERW m16
Code region B (victim accessing data that is not secret)
Speculation barrier (for example, LFENCE)
Code region C (attacker can only see the data accessed in B)

Supposons que ces instructions soient exécutées sur un processeur avec le MD_CLEAR mise à jour du microcode (discutée ci-dessous). L'exécution de A peut laisser certaines données secrètes en vol sur le même noyau physique. Lorsque VERW commence l'exécution, B peut s'exécuter avant que tous les tampons qui fuient soient remplacés. Une barrière, telle que LFENCE, doit être placée après B pour garantir que C ne peut pas accéder aux données secrètes.

L'instruction VERW n'est pas prise en charge en mode réel et en mode virtual-8086 car les autorisations d'accès aux segments ne sont pas disponibles dans ces modes. Par conséquent, dans ces modes, une séquence d'instructions, qui dépend de la microarchitecture, doit être utilisée à la place.

Les caractéristiques suivantes de VERW expliquent pourquoi Intel a choisi de surcharger cette instruction avec la fonctionnalité d'écrasement du tampon (au lieu de toute autre instruction ou d'introduction d'un nouveau MSR):

  • VERW est microcodé, ce qui est probablement nécessaire pour qu'une mise à jour du microcode fonctionne.
  • VERW est rarement utilisé, donc la surcharge de performances qui en résulte est pratiquement insignifiante sur les logiciels existants.
  • VERW peut être exécuté à n'importe quel niveau de privilège. En particulier, il peut être utilisé dans les cas où les limites de sécurité sont en mode utilisateur (par exemple, SGX et bacs à sable).

VERW n'est cependant pas parfait. Comme déjà dit ci-dessus, cela ne fonctionne pas en mode réel et en mode virtuel-8086. Il modifie également l'indicateur ZF.

CVE-2018-12130 (MFBDS) ne peut être atténué que partiellement en désactivant SMT, selon un article de blog approfondi. Certaines informations peuvent toujours être divulguées via un changement de contexte pendant les appels système.

Deux cas doivent être examinés séparément:

  • L'attaquant et la victime ne s'exécutent jamais sur deux threads du même noyau physique en même temps. Cela peut se produire lorsque HT est désactivé ou lorsque le planificateur du système d'exploitation décide d'exécuter les threads sur différents cœurs physiques en même temps (car, par exemple, les threads ont des affinités de noyau physique différentes). Dans les deux cas, les threads peuvent toujours s'exécuter sur le même noyau logique à différents moments. Un exploit MDS peut toujours réussir. Le seul moyen pour l'attaquant de s'exécuter sur le même noyau logique que celui sur lequel la victime s'exécute est lorsque la victime passe en mode noyau (par exemple, appel système ou interruption matérielle) et que l'attaquant est programmé pour s'exécuter ensuite sur le même noyau logique. . Par conséquent, le noyau peut empêcher complètement l'attaquant d'exploiter les tampons internes du processeur en exécutant l'instruction VERW avant de retourner en mode utilisateur (pour exécuter ensuite le thread programmé sur ce noyau logique). Cela garantit également que les tampons ne contiennent aucune demande de mémoire du noyau lors du retour en mode utilisateur. De même, VERW doit être exécuté lors du basculement entre deux machines virtuelles sur le même noyau logique.
  • L'attaquant et la victime peuvent s'exécuter simultanément sur le même noyau physique. Le noyau Linux documentation sur MDS mentionne que HT doit être désactivé pour une protection complète afin d'éviter que cette situation particulière ne se produise en premier lieu. Intel article sur MDS propose cependant une atténuation alternative appelée ordonnancement de groupe. L'idée ici est de s'assurer que deux threads sont planifiés pour s'exécuter sur deux cœurs logiques frères uniquement s'ils se font mutuellement confiance. L'hyperviseur Hyper-V utilise déjà la planification de groupe (et il a été récemment mis à jour pour utiliser VERW lors du basculement entre des processeurs virtuels qui appartiennent à différentes machines virtuelles). Pendant l'exécution de VERW (ou la séquence logicielle alternative), le noyau logique frère doit être mis au repos (par exemple, exécuter HLT ou PAUSE) pour garantir que tous les tampons obtiennent écrasé.

Les atténuations susmentionnées (écrasement des tampons affectés par MDS lors du retour du noyau ou lors du basculement entre machines virtuelles, désactivation de HT et planification de groupe) ne peuvent pas protéger les applications en bac à sable (dans un navigateur Web) et les enclaves SGX, où il n'y a pas de commutation entre les niveaux de privilège . Une atténuation possible pour les applications en bac à sable consiste à utiliser des processus à la place. Les enclaves SGX sont protégées par la mise à jour du microcode elle-même.

Le MD_CLEAR la mise à jour du microcode semble inclure les modifications suivantes:

  • Nouvelle fonctionnalité de l'instruction VERW comme expliqué ci-dessus. Seuls les tampons qui sont vulnérables sur chaque processeur particulier sont remplacés, donc l'impact de VERW sur les performances dépend du processeur. Sur les processeurs qui ne sont pas vulnérables à une attaque MDS (tels que 2nd Gen Xeon SP), VERW n'écrase aucun tampon et se comporte comme d'habitude.
  • Lors de l'entrée ou de la sortie d'une enclave SGX, les tampons affectés par MDS sont remplacés. Cependant, à l'entrée de l'enclave, il doit s'assurer qu'aucun thread non fiable ne s'exécute sur le noyau logique frère.
  • Lorsque vous quittez le mode de gestion du système (à l'aide de l'instruction RSM), les tampons affectés à MDS sont remplacés. Cependant, à l'entrée en mode SMM, le logiciel SMM doit garantir qu'aucun thread non approuvé ne s'exécute sur le noyau logique frère.
  • Le RIDL papier dans la section IX mentionne que "le microcode mis à jour vide également ces tampons lors du vidage du cache L1." Je pense que cela fait référence au IA32_FLUSH_CMD MSR, où la définition du bit à l'index 0 à 1 entraîne l'écriture différée du processeur et invalide l'ensemble du cache L1D. C'est ce qu'on appelle le L1D_FLUSH commande. Il écrase également tous les tampons vulnérables à MDS.

Dans cet article d'Intel, l'impact sur les performances de la mise à jour du microcode et du patch du système d'exploitation (pour utiliser l'instruction VERW) me semble significatif (plus de 5%) pour certains benchmarks. Il y a aussi une liste de FAQ à la fin où Intel recommande de ne pas désactiver HT, ce qui est logique.

La section E du document RIDL mentionne que les auteurs ont pu divulguer des adresses physiques à partir du matériel de navigation de page des MMU (les pages parcourent les LFB). Je n'ai vu aucune atténuation proposée pour cette attaque.

Certains processeurs récents incluent des atténuations matérielles pour les quatre attaques MDS. Cela peut être vérifié à l'aide de la séquence de commandes suivante:

Sudo modprobe msr
Sudo rdmsr -p 0 0x10A

La première commande charge le module de noyau msr et la seconde commande lit la valeur dans le IA32_Arch_CAPABILITIES MSR. Si le sixième bit (bit à l'index 5) est 1, le processeur a des atténuations matérielles pour toutes les attaques MDS et donc toutes les atténuations décrites ci-dessus ne sont pas nécessaires. Ce bit est appelé MDS_NO. Sinon, le processeur n'a aucune atténuation matérielle pour au moins MSBDS, MLPDS et MDSUM. Notez que si le IA32_Arch_CAPABILITIES MSR lui-même n'est pas pris en charge, alors le processeur n'a définitivement aucune atténuation matérielle pour toutes les attaques MDS.

Pour une discussion sur le fonctionnement de MFBDS, MLPDS et MDSUM, voir: A propos des vulnérabilités RIDL et de la "relecture" des charges . Pour une discussion sur le fonctionnement de MSBDS, voir: Quels sont les détails microarchitecturaux derrière MSBDS (Fallout)? .

6
Hadi Brais

Voici les descriptions des CVE:

CVE-2018-12126 - faille pouvant entraîner la divulgation d'informations à partir du tampon de stockage du processeur.

CVE-2018-12127 - exploiter les opérations de chargement du microprocesseur qui peuvent fournir des données à un attaquant sur les registres CPU et les opérations dans le pipeline CPU.

CVE-2018-12130 - erreur de mise en œuvre des tampons de remplissage du microprocesseur qui peuvent exposer des données dans ce tampon.

CVE-2019-11091 - faille dans la mise en œuvre du "tampon de remplissage", un mécanisme utilisé par les processeurs modernes lorsqu'un cache-miss est effectué sur le cache du processeur L1.

Pour résoudre le problème global, il faut s'assurer que le code approuvé et non approuvé ne partage pas les cœurs physiques.

La désactivation de HT ne permet pas que cela se produise dans le cas de HT, mais dans un environnement VM, vous pouvez toujours vous retrouver avec des codes dangereux et non dangereux fonctionnant sur le même noyau physique, car il y a deux vecteurs d'attaque possibles au niveau de l'hyperviseur:

vecteur d'attaque à contexte séquentiel (SCAV, inter-VM): un VM malveillant) peut potentiellement déduire les données récemment accédées d'un contexte précédent (thread HV ou autre VM thread) sur l'un ou l'autre processeur logique d'un cœur de processeur.

Vecteur d'attaque de contexte simultané (CCAV Inter-VM): un VM malveillant peut potentiellement inférer les données récemment accédées d'un contexte s'exécutant simultanément (thread HV ou autre VM) sur l'autre processeur logique du cœur de processeur compatible HT.

Comme vous pouvez le voir, l'un des vecteurs ne nécessite pas l'activation de HT. La désactivation de HT ne résout donc que l'une des 2 possibilités d'attaque (CCAV).

Pour corriger l'autre, une correction au niveau du logiciel est nécessaire pour s'assurer qu'un SCAV ne se produit pas.

Pour SCAV , les hyperviseurs doivent être corrigés avec les mises à jour du microcode fournies par Intel. Dans le cas de VMWare, ceux-ci sont fournis dans des correctifs ESXi distincts pour la plupart des plates-formes Intel concernées. Pour CCAV VMware propose également une solution (Side-Channel-Aware Scheduler peut être activé - cela garantit pratiquement qu'un tel exploit ne peut pas se produire), mais cela pourrait impact sur les performances. Quoi qu'il en soit, l'impact sur les performances devrait être inférieur à la désactivation de HT, mais notez que SCAS est destiné à la couche Hypervisor et non à la couche Virtual Machine. Les machines virtuelles réelles sont toujours vulnérables si elles ne sont pas corrigées.

En conclusion, à la fois les HV et les VM doivent être corrigés ou HT désactivés pour le deuxième cas (CCAV) et un correctif au niveau HV basé sur les mises à jour du microcode Intel est nécessaire pour le 1er cas (SCAV).

0
Overmind