MDS (Microarchitectural Data Sampling): Nouvelle vague de vulnérabilités autour de l'exécution spéculative dans les CPU Intel

Ces vulnérabilités résident dans l’implèmentation de l’exécution spéculative, où le microprocesseur essaie de deviner quelles instructions seront éventuellement nécessaires. Ils exploitent la possibilité de lire des tampons de données trouvés entre différentes parties du processeur.

Quatre CVE ont été assignés pour couvrir les différents cas de fuites de données :
- ZombieLoad CVE-2018-12130 pour la fuite de données déjà chargées à partir du buffer de remplissage d'un processeur (MFBDS)
- Fallout CVE-2018-12126 pour la fuite de données stockées dans les buffers (MSBDS)
- RIDL CVE-2018-12127 pour la fuite provenant de divers buffers internes au microprocesseur (MLPDS)
- RIDL CVE-2019-11091 pour la fuite de données dans la mémoire uncacheable (MDSUM)



=> https://cpu.fail/

L'annonce d'Intel: https://www.intel.com/content/www/us/en/architecture-and-technology/mds.html

L'analyse de Canonical (éditeur d'Ubuntu) :

Il a été découvert que le contenu de la mémoire précédemment stockée dans des mémoires microarchitecturales d’un cœur de processeur Intel pouvait être exposé à un processus malveillant s’exécutant sur le même cœur de processeur par le biais d’un canal latéral d’exécution spéculatif. Un attaquant local pourrait accéder au contenu obsolète des mémoires tampon de stockage, des ports de chargement et des tampons de remplissage pouvant contenir des données appartenant à un autre processus ou des données provenant d'un contexte de sécurité différent. En conséquence, une exposition de mémoire inattendue peut se produire entre les processus de l'espace utilisateur, entre le noyau et l'espace de l'utilisateur, entre les ordinateurs virtuels ou entre un ordinateur virtuel et l'environnement hôte.

MDS diffère des autres attaques de canal secondaire d’exécution spéculatives récentes en ce que l’attaquant ne peut pas cibler des données spécifiques. L'attaquant peut échantillonner périodiquement le contenu des tampons mais ne contrôle pas les données présentes dans les tampons lors du prélèvement de l'échantillon. Par conséquent, un travail supplèmentaire est nécessaire pour collecter et reconstruire intégralement les données en un ensemble de données significatif.

Les processeurs d'autres fournisseurs ne sont apparemment pas affectés par les MDS.

Intel a fourni des mises à jour du microcode qui, associées aux noyaux mis à jour, atténuent les vulnérabilités dans certaines situations. La technique sous-jacente utilisée pour résoudre les quatre problèmes est la même. Le noyau exécute une instruction spécifique qui efface tous les tampons microarchitecturaux affectés. Le noyau doit exécuter l'instruction à différents moments pour chaque vulnérabilité d'échantillonnage de données. Dans certaines situations, la suppression des mémoires tampons empêchera les adversaires d’accéder aux données présentes.

Les mises à jour du noyau et du package intel-microcode correspondantes corrigent pleinement les failles de la MDS si votre processeur ne prend pas en charge la technologie Hyper-Threading, également appelée Symmetric Multi-Threading (SMT).

Les MDS ne sont pas totalement contrôlées si votre processeur prend en charge l'Hyper-Threading et si l'Hyper-Threading est activé.

Voici un exemple de charges de travail nécessitant la désactivation de l'Hyper-Threading: Un système qui héberge des machines virtuelles provenant de domaines de sécurité variés et / ou dont le propriétaire du système ne fait pas totalement confiance. Un programme malveillant dans une machine virtuelle peut extraire des secrets d’autres machines virtuelles ou de l’hôte de virtualisation lui-même.

L'option de démarrage du noyau suivante peut être utilisée pour désactiver l'Hyper-Threading des processeurs affectés. Cette configuration fournit une atténuation complète sur les systèmes mis à jour: mds = full, nosmt

---

De nouveaux microcode sont disponible, Dell a par exemple diffusé des mises à jour UEFI pour de nombreux PC.

Intel a prévu des mises à jour pour tous les processeurs sortis depuis 2012 (à part certains Atom).
Certains processeurs de 2011 sont aussi corrigés, mais aucun de 2010 et avant.

Un résumé hors gamme "Atom" :
- famille de processeurs Sandy Bridge (core de 2ème génération par exemple Core i3/i5/i7 2xxx) et plus récents => correctifs présents
- famille de processeurs Nehalem, Westmer (core de 1ère génération) ou plus anciens => pas de correctifs

Liste des processeurs qui sont mis à jour et de ceux qui ne seront pas mis à jour :
(cliquez sur la miniature ci-dessous - le document est au format PDF)


Aucun mécanisme de secours logiciel n'est disponible pour les processeurs qui n'ont pas reçu de mises à jour de microcode par Intel. Une atténuation n'est possible que si Intel a fourni une mise à jour du microcode à votre processeur.

Pour ceux qui ne peuvent pas faire la mise à jour de leur BIOS / UEFI,  de nombreux systèmes d'exploitation vont diffuser des mises à jour du micro-code du CPU (installé à chaque reboot).

Comment vérifier si on est affecté sous Linux ?

En regardant le fichier /sys/devices/system/cpu/vulnerabilities/mds :

cat /sys/devices/system/cpu/vulnerabilities/mds


- Si le fichier n'existe pas, car cela indique que votre noyau n'a pas mis en place de mesures d'atténuation pour MDS : le système est alors vulnérable

- Not affected : Les processeurs qui ne sont pas vulnérables à MDS (par exemple les microprocesseurs AMD)


- Mitigation: Clear CPU buffers; SMT disabled : Mitigation ok. Intel Hyper-Threading n'est pas disponible ou il a été désactivé


- Mitigation: Clear CPU buffers; SMT vulnerable : Mitigation ok. Un risque subsite avec l'activation de Hyper-Threading, d'où le message "SMT est vulnérable"




- Mitigation: Clear CPU buffers; SMT Host state unknown : Mitigation ok. Le noyau n'est pas en mesure de déterminer de manière fiable si Hyper-Threading est activé lors de son exécution dans un environnement virtuel.

- Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable : Vulnerable: soit le microcode n'a pas été installé, soit le processeur est trop ancien pour qu'Intel développe un microcode. Noyau Linux mis à jour, mais sans microcode mis à jour.


- Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown : Vulnerable:  le microcode n'a pas été installé + le noyau n'est pas en mesure de déterminer de manière fiable si Hyper-Threading est activé lors de son exécution dans un environnement virtuel.
[/size]

Oui, c'est un bug matériel, cela concerne tous les systèmes d’exploitation (sauf probablement ceux qui son monotâche, comme MS-DOS).

Microsoft à déployé des mises à jour pour Windows 7, Windows 8 et Windows 10.

Il faut faire par contre attention au microcode, Microsoft ne fournit le microcode que pour le PCs Microsoft (principalement la gamme "surface") : "Si vous possédez un appareil non-Microsoft, nous vous recommandons de contacter votre fabricant OEM pour obtenir cette information."
Aucun mécanisme de secours logiciel n'est disponible pour les processeurs qui n'ont pas reçu de mises à jour de microcode Intel
=> Pour les utilisateurs Windows une mise à jour du BIOS / UEFI est nécessaire.
=> Pour les utilisateurs Linux tout est mis à jour, si la distribution propose bien une mise à jour du microcode.

Maintenant comme évoqué, le risque est bien plus élevé coté serveur qui héberge des VM, d'où la position de ce sujet dans la partie serveur.

Comment vérifier si on a bien le bon microcode ?

Sous linux, il faut faire dmesg | grep microcode

La date du microcode apparaît, elle doit dater de 2019 :



Quand il n'y a pas de microcode disponible, voici ce qu'affiche dmesg |grep microcode :

"openssl speed" c'est du code pur userspace sans aucun syscall ni IPC (comme le "General Compute" d'Intel tant le nombre de threads est inférieur au nombre de threads du CPU), donc c'est normal que les performances ne changent pas.

Les patchs ont des impacts sur les changements de contexte :
 - interruptions
 - appels système
 - basculement d'un processus à un autre (voire thread, je ne sais pas si le kernel fait la différence et évite les séquences d'effacement des buffers dans ce cas)