C'est reparti pour un tour : une nouvelle faille liée à l'exécution spéculative des processeurs Intel vient d'être dévoilée. Elle permet de récupérer des données sensibles directement depuis le CPU. Elle a été signalée en amont et les premiers correctifs sont déjà disponibles.
Après les révélations autour de Meltdown/Spectre et leurs nombreuses variantes, il s'agit encore « d'attaques par canal auxiliaire d’exécution spéculative ». Cette fois-ci, ce n'est pas le cache qui est ciblé, mais plusieurs mémoires tampons du processeur : Store buffers, Fill buffers et Load ports.
Le fondeur affirme que les brèches avaient été découvertes par ses chercheurs et partenaires, mais aussi par une équipe indépendante.
Risque de vol de données personnelles
MDS, alias Microarchitectural Data Sampling, se compose en fait de quatre failles, aussi connues sous le nom de Fallout, RIDL et Zombiload :
- CVE-2018-12126 : Microarchitectural Store Buffer Data Sampling
- CVE-2018-12130 : Microarchitectural Fill Buffer Data Sampling
- CVE-2018-12127 : Microarchitectural Load Port Data Sampling
- CVE-2019-11091 : Microarchitectural Data Sampling Uncacheable Memory
Le risque est réel puisque, comme l'explique Intel, « sous certaines conditions, MDS permet à un programme de potentiellement lire des données auxquelles il ne devrait pas avoir accès ».
Google en rajoute une couche dans un bulletin de sécurité : « Si des processus Chrome sont attaqués, les données sensibles peuvent inclure le contenu d'un site, ainsi que les mots de passe, les numéros de carte de crédit et les cookies ».
Des démonstrations en vidéo sont disponibles par ici.
Les processeurs Intel depuis 2008 touchés, sauf quelques modèles récents
Dans un document technique, le fondeur relativise tout de même les risques. Les mémoires tampons en question sont bien moins importants que le cache L1 pour les données (L1D) et contiennent donc moins d'informations, qui sont écrasées plus régulièrement.
Ce n'est pas tout : « il est également plus difficile d'utiliser MDS pour déduire des données associées à une adresse mémoire spécifique, ce qui peut obliger le pirate à collecter et analyser de grandes quantités de données pour récupérer des données protégées ». Bref, on peut paniquer, mais pas trop non plus.
Les processeurs Intel depuis 2008 sont touchés (génération Nehalem), à l'exception de certains Core de 8ème et 9ème génération, ainsi que les Xeon Scalable de seconde génération, affirme le fondeur. Intel s'attend à ce que l'ensemble de ses futurs processeurs soient protégés contre MDS.
De leurs côtés, AMD et ARM ne semblent pas concernées. Le Texan est du même avis que les chercheurs : « nous pensons que nos produits ne sont pas susceptibles d’être concernés par « Fallout », « RIDL » et « ZombieLoad Attack » et ce grâce aux mécanismes de protection matérielle au sein de nos architecture. Nous n’avons pas réussi à reproduire ces exploits sur les produits AMD et ne sommes pas au courant de tiers ayant réussi ».
La valse des mises à jour a commencé
La société de Santa Clara ne recommande pas de désactiver l'Hyper-Threading en bloc, d'autant plus « qu'il est important de comprendre que cela ne fournit pas à lui seul une protection contre MDS ». La situation doit être étudiée au cas par cas, en fonction des besoins en termes de sécurité et des logiciels utilisés par chacun.
Dans tous les cas, Intel est en train de mettre à jour le microcode de ses processeurs avec, cette fois encore, une possible baisse des performances. Le fondeur propose quelques tests maison en essayant d'être rassurant. Suivant les cas, la chute peut atteindre 3 % pour le grand public lorsque l'Hyper-Threading reste activé, contre 9 % dans le cas contraire. Pour les datacenters, les baisses oscillent entre 14 % avec HT activé et 19 % dans le cas contraire.
Bien évidemment, de nombreuses mises à jour ont été publiées suite à la découverte et la publication des failles. Chez Apple, cela passe par macOS 10.14.5 publié en début de semaine. Microsoft profite de son patch Tuesday pour déployer des correctifs pour Windows et Windows Server. Ubuntu y va aussi de son correctif, tout comme Oracle, et les annonces devraient se multiplier au cours des prochains jours.
Pour Chrome OS, Google a décidé de désactiver par défaut l'Hyper-Threading. D'autres actions seront prises dans Chrome OS 75, sans plus de détail pour l'instant. Enfin, les services en ligne tels que Amazon AWS, Google Cloud et Microsoft Azure ont également annoncé avoir mis en place des correctifs.
Sachez enfin que les chercheurs à l'origine de cette découverte proposent un outil pour vérifier si sa machine est vulnérable. Il est disponible pour Windows et Linux, avec le code source disponible dans ce dépôt GitHub (Mozilla Public License 2.0).
Commentaires (53)
#1
Quelqu’un saurait m’éclairer sur la façon dont le microcode est mis à jour par les màj de l’OS ?
Ça sous-entend que l’OS peut mettre à jour le firmware du CPU de façon transparente et ça m’étonne (mais j’y connais rien donc bon).
#2
#3
How-To rapide pour l’outil proposé en fin d’article :
Sous Linux, il faut avoir CMake de disponible pour pouvoir construire le binaire. Globalement, ca se fait de la façon suivante :
git clone –recurse-submodules [email protected]:vusec/ridl.git
cd ridl
cmake .
make
Vous devriez avoir un binaire mdstool dans le répertoire courant après ça, qui vous donne la fenêtre présentée en screenshot une fois lancé.
#4
#5
#6
Est-ce que cela a un rapport avec la faille SPOILER qui touche tous les CPU Intel Core ?
#7
Les processeurs Intel depuis 2011 sont touchés
Le document d’intel mentionne Nehalem, donc 2008, pas 2011.
#8
Une fork de ridl en ligne de commande est dispo. J’ai jeté un coup d’œil au code et ça fait bien ce que ça dit, c’est à dire du printf dans une console au lieux d’une interface graphique.
#9
Donc si on cumule l’ensemble des baisses de performance de toutes ces failles sur, disons un Core i7 de 7ème génération, on est sur du -40%? Je suis super étonné que personne n’ait encore collé un procès à Intel, surtout les datacenters dont la facture d’électricité a dû atteindre des sommets à chaque correctif…
#10
@Soraphiro @janiko
Merci ! J’en était resté au flash par disquette qui crame la machine une fois sur quatre.
#11
Le microcode peut être chargé,
Par exemple pour Linux, il peut être chargé soit par un applicatif, soit directement par le noyau (qui est le mieux si le bios n’est pas modifié car cela reste plus tôt que après le démarrage).
L’outiliucode-tool permet de charger le microcode.
À une époque, je m’étais même amusé à réintégrer le microcode de mes processeurs dans des bios AMI et AWARD pour avoir le dernier chargé au plus tôt. Mais c’était fait un peu à l’arrache donc je ne le conseille pas trop.
#12
#13
Si je comprends bien, pour que cette faille soit exploitée, il faut que les hackeurs aient déjà accès en local au serveurs ou PCs pour pouvoir exécuter un code malveillant qui lui va exploiter ce type de brèche ?
De plus, d’après l’article, l’exploitation de cette brèche est complexe :
“Practical exploitation of MDS is a very complex undertaking. MDS does not, by itself, provide an attacker with a way to choose the data that is leaked.”
Donc c’est comme au moment de spectre, est ce que l’on est prêt à perdre jusqu’à 20% de ressource processeur pour contrer cette faille qui aujourd’hui d’après Intel est complexe a exploiter ?
Est ce qu’il n’est pas plus prudent de respecter les standards de sécurité et de faire attention que les équipements et antivirus soit à jour et correctement configurés ?…
#14
Petit lapsus dans la news :
MDS, alias Microarchitectural Data Sampling, se compose en fait de quatre failles, aussi connues sous le nom de Fallout, RIDL et Zombiland Le dernier devrai plutot être zombieload… Sinon, ça serait intéressant de faire un benchmark intel avec failles vs intel sans failles vs amd, pour voir ce que vaux vraiment l’architecture une fois sécurisée.
#15
#16
Autant je suis d’accord avec toi qu’au niveau des datacenters le risque est faible, autant niveau particuliers et même dans une certaine mesure les entreprises (toutes n’ont pas une infra info rigoureuse) le risque est réel principalement par l’effet de masse.
" />
Sinon, c’est marrant, de mon oeil de néophyte, ça donne l’impression qu’en fait Intel était plus performant depuis des années parce qu’ils ont un poil survolé les tests de robustesse…
Je note cependant que, “bizarrement”, aucun site informatique n’a refait de tests comparatifs de processeurs (à l’époque de Meltdown déjà très peu de magazines avaient fait l’effort d’évoquer le sujet).
Prenons en compte également les améliorations de microcode d’AMD…
Serais-je le seul à apprécier si un magazine “au hasard” se permettait de refaire des comparatifs sous Linux (de préférence) et Windows (au pire) ?
#17
Sous Linux, un script shell pour vérifier la vulnérabilité aux diverses failles, et quels contournements sont actifs :https://github.com/speed47/spectre-meltdown-checker
#18
Je regarde merci 
" />
#19
#20
Je viens de vérifier avec l’outil, ma bécanne “loisirs” avec son i9 9900K est touchée par la faille.
La machine pour la boulot n’est pas non plus safe avec son vieillissant i7 4790K, time for AMD.
#21
#22
Ah Shit, Here We Go Again !
" />
#23
Eh oh, j’ai un 4790k, en principal, je te permets pas!
" />
#24
J’aimerais savoir comment s’assurer d’avoir un microcode à jour ainsi que la manière de le mettre à jour, si c’est possible, sous Windows. J’ai les dernières màj mais Asus n’as jamais mis à jour le BIOS de mon laptop (un N551VW) et comment simplement savoir quelle est la version du microcode utilisé, quelle est la dernière en date, etc …
#25
#26
Et encore, pensez à ceux qui ont un 2600K en machine principale 
" />
#27
Le 4790k est encore très véloce, je suis à peine bottleneck en 1080p avec une 1080 Ti.
" />
Mais les problèmes de sécu, c’est un souci, vivement Zen 2.
#28
Mon 2600K est tout aussi parfait pour du 1440p avec comme toi une 1080 Ti 
" />
Par contre le 2600K en 1080p et la Ti, je perdais trop de fps…
Vivement Zen 2 oui !
#29
Perso, sous Win10_proc I7-3770K) , j’ai exactement les mêmes vulnérabilités (je viens de vérifier avec MDSTool) avant et après l’application du patch Tuesday…
C’est normal Docteur?
Je ne comprends même pas pourquoi Microsoft n’a pas pondu un patch plus tôt puisqu’ils sont censés avoir été prévenus depuis plus d’un an (par l’intermédiaire d’Intel?). Pourquoi attendre le jour de la divulgation publique de la faille pour mettre à jour Win10…
#30
Sur Ubuntu, l’update microcode intel a éte deployé sur les dépôts, faites juste un update et un reboot.
#31
Selonhttps://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/master/… il y a un nouveau microcode 0x21 qui est sorti pour Ivy Bridge.
Si Windows l’a déployé (mdstool donne la version), je suppose que MD_CLEAR doit être marqué comme disponible (il n’y a pas le détail des changements CPU par CPU, donc peut-être que ça fait autre chose).
#32
#33
“Le fondeur affirme que les brèches avaient été découvertes par…”
Leur découverte n’est pas récente ?
“CVE-2018”
Voila qui répond en partie à ma question.
Vu les cadences atteintes aujourd’hui par les CPU, ne serait il pas possible de se passer complètement de “canal auxiliaire d’exécution spéculative” ?
#34
#35
Oui :
Ce matin avant update, les syslog :
kernel: [ 0.800527] microcode: sig=0x306a9, pf=0x10, revision=0x20
kernel: [ 0.800644] microcode: Microcode Update Driver: v2.2.
Après mise à jour linux :
kernel: [ 0.000000] microcode: microcode updated early to revision 0x21, date = 2019-02-13
kernel: [ 0.788904] microcode: sig=0x306a9, pf=0x10, revision=0x21
kernel: [ 0.789067] microcode: Microcode Update Driver: v2.2.
\o/
#36
La fréquence plus élevée et le “canal auxiliaire…” seraient les seuls progrès des CPUs récents si on les compare à du 80486 ?
#37
Les progrès, outre les nouvelles instructions, consistent à permettre l’exécution de plus en plus d’instructions en même temps (architecture superscalaire), et de les réordonner (out-of-order).
Sans exécution spéculative :
#38
On fait comment avec le parc d’entreprise? Avec WSUS?
#39
Le patch kernel pour Debian Buster n’est pas encore sorti. :-/ Dommage car pour le reste cette distro est vraiment beaucoup plus stable que Stretch, au moins sous KDE.
#40
Très juste, j’ai tendance à oublier que Intel traîne la même archi depuis plus de 10 ans… Faut dire, ils font tellement d’efforts pour faire croire que leur nouvelle gen est révolutionnaire à chaque fois !! XD
On peut également noter qu’il y a certainement aussi un effet d’opportunité similaire à Windows/Linux, enfin je le suppose : tant qu’à bosser pour essayer de trouver des failles, autant se concentrer sur celui qui a le plus de parts de marché. :)
#41
Intel est seul concerné ? Ou y’a une des variantes qui touchent AMD (ou une partie de gamme seulement) ?
Avec un FX, sur la partie MADS, tout est au vert. Le reste non par contre.
Mais si je passe Spectre & Meltdown Checker, tout ressort comme non vulnérable… il n’inclut pas certaines vérifications de MDS donc ?
#42
Dans ce cas là, c’est intel qui doit fournir le patch.
#43
Hmm, après update et reboot, je suis apparemment toujours vulnérable…
(Ubuntu 18.04.2, i7-4790, microcode: 0x27)
#44
#45
Mon lecteur de disquettes avec windows 3.1 n’attends que toi sur le bon coin
" />
#46
J ai aussi un Haswell sur mon PC principal (4570k) et attends aussi Zen2 pour un upgrade.
Quant au ‘ il semble que les 4XXX ont le plus souffert des patchs anti-spectre et compagnie’, cela reste encore ok sur Haswell.
La perte de perfs en % est encore plus marquée sur l archi Core2Duo comme l outil InSpectre suggérait.
La tendance est d avoir une chute de perf plus marquée plus le CPU est vieux!
Et les CPU sans HT comme nos i5 sont aussi moins affectés que ceux avec HT (i7)
#47
je viens de lancer l outil, mais je ne comprends pas bien comment interpréter les résultats.
J ai pourtant eu les updates du microcode avec le patch de mai sous win10pro (https://support.microsoft.com/fr-ch/help/4494441/windows-10-update-kb4494441 ), mais il reste un paquet de lignes ‘vulnérable’ dans l outil.
Un 2nd article pour mieux expliquer ce qu on devrait avoir serais pas mal :)
#48
Oh il ne faut pas rigoler avec Windows 3,tout le monde s’est étonné que certains parcs tournaient encore avec mais l’OS est tellement simple (et le hardware aussi) que c’est stable comme un RPi 😊
Et en fait on est moins embêtés par toutes ces failles, un pirate s’attend pas à trouver un Pentium MMX… ☺
#49
Normal ces bots qui spam des sites à la con ?
#50
Oui, c’est normal quand on ne protège pas son site contre les bots.
C’est très pénible quand comme moi, on parcourt la liste des articles et des brèves pour voir les nouveaux commentaires pour tomber ensuite sur ces SPAM.
Quelques pistes pour rendre le travail des bots plus difficile. À mettre en place pour la création de compte.