Auteur Sujet: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel  (Lu 17865 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
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).

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Ubuntu : Les correctifs (micro-code + nouveau noyau) pour Ubuntu sont en ligne pour toutes distributions encore maintenues
   
Mise à jour du microcode pour Ubuntu:
- Ubuntu 19.04 => intel-microcode 3.20190514.0ubuntu0.19.04.1
- Ubuntu 18.10 => intel-microcode 3.20190514.0ubuntu0.18.10.1
- Ubuntu 18.04 LTS => intel-microcode 3.20190514.0ubuntu0.18.04.2
- Ubuntu 16.04 LTS => intel-microcode 3.20190514.0ubuntu0.16.04.1
- Ubuntu 14.04 ESM => intel-microcode 3.20190514.0ubuntu0.14.04.1

Il faut également une mise à jour du noyau Linux :
- Ubuntu 19.04 => linux-image-5.0.0-15-generic 5.0.0-15.16
- Ubuntu 18.10 => linux-image-4.18.0-20-generic 4.18.0-20.21
- Ubuntu 18.04 LTS => linux-image-4.15.0-50-generic 4.15.0-50.54 ou linux-image-4.18.0-20-generic 4.18.0-20.21
- Ubuntu 16.04 LTS => linux-image-4.4.0-148-generic 4.4.0-148.174 ou  linux-image-4.15.0-50-generic 4.15.0-50.54
- Ubuntu 14.04 ESM => linux-image-3.13.0-170-generic 3.13.0-170.220 ou linux-image-4.4.0-148-generic 4.4.0-148.174
- Ubuntu 12.04 ESM => linux-image-3.2.0-140-generic 3.2.0-140.186 ou  linux-image-3.13.0-140-generic 3.13.0-140.186






Comment faire si mon Linux n'a pas installé le package Intel-microcode ?

Pour les PC avec interface graphique, il faut activer l’utilisation du microcode Intel dans les pilotes additionnels :


A priori, c'est activé par défaut depuis Ubuntu 16.04.
Il faut par contre l'activer manuellement sur des anciens Linux ou des distribution comme Debian.[/size]



Sur un serveur Ubuntu server comment faire ?

C'est simple :
sudo apt install intel-microcode

Il faut ensuite redémarrer le serveur.

intel-microcode est un paquet qui installe iucode-tool




Sur un serveur Debian, comment faire ?

La documentation est sur https://wiki.debian.org/Microcode

Il faut activer les dépôts "contrib" et "non-free"  dans /etc/apt/sources.list

Par exemple :
deb http://security.debian.org/ stretch/updates main contrib non-free
deb-src http://security.debian.org/ stretch/updates main contrib non-free
deb  http://deb.debian.org/debian stretch main contrib non-free
deb-src  http://deb.debian.org/debian stretch main contrib non-free

Puis :
sudo apt update
sudo apt install intel-microcode


Il faut ensuite redémarrer le serveur.

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
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]

alain_p

  • Abonné Free fibre
  • *
  • Messages: 16 168
  • Delta S 10G-EPON sur Les Ulis (91)
Personnellement, je suis très sceptique sur la sévérité de ces vulnérabilités, qui sont très difficiles à exploiter, et je me demande si le remède ne peut pas potentiellement être pire que le mal, si par exemple il entraine des problèmes de performance. A voir...

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Sur un ordinateur non virtualisé le risque est faible.

Quand on parle de l'hébergement de serveurs virtualisé, le risque est bien plus élevé.
Tu ne connais pas la personne qui loue la VM à coté...

Extrait tradut en Français de Intel Analysis of Microarchitectural Data Sampling :

Atténuation pour les environnements utilisant le multithreading simultané (SMT)

Le système d'exploitation doit employer deux méthodes différentes pour empêcher un thread d'utiliser MDS pour déduire les valeurs de données utilisées par le thread frère :
- Le premier (planification de groupe) protège contre les attaques d'utilisateurs
- La seconde (entrée synchronisée) protège les données du noyau contre les attaques lorsqu'un thread exécute le code du noyau par un attaquant s'exécutant en mode user sur l'autre thread.

Planification de groupe

Le système d'exploitation peut empêcher un thread frère d'exécuter du code malveillant lorsque le thread actuel traverse des domaines de sécurité. Le planificateur de système d'exploitation peut réduire le besoin de contrôler les threads frères en s'assurant que les charges de travail logicielles partageant le même noyau physique se font mutuellement confiance (par exemple, si elles appartiennent au même domaine de sécurité défini par l'application) ou en veillant à ce que l'autre thread soit inactif.

Le système d'exploitation peut appliquer une telle relation de confiance entre des charges de travail de manière statique (par exemple, via l'affinité des tâches ou cpusets) ou de manière dynamique via un planificateur de groupe dans le système d'exploitation (parfois appelé planificateur principal). Le planificateur de groupe doit préférer les processus avec le même domaine de confiance sur le noyau frère, mais uniquement si aucun autre cœur inactif n'est disponible. Cela peut affecter les décisions d'équilibrage de charge entre les cœurs. Si un processus d'un domaine de confiance compatible n'est pas disponible, le planificateur peut avoir besoin d'inactiver le thread frère.

Système sans planification de groupe : un système à trois cœurs où le cœur 2 exécute des processus provenant de différents domaines de sécurité.
Ces processus pourraient utiliser MDS pour déduire des données protégées les unes des autres.


Système avec planification de groupe : montre comment un planificateur de groupe supprime la possibilité d'attaques de processus à processus en s'assurant qu'aucun noyau n'exécute des processus de domaines de sécurité différents en même temps.



Entrée synchronisée à l'anneau 0 et sortie à l'aide d'IPI

Le système d'exploitation doit prendre des mesures lorsque le thread matériel actuel effectue la transition du code user (code de l'application) au code du noyau (mode anneau 0). Cela peut se produire dans le cadre d'événements syscall ou asynchrones tels que des interruptions. Par conséquent, le thread frère peut ne pas être autorisé à s'exécuter en mode user car le code du noyau peut ne pas approuver le code user. Dans une vue simplifiée d'un système d'exploitation, nous pouvons considérer que chaque thread se trouve dans l'un des trois états suivants:
- Idle
- Ring 0 (kernel code)
- User (code de l'application)

La figure ci-dessous montre les transitions d'état permettant de protéger le noyau contre les applications malveillantes :


Chaque nœud de la figure ci-dessus montre les états d'exécution possibles des deux threads partageant un cœur physique.

À partir de l'état 1, les deux threads sont inactifs. À partir de cet état, une interruption fera passer le noyau à l'état 2a ou 2b en fonction du thread qui est interrompu. S'il n'y a aucune tâche utilisateur à exécuter, le cœur physique repasse à l'état 1 à la fin de l'interruption. Si l'état d'inactivité est implèmenté à l'aide des états C du processeur, VERW doit être exécuté avant l'entrée dans les états C des processeurs affectés par MSBDS.

À partir de 2a ou 2b, un thread peut commencer à exécuter un processus user. Tant que l'autre thread sur le cœur reste inactif, des atténuations spécifiques à SMT ne sont pas nécessaires lors de la transition de 2a à 3a ou de 2b à 3b, bien que le système d'exploitation doive écraser les tampons en exécutant VERW avant de passer à 3a ou 3b.

En variante, à partir de 2a ou 2b, le noyau physique peut passer à l'état 4 si une interruption réveille le fil frère. Le noyau physique peut éventuellement revenir en 2a ou 2b si cette interruption ne provoque pas l'exécution d'un processus user par le noyau.

À partir de l'état 4, le noyau peut passer à l'état 5 et commencer à exécuter le code user sur les deux threads. Le système d'exploitation doit s'assurer que le passage à l'état 5 empêche le thread qui entre en premier le code user de lancer une attaque sur des données protégées dans les tampons microarchitecturaux de l'autre thread. Le système d'exploitation doit également exécuter VERW sur les deux threads. Il n'y a pas de support matériel pour la transition atomique des deux threads entre les états du noyau et de l'utilisateur. Le système d'exploitation doit donc utiliser les techniques logicielles standard pour synchroniser les threads. Le système d’exploitation doit également veiller à éviter, au niveau des points limites, le chargement de données protégées dans des mémoires tampons microarchitecturales lorsque l’un ou les deux threads passent en mode user. Notez que le noyau ne doit entrer que dans l'état 5 lors de l'exécution de deux threads user du même domaine de sécurité (comme décrit dans la section Planification de groupe ci-dessus).

Le noyau peut entrer dans l'état 6a ou 6b à partir de l'état 5 parce qu'un des threads quitte le mode user ou à partir de l'état 3a ou 3b car une interruption a réveillé un thread de l'état inactif. Lorsqu'il est dans l'état 6a ou 6b, le système d'exploitation doit éviter d'accéder aux données considérées comme protégées vis-à-vis du thread frère en mode user. Si le thread dans l'état du noyau doit accéder à des données protégées, le système d'exploitation doit passer de l'état 6a ou 6b à l'état 4. Le thread dans l'état du noyau doit utiliser une interruption interprocesseur (IPI) pour mettre en contact les deux threads dans l'état du noyau afin d'effectuer la transition. le noyau à l'état 4. Lorsque le thread du noyau est prêt à quitter l'état du noyau (en passant à l'état inactif ou en revenant à l'état user), le thread frère peut être autorisé à quitter la routine de service IPI et à reprendre son exécution. l'utilisateur se déclare lui-même après avoir exécuté un VERW.

Marco POLO

  • Abonné Free fibre
  • *
  • Messages: 2 132
  • FTTH 1 Gb/s sur Paris (75)
Cela concerne-t'il également les PCs sous Windows ?

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
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 :



Marco POLO

  • Abonné Free fibre
  • *
  • Messages: 2 132
  • FTTH 1 Gb/s sur Paris (75)
Merci: MàJ cumulative installée. 

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Attention : tu dois aussi mettre à jour le BIOS de ton PC pour que cela puisse fonctionner.

Quid des performances ?

Intel a réalisé des tests qui montrent une absence de baisse de performance sauf pour les serveurs de stockage :



vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Mes propres tests de performances avant / après le patch

J'ai toutefois eu enfin de faire mes propre tests, sur un PC bien plus ancien et bien moins performant avec l'Hyper-Threading non désactivé (car oui le désactiver fait bien baisser les performances, pas de surprise)

J'ai réalisé mes tests sur les 5 technologies de chiffrement utilisées pour transporter du trafic https avec un Core i3-4150 @3.50GHz, processeur intégrant les instructions AES-NI.
Le système d’exploitation est Ubuntu 19.04 et j'ai réalisé le test avant et après la mise à jour micro-code + noyau Linux.

OpenSSL donne des débits en Mo/s pour plusieurs taille de blocs (16 bytes / 64 bytes / 256 bytes / 1024 bytes / 8192 bytes / 16384 bytes) : je prend la valeur la plus élevée entre tous les types de blocs et je recommence deux fois les tests pour prendre le test le plus élevé.

$ openssl speed -elapsed -evp aes-128-cbc --multi 8 : Perte de débit de 0,01% (3134,2 Mo/s vs 3134,0 Mo/s)

$ openssl speed -elapsed -evp aes-256-cbc --multi 8 : Perte de débit de 0,36% (2255,0 Mo/s vs 2246,9 Mo/s)

$ openssl speed -elapsed -evp aes-128-gcm --multi 4 : Perte de débit de 0,04% (7035,2 Mo/s vs 7032,6 Mo/s)

$ openssl speed -elapsed -evp aes-256-gcm --multi 4 : Perte de débit de 0,34% (5421,2 Mo/s vs 5402,7 Mo/s)

$ openssl speed -elapsed -evp chacha20-poly1305 --multi 4 : Perte de débit de 0,07% (4272,3 Mo/s vs 4269,5 Mo/s)

Les tests avec moins de threads sont moins impactés ou non impactés.
=> L'impact du patch sur les performances est donc bien faible


La version d'OPenSSL utilisée est celle d'Ubuntu 19.04 : OpenSSL 1.1.1b  26 Feb 2019.



Liste de sites qui utilisent aes-128-cbc :
centurylink.ca
Liste de sites qui utilisent aes-256-cbc :
sfr.fr
skype.com

Liste de sites qui utilisent aes-128-gcm :
amazon.fr
google.com
youtube.com
orange.fr
ovh.com
securityheaders.com
mozilla.github.io
free.fr
lemonde.fr
vichy.fr
ubuntu.com
debian.org
fr.yahoo.com
cogentco.com
linkedin.com
speedtest.net
vinted.fr
banque-france.fr
psychologies.com
ssllabs.com
mozilla.org
fortuneo.fr
netflix.com
hstspreload.org

Liste de sites qui utilisent aes-256-gcm :
microsoft.com
apple.com
getfedora.org
ionos.fr
paris.fr
lyon.fr
dailymotion.com
leboncoin.fr
bouyguestelecom.fr
qwant.com
scaleway.com
boursorama.com
nperf.com
mycanal.fr
assurance-carte.europ-assistance.fr
k-net.fr
LaFibre.info
1.testdebit.info

Liste de sites qui utilisent chacha20-poly1305 :
tls.imirhil.fr
fr.wikipedia.org
cdiscount.com
fr.libreoffice.org
videolan.org

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
"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)

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Le test a été réalisé sur un Core i3-4150 : 2 cœurs Hyper-Threading, donc au moins quand je suis en multi 8 bascule d'un processus à un autre.

Par contre tu saurais peut-être me dire pourquoi avec OpenSSL, aes-128-cbc et aes-256-cbc voit ses performances doublées quand on passe de 2 threads à 4threads alors que le CPU n'a que 2 cœurs ! Là l'Hyper-Threading permet de doubler les performances.

Au contraire, avec aes-128-gcm etaes-256-gcm il n'y a aucun gain avec l''Hyper-Threading : les performances sont les mêmes quand on passe de 2 threads à 4threads.