Encore de nouvelles failles sur les processeurs Intel, les correctifs sont disponibles

Encore de nouvelles failles sur les processeurs Intel, les correctifs sont disponibles

Par Sébastien Gavois

Le 13 Novembre 2019 à 09h14
Sciences et espace
2 min 28

Encore de nouvelles failles sur les processeurs Intel, les correctifs sont disponibles

Selon Intel, la première faille TSX Asynchronous Abort (TAA) est « similaire » à une autre brèche dévoilée en mai dernier : Microarchitectural Data Sampling (MDS), liée à l'exécution spéculative des processeurs Intel. Les deux brèches touchent ainsi les mêmes mémoires tampons : Store buffers, Fill buffers et Load ports.

Là encore, un utilisateur authentifié avec un accès local pourrait récupérer des informations via une attaque par canal auxiliaire. TAA dispose d'un numéro CVE différent de MDS – CVE-2019-11135 – car « elle utilise un nouveau mécanisme pour exploiter » cette vulnérabilité. De plus amples détails techniques sont disponibles par ici.

Le fondeur dévoile également d'autres failles, comme la CVE-2018-12207, alias Intel Processor Machine Check Error, pouvant faire planter une machine avec le code d'erreur 0150H. Elle ne concerne visiblement que la virtualisation. 

Enfin, deux failles concernent l'IGP i915 : CVE-2019-0154 et CVE-2019-0155. La première peut provoquer un déni de service, tandis que la seconde permettrait à un attaquant avec un accès local de « récupérer des données sensibles ou éventuellement élever ses privilèges ».

Les brèches et correctifs ont été signalés en amont, ce qui explique qu'une vague de mise à jour se déverse ces dernières heures. Windows, Ubuntu et Red Hat ont d'ores et déjà commencé le déploiement. 

Commentaires (28)


-Vlad- Abonné
Le 13/11/2019 à 10h20

Le lien windows en fin d’article concerne windows 7, pour windows 10 ici : https://support.microsoft.com/fr-fr/help/4524570


pamputt Abonné
Le 13/11/2019 à 10h51

Est ce qu’on a des infos sur des développements de nouvelles familles de processeurs qui ne seraient pas sensibles à ce type d’attaques, aussi bien chez Intel que chez AMD, etc


hwti Abonné
Le 13/11/2019 à 11h55
Obidoub
Le 13/11/2019 à 12h17

Difficile de blâmer Intel, par définition une faille est un truc inévitable.



Mais moi qui comptait acheter du Intel en fin d’année, je me pose des questions. Acheter un gros CPU très cher pour ensuite voir ses performances fondre comme neige au soleil au fur et à mesure des correctifs, non merci.


refuznik Abonné
Le 13/11/2019 à 13h06

Oui enfin depuis 3 ans, il faut acheter du AMD. Surtout que depuis 2 ans les dernières versions ne sont plus touchés par Spectre contrairement à Intel qui n’a pas revu son architecture.


Obidoub
Le 13/11/2019 à 13h14







refuznik a écrit :



Oui enfin depuis 3 ans, il faut acheter du AMD. Surtout que depuis 2 ans les dernières versions ne sont plus touchés par Spectre contrairement à Intel qui n’a pas revu son architecture.





Je suis actuellement sur du Ryzen 1700X mais j’ai pour projet d’en faire un serveur de virtualisation.

Du coup pour ma machine gaming je voulais prendre le CPU le plus costaud, c’est un kif. Mais du coup j’hésite.



Groupetto Abonné
Le 13/11/2019 à 13h46

Un 3700X devrait faire l’affaire pour jouer…les perfs sont bonnes, en moyenne 10% en dessous des 9700K / 9900K d’Intel.



Je vais passer à la caisse début décembre (j’attends le Cyber Monday, au cas où, on sait jamais <img data-src=" />).



Mais pour être franc, la raison pour laquelle on trouve moins de faille chez AMD, c’est peut-être juste que les hackers se concentrent sur les processeurs les plus courants (donc de l’Intel encore pour l’instant).


alex.d. Abonné
Le 13/11/2019 à 13h50







Obidoub a écrit :



Difficile de blâmer Intel, par définition une faille est un truc inévitable.



Une faille, par définition, c’est un truc mal conçu, donc c’est évitable.



Le point commun de toutes les failles récentes chez Intel, c’est une exécution spéculative conçue en dépit du bon sens.



LostSoul Abonné
Le 13/11/2019 à 14h52







alex.d. a écrit :



Une faille, par définition, c’est un truc mal conçu, donc c’est évitable.



Le point commun de toutes les failles récentes chez Intel, c’est une exécution spéculative conçue en dépit du bon sens.





le principe du spéculatif est par définition contraire au bon sens ;)



Obidoub
Le 13/11/2019 à 15h20







Groupetto a écrit :



Un 3700X devrait faire l’affaire pour jouer…les perfs sont bonnes, en moyenne 10% en dessous des 9700K / 9900K d’Intel.





Après avoir consulté quelques bench, je trouve qu’il n’apporte pas grand chose par rapport à mon 1700X <img data-src=" />

Le i9-9900K creuse un peu plus l’écart dans le gaming.



En passant, j’adorerai des benchmark sur INpact-hardware…



XXC Abonné
Le 13/11/2019 à 18h46







LostSoul a écrit :



le principe du spéculatif est par définition contraire au bon sens ;)



C’est quoi le bon sens ?

Exécuter de façon séquentielle, sans cache (pour être déterministe) ton code? On retourne au 386 alors ;)



Ces “failles” sont des sides channel attack exploitant les effet de bord de ce qui a permis l’explosion des performance.

Les fermer se fera donc au détriment des performances.



Maintenant pour une machine de gaming ou de calcul local, on s’en fout des ces failles.



Par contre, si c’est pour un serveur cloud, oui, il y a un problème. Comme dans toute colocations, les colocataires indélicats peuvent regarder par dessus ton épaule ;)






Ricard
Le 13/11/2019 à 19h18

Windows 10 sur du Intel. Combo. <img data-src=" />


Salamandar
Le 13/11/2019 à 22h08

Si tu veux faire un serveur de virtualisation, prends un Ryzen. Plus de cores, c’est très intéressant pour ça :)








XXC a écrit :



C’est quoi le bon sens ?







Par “bon sens”, on peut considérer qu’il entend “ce qui semble logique au premier abord”. De la même façon que la mécanique quantique est également contraire au bon sens, l’exécution spéculative est en quelque sorte une espèce de fonction d’onde qui se collapse quand on fait une observation : le processeur est simultanément dans un état où certaines instructions ont déjà été exécutées et dans un état où ces instructions n’ont pas encore été exécutées.



Bon, maître Capello Feynman me rappelera que l’analogie s’arrête là parce que ces deux états ne se superposent pas comme en mécanique quantique, l’état du processeur est décrit par des variables cachées et non par une incertitude intrinsèque.



Et donc le théorème de non clonage ne s’applique pas, et donc on peut observer l’état caché, et donc failles.



Hugues1337
Le 14/11/2019 à 10h02







Obidoub a écrit :



Difficile de blâmer Intel, par définition une faille est un truc inévitable.





N’importe quoi.



Et le fait qu’Intel met un embargo sur les failles de ce type c’est aussi non blâmable ?

Cadeau :https://mdsattacks.com/#ridl-ng



Obidoub
Le 14/11/2019 à 11h25

Si tu as connaissance d’une technique infaillible pour ne jamais avoir de failles, je pense que Intel sera très content de recevoir ton CV…


Hugues1337
Le 14/11/2019 à 13h06







Obidoub a écrit :



Si tu as connaissance d’une technique infaillible pour ne jamais avoir de failles, je pense que Intel sera très content de recevoir ton CV…





Moi j’espère surtout que t’es pas QA.



OlivierJ Abonné
Le 20/11/2019 à 13h34







Obidoub a écrit :



Mais moi qui comptait acheter du Intel en fin d’année, je me pose des questions. Acheter un gros CPU très cher pour ensuite voir ses performances fondre comme neige au soleil au fur et à mesure des correctifs, non merci.





Tu n’es pas obligé d’appliquer les correctifs si tu n’es pas une entreprise qui offre des VM.

En tant que particulier je me fiche de ces failles.







Obidoub a écrit :



En passant, j’adorerai des benchmark sur INpact-hardware…





J’utilise régulièrementhttps://www.cpubenchmark.net/singleThread.html même si l’indice n’est pas précis pour les performances selon les divers domaines ; sinon anandtech ou Phoronix font du bon boulot, en autres.







XXC a écrit :



C’est quoi le bon sens ?

Exécuter de façon séquentielle, sans cache (pour être déterministe) ton code? On retourne au 386 alors ;)





De façon déterministe à nouveau, note qu’on a les Atom (pas de “Out of order”, sauf dans les tous derniers je crois).









XXC a écrit :



Maintenant pour une machine de gaming ou de calcul local, on s’en fout des ces failles.





<img data-src=" />







33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :



l’exécution spéculative est en quelque sorte une espèce de fonction d’onde qui se collapse quand on fait une observation : le processeur est simultanément dans un état où certaines instructions ont déjà été exécutées et dans un état où ces instructions n’ont pas encore été exécutées. [..]





<img data-src=" />

Joli.



XXC Abonné
Le 20/11/2019 à 15h02







OlivierJ a écrit :



De façon déterministe à nouveau, note qu’on a les Atom (pas de “Out of order”, sauf dans les tous derniers je crois).



Pas besoins de faire de l’out of order pour ne pas être déterministe.

Le cache est la première source de non déterminisme introduite pour améliorer les perf.

Certaine attaques se base d’ailleurs sur la latence d’accès aux données en suivant quelle soit en cache ou pas.

Les caches (externes) sont apparus officiellement sur le 386.



Bon, je retourne a mon Z80, c’est plus sur <img data-src=" />




Obidoub
Le 20/11/2019 à 15h13







OlivierJ a écrit :



Tu n’es pas obligé d’appliquer les correctifs si tu n’es pas une entreprise qui offre des VM.

En tant que particulier je me fiche de ces failles.





Pas vraiment le choix avec Windows Update…







OlivierJ a écrit :



J’utilise régulièrementhttps://www.cpubenchmark.net/singleThread.html même si l’indice n’est pas précis pour les performances selon les divers domaines ; sinon anandtech ou Phoronix font du bon boulot, en autres.





Difficile de trouver quelque chose d’aussi carré que ce que faisait hardware.fr. Quant à Phoronix… c’est vraiment pas terrible pour les benchmark :/



M’enfin c’était surtout un clin d’oeil à NextINpact, depuis la mort de hardware.fr y’a un créneau à prendre <img data-src=" />



OlivierJ Abonné
Le 20/11/2019 à 16h21







XXC a écrit :



Pas besoins de faire de l’out of order pour ne pas être déterministe.

Le cache est la première source de non déterminisme introduite pour améliorer les perf.

Certaine attaques se base d’ailleurs sur la latence d’accès aux données en suivant quelle soit en cache ou pas.





Le fonctionnement du cache me paraît plus simple (et déterministe) qu’un truc comme le OoO. Tu as réellement des attaques autres que théoriques, sur le cache ?







XXC a écrit :



Les caches (externes) sont apparus officiellement sur le 386.





Qu’appelles-tu externes ? (et pas externes aussi d’ailleurs)







Obidoub a écrit :



Pas vraiment le choix avec Windows Update…





Ah oui, je pensais à Linux, très utilisé en datacenter et pour la virtualisation.







Obidoub a écrit :



Difficile de trouver quelque chose d’aussi carré que ce que faisait hardware.fr. Quant à Phoronix… c’est vraiment pas terrible pour les benchmark :/





AnandTech fait largement aussi bien que hardware.fr (que j’ai beaucoup lu), et même plus pro à mon avis (et explications plus fouillées, du moins pendant très longtemps) ; quant à Phononix, que leur reproches-tu ? Je trouve justement qu’ils ont des benchs assez complets, avec plein d’applications (de la vidéo, du zip, du jeu, etc.).



XXC Abonné
Le 20/11/2019 à 16h50







OlivierJ a écrit :



Le fonctionnement du cache me paraît plus simple (et déterministe) qu’un truc comme le OoO.



Le fonctionnement du cache est bien plus simple que l’OoO, mais ca ne le rends pas déterministe.

Le temps de réponse de ton cache dépends de son contenu et de ce que tu temande. Et en environnement multitâche, tu ne contrôle plus rien.

Même avec un seul et unique process, le temps pour parcourir une liste chainée (qui ne tiens pas en cache) n’est pas prévisible. Le temps d’acces a chaque element depends de ceux que tu as lu avant, et qui ont pris la place d’un autre.

En fait, le seul cache qui soit déterministe, c’est celui qui est assez grand pour contenir l’ensemble de ton code et tes données, et encore, seulement une fois l’ensemble dans le cache.









OlivierJ a écrit :



Tu as réellement des attaques autres que théoriques, sur le cache ?



Je ne sais pas si je vais pouvoir retrouver ça, mais de mémoire c’était un PoC d’extraction de clef privée. Le process attaquant saturait le cache pour virer la clef / le code du cache, puis après avoir laisser tourner le process cible, vérifiait le temps d’accès à la mémoire de celui ci. L’algo étant connu, il en déduisait les différent branchement et donc la clef.







OlivierJ a écrit :



Qu’appelles-tu externes ? (et pas externes aussi d’ailleurs)



Externe car sur la carte mère et non dans de processeur lui même.



OlivierJ Abonné
Le 20/11/2019 à 17h09







XXC a écrit :



Je ne sais pas si je vais pouvoir retrouver ça, mais de mémoire c’était un PoC d’extraction de clef privée. Le process attaquant saturait le cache pour virer la clef / le code du cache, puis après avoir laisser tourner le process cible, vérifiait le temps d’accès à la mémoire de celui ci. L’algo étant connu, il en déduisait les différent branchement et donc la clef.





J’ai souvenir vers 2000 (chez Schlumberger qui faisait des cartes à puce) qu’on développait déjà des variantes des algorithmes, pour qu’il s’exécute en temps constant (et autres modifs) pour que même en espionnant la puce et sa consommation, on ne puisse déduire la clé.







XXC a écrit :



Externe car sur la carte mère et non dans de processeur lui même.





Est-ce que ça change quelque chose à l’aspect non déterministe ?

(pas l’impression a priori)



XXC Abonné
Le 20/11/2019 à 18h24







OlivierJ a écrit :



J’ai souvenir vers 2000 (chez Schlumberger qui faisait des cartes à puce) qu’on développait déjà des variantes des algorithmes, pour qu’il s’exécute en temps constant (et autres modifs) pour que même en espionnant la puce et sa consommation, on ne puisse déduire la clé.





A cette époque les cartes a puces n’avaient pas de cache (Z80 / 8051 / ARM7TDMI principalement) et effectivement en assurant un temps constant on évite une partie des attaques side channel.







OlivierJ a écrit :



Est-ce que ça change quelque chose à l’aspect non déterministe ?

(pas l’impression a priori)



Non, c’est juste qu’a l’époque la RAM rapide nécessaire n’avaient pas un bon rendement et coutaient cher.



Obidoub
Le 21/11/2019 à 10h54







OlivierJ a écrit :



Ah oui, je pensais à Linux, très utilisé en datacenter et pour la virtualisation.





Mon besoin primaire c’est du gaming… donc sous Windows.

Sous linux j’ai toujours mon i7 de 2013, toujours au top…







OlivierJ a écrit :



quant à Phononix, que leur reproches-tu ?





Ça dépend des articles… je leur reproche de faire souvent des benchmark brut sans élément de comparaison, donc peu utiles. Et puis c’est souvent centré sur Linux donc peu intéressant si tu t’intéresse aux bench gaming.



OlivierJ Abonné
Le 21/11/2019 à 11h06







Obidoub a écrit :



Mon besoin primaire c’est du gaming… donc sous Windows.





Donc tu devrais t’en moquer complètement de ces failles, non ?







Obidoub a écrit :



Ça dépend des articles… je leur reproche de faire souvent des benchmark brut sans élément de comparaison, donc peu utiles. Et puis c’est souvent centré sur Linux donc peu intéressant si tu t’intéresse aux bench gaming.





J’avais en tête que justement ils testent souvent les performances des cartes graphiques et des jeux, et parfois sur plusieurs OS.

Effectivement l’orientation principale est Linux.



fred42 Abonné
Le 21/11/2019 à 17h04







OlivierJ a écrit :



Donc tu devrais t’en moquer complètement de ces failles, non ?







Il devrait s’en moquer sauf que Windows ne laisse plus le choix d’appliquer ou non un correctif comme il l’a dit plus haut, donc il subit des pertes de perf inutiles pour lui.



OlivierJ Abonné
Le 22/11/2019 à 12h58

Vi vi, j’avais compris, mais à moitié oublié entretemps, pardon :-)


Fermer