Dans le sillon de Spectre, une nouvelle vulnérabilité touchant... tous les ordinateurs du monde (ou presque)

03 mai 2021 à 12h32
36
© Fotolia
© Fotolia

Une nouvelle faille de sécurité de type Spectre menace la sécurité de nos ordinateurs. Elle touche les processeurs AMD récents et ceux d'Intel de la dernière décennie. Un correctif engendrerait une diminution drastique des performances des CPU.

En 2018, nous apprenions que des vulnérabilités touchaient de très nombreux modèles de processeurs équipant nos PC. Ces séries de failles sont connues sous les noms Spectre et Meltdown. Exploitées, elles peuvent permettre à des assaillants de voler les données d'un ordinateur et d'en prendre le contrôle. Une nouvelle variante de Spectre a été récemment identifiée.

Une faille du cache micro-op

Des chercheurs de l’Université de Virginie et de l’Université de Californie à San Diego sont à l'origine de cette découverte, qui concerne une fois encore aussi bien les processeurs Intel que les CPU AMD.

La faille de sécurité consiste en l'exploitation du cache micro-op. Ce dernier enregistre les instructions simples, permettant au processeur de les traiter des instructions simplement et rapidement lors du processus d'exécution, résultant en un gain de performances du CPU.

Cette nouvelle vulnérabilité de type Spectre touche ainsi tous les processeurs ayant recours à un cache micro-op, c'est-à-dire les références Intel depuis 2011 et celles d'AMD depuis 2017.

Un correctif engendrerait une chute des performances de nos CPU

Les nombreux patchs de sécurité et correctifs qui ont été déployés suite aux révélations sur les premières failles Spectre sont inefficaces dans ce cas, car les premières vulnérabilités agissaient à un niveau tardif du processus d'exécution spéculative, alors que cette dernière agit plutôt à la source.

Comme les autres failles Spectre, cette vulnérabilité exploite l'exécution spéculative, qui permet au processeur de préparer et d'accomplir des tâches qui n'ont pas encore été demandées pour qu'elles s'exécutent rapidement une fois qu'elles sont requises.

La vulnérabilité permet de tromper le CPU et de lui faire exécuter des instructions de manière à ouvrir un passage aux hackers vers le système et donc d'accéder à des données confidentielles.

Les chercheurs estiment cependant que cette faille de sécurité est compliquée à exploiter, et que la corriger passerait nécessairement par une baisse sensible des performances des processeurs. Intel et AMD pourraient donc choisir de ne pas couvrir cette vulnérabilité.

Source : Tech Xplore

Alexandre Schmid

Gamer et tech enthusiast, j’ai fait de mes passions mon métier. Diplômé d’un Master en RNG sur Hearthstone. Rigole aux blagues d’Alexa.

Lire d'autres articles

Gamer et tech enthusiast, j’ai fait de mes passions mon métier. Diplômé d’un Master en RNG sur Hearthstone. Rigole aux blagues d’Alexa.

Lire d'autres articles
Vous êtes un utilisateur de Google Actualités ou de WhatsApp ? Suivez-nous pour ne rien rater de l'actu tech !
google-news

A découvrir en vidéo

Rejoignez la communauté Clubic S'inscrire

Rejoignez la communauté des passionnés de nouvelles technologies. Venez partager votre passion et débattre de l’actualité avec nos membres qui s’entraident et partagent leur expertise quotidiennement.

S'inscrire

Commentaires (36)

UncleJul
Ne pas couvrir cette faille ? Allez expliquer ça au secteur bancaire.
Yves64250
Je viens d’acheter un i5 6 cores ,ça veut dire que j’aurais encore un processeur a performances diminuées?
Peter_Vilmen
La partie de l’article qui explique comment la faille est exploitée est manquante, alors que c’est l’information la plus importante pour les lecteurs.
nicgrover
Peut-être pour ne pas donner de mauvaises idées aux hackers^^
dredd
Personnellement, j’avoues que je m’en fous et je viens pas sur un site généraliste pour ce genre de chose. 99% des lecteurs de Clubic ne comprendraient pas la moitié des explications et les deux tiers du % restant ne pourrait pas expérimenter la chose par manque de labo capable de le faire.<br /> Il y a pléthore de sites pointus qui expliquent probablement en détail et d’ailleurs, il suffit de se référer à la source indiquée par l’article de Clubic
sandalfo
Bof. Pour exploiter cette faille il faut avoir accès en écriture au cache micro-op du CPU. Autant dire que vous êtes depuis longtemps dans le système. Je m’interroge sur les possibilités d’exploiter cette faille à distance sans un accès admin.
Valmont69
C’est pour cela, mais pas seulement, que ce secteur (et d’autres) utilisent encore beaucoup des systèmes qui sont équipés de processeurs IBM Power (IBM Power Systems).
santec
seulement sur x86 ?! quand et il sur ARM
Kratof_Muller
Avant que cette faille soit documentée et repertoriée CVE dans un outil de test de pénétration, il faudrait que les découvreurs de cette faille en laisse tous les détails fuiter.
brice_wernet
1- La plupart de ces attaques nécessite d’exécuter un code très gourmand qui sature un CPU - ça crée une alerte de toutes façons<br /> 2- La plupart de ces attaques nécessite ou est fortement aidée par l’hyperthreading - il suffit d’allouer les VM en faisant en sorte que les paires de CPU hyperthreadés soient ensemble pour qu’une VM puisse très difficilement surveiller l’autre<br /> 3- On ne mélange pas les VM entre elles, on a normalement des infra physiquement séparées pour le sensible et le reste - et rentrer dans le sensible est compliqué…<br /> Donc ces failles existent, mais ne sont pas faciles à exploiter en entreprise en fait. Elles sont plus inquiétante pour les serveurs qu’on ne maîtrise pas: ceux qu’on loue dans le cloud…
kijuhy
Manque à préciser qu’un openBSD par exemple n’a jamais implémenté ces fonctionnalités car le boss avait déjà des doutes sur les problèmes de sécurité il y’a 10 ans de cela.<br /> Donc openBSD n’est pas du tout vulnérable.
ultrabill
Clubic est connu pour être la source d’information technique des hackers, évidement…
Kriz4liD
Attendons les patchs Intel et AMD pour comparer la baisse de performance.
Bombing_Basta
dredd:<br /> 99% des lecteurs de Clubic ne comprendraient pas la moitié des explications et les deux tiers du % restant ne pourrait pas expérimenter la chose par manque de labo capable de le faire.<br /> Ce n’est pas parce-que la masse est à tendance neuneu de la tech (voir plus), qu’il ne faut penser qu’à eux.
wackyseb
Fallait de suite prendre un 24 coeurs au lieu d’un 6.<br /> Et du Intel en plus… Ah ces jeunes je te jure …<br /> PS : Ceci est une blague hein !!! Pas taper
John.Reese
Je ne comprends pas. Vous dites au début «&nbsp;engendrerait une diminution drastique des performances des CPU&nbsp;» et à la fin «&nbsp;la corriger passerait nécessairement par une baisse sensible des performances des processeurs&nbsp;». Vous dites l’inverse. C’est lequel des deux?
soaf78
Wow tu connais 99% des lecteurs de ce site…<br /> Et tu enlèves 99% et il te reste 2/3 (soit 66,6%)<br /> Dingue !
Bombing_Basta
John.Reese:<br /> baisse sensible des performances des processeurs<br /> C’est peut-être à comprendre comme un euphémisme.<br /> «&nbsp;Pourquoi t’as la main plâtrée ?!?&nbsp;»<br /> «&nbsp;Hier, je me suis écrasé le doigt, j’ai eu 4 fractures !&nbsp;»<br /> «&nbsp;T’as eu mal ?&nbsp;»<br /> «&nbsp;Sensiblement…&nbsp;»<br /> soaf78:<br /> Et tu enlèves 99% et il te reste 2/3 (soit 66,6%)<br /> Dingue !<br /> Autant sur le début de ton com je suis plutôt du même avis, autant sur la suite tu te fails…<br /> Il a dit «&nbsp;les 2/3 du % restant&nbsp;»…<br /> Deux tiers de 1% ça fait 0.66%…
silversword666
Non c’est la même chose : Un correctif engendrerait une diminution drastique des performances des CPU = la corriger passerait nécessairement par une baisse sensible des performances des processeurs
silversword666
Ceux qui ne se considèrent pas comme neuneus de la tech peuvent prendre la peine de lire la source de l’article…
silversword666
Le problème se situe sur tous les PC Intel des 10 dernières années, et AMD de moins de 4 ans. Il n’est pas question de serveurs ici, encore moins de VM.
Blackalf
@Angelus33075 message supprimé pour le motif message non-constructif/hors-sujet.
John.Reese
Tu viens de dire encore une fois l’inverse sensible c’est l’inverse de drastique. Définition du Larousse : Drastique = D’une rigueur contraignante ; très rigoureux, draconien.<br /> C’est bien l’inverse de sensible qui n’est pas contraignant, très rigoureux et draconien puisqu’il se fait peu ressentir.
dredd
Sauf que Clubic n’est pas un site élitiste et encore une fois, t’as la source et tout y est expliqué. Help yourself comme on dit.
dredd
les deux tiers du % restant<br /> Les math c’est peut-être ton fort, mais la lecture, je ne serai pas aussi catégorique.
soaf78
J’avoue, j’ai répondu un peu vite…
brice_wernet
Si, il est question de tous les serveurs en Xeon notamment, ou des threadrippers récents par exemple.<br /> On pourrait sur des sites en VPS mutualisés voler les infos des autres.
brice_wernet
Il est vulnérable à certaines formes de variations de spectre/meltdown, tout ne dépend pas de l’hyperthreading. Dans le cas présent, l’hyperthreading ne semble pas obligatoire.<br /> Il n’y a pas de magie: ces attaques ressemblent aux attaques de puces de cartes bleues: ils arrivent à savoir ce que fait la carte et quelles données elle manipule (les valeurs!!!) en analysant les micro évolutions de la consommation de la carte…<br /> Un peu comme l’attaque de la mémoire dite de «&nbsp;hammering&nbsp;»: à force d’écrire, ils arrivent à induire un «&nbsp;bruit&nbsp;» qui va changer la valeur d’un autre emplacement mémoire…<br /> On a aussi eu des POC sur des attaques sur la mémoire des cartes graphiques: ils détectaient des restes des images de navigateur et les extrayait car la mémoire graphique n’était pas forcément vidée totalement)<br /> Bref, toutes les «&nbsp;optimisations&nbsp;» qui permettent de grapiller quelques précieux % de perfs permettant de faire remonter les ventes finissent pas être un problème de sécurité.<br /> Je me rappelle le 1er document spectre/meltdown : sur un i5 3570K, le POC permettait d’extraire 40 octets à la seconde … Sur un skylake, 100ko/s: les optimisations avaient énormément optimisé les «&nbsp;failles&nbsp;».
Blap
Il a raison, c’est toi qui comprend mal le sens de la phrase :<br /> «&nbsp;une baisse sensible&nbsp;» = «&nbsp;une baisse importante&nbsp;».<br /> C’est peu ou prou la meme chose.<br /> Et «&nbsp;peu ou prou&nbsp;» veut dire «&nbsp;plus ou moins&nbsp;» : D
newseven
Un correctif engendrerait une chute des performances de nos CPU<br /> Un chance que les processeurs sont de plus en plus puissant donc l’impacte ne devrait pas avoir trop d’importance .<br /> alerte générale j’ai perdu un FPS dans mon jeu de Fortnite c’est inacceptable en 1080 p .<br /> Quand on se retrouve devant un problème .<br /> Ce n’est pas normale de le confronter pour le résoudre !
kijuhy
Je ne parlais pas uniquement de l’hyperthreading si vous voulez plus de détail :<br /> «&nbsp;Tom Interviews Theo de Raadt of the OpenBSD Project&nbsp;» sur youtube en parle de manière accessible.
silversword666
Bien sûr que les serveurs sont aussi concernés mais si tu fais la proportion serveurs / PC dans le monde, la menace est clairement côté PC. C’est évident que les serveurs seront patchés dans le cadre du patch management de l’entreprise si un correctif devait être disponible. Pas certain que tous les particuliers fassent la même démarche à moins de les y forcer.
wackyseb
Euh, allez dictionnaire.<br /> Ah Zut, c’est pareil. Dans les 2 cas, il y a baisse<br /> Sensible : qui se remarque<br /> Drastique : non négligeable<br /> Ah bah oui c’est pareil. Dingue cette affaire !
wackyseb
Tout a fait d’accord .<br /> Ah je me suis coupé avec une feuille =&gt; supprimons le papier.<br /> Ah il y a eu 1 accident grave en 40 ans sur une route en ligne droite. =&gt; allez on met un radar, des chicanes, on replante les platanes le long de la route et on fait des contrôles routiers pendant 3 mois pour sensibiliser<br /> Euh, un peu excessif de toujours bosser en action/réaction.<br /> Là il y a un risque « potentiel ». Ok, est ce que la solution doit forcément être matérielle, est ce qu’on n’arriverait pas à voir le comportement de la signature de l’attaque. Est-ce qu’on est obligé de boucher cette vulnérabilité pour tout le monde.<br /> En voilà des questions avant de réagir de suite.<br /> On vois le résultat avec spectre.<br /> Et si on passait tous en ARM d’ici moins de 5 ans<br /> Voir un saut dans l’inconnu avec du RISC (a l’échelle d’un PC) ou carrément sur une autre alternative encore nouvelle et expérimentale.
brice_wernet
Les solutions de OpenBSD «&nbsp;améliorent&nbsp;» la protection en rendant plus rare les cas possible de copie de données, mais ce n’est pas impossible.<br /> En gros, ils ont désactivé l’hyperthreading par défaut? On y perd en perf dans la majorité des cas. Séparer les tables de pages user/kernel? On se retrouve sur une structure mémoire proche de ce qu’on aurait avec un hyperviseur.<br /> Guess what? L’attaque marche aussi sur les systèmes hypervisés et c’est bien le problème. OpenBSD a compliqué l’attaque car on peut difficilement déduire ce qu’on a lu comme données, mais on les a lues quand même.<br /> La seule protection, c’est de ne pas mélanger dans les processus d’un serveur, qu’il soit sous Windows/Linux/OpenBSD/un hyperviseur: processus «&nbsp;vérifiés&nbsp;» et processus «&nbsp;non vérifiés&nbsp;»
juju251
Bombing_Basta:<br /> Ce n’est pas parce-que la masse est à tendance neuneu de la tech (voir plus), qu’il ne faut penser qu’à eux.<br /> Et sinon, t’exprimer sans être condescendant avec tout le monde, c’est quelque chose que tu sais faire ou non ?<br /> PS : Mon message n’appelle pas de réponse, en revanche, j’apprécierais que tu arrives à t’exprimer avec plus de politesse à l’avenir.
Bombing_Basta
Alors je ne répondrai pas…<br /> #LoveBubbles
kijuhy
Sur openBSD il n’y a aussi pas de cross-SMT thread qui est la base de la faille dont fait objet l’article… Ca ressemblerai un peu à de la magie d’exploiter une faille sur un système qui ne comporte pas les éléments faillibles.
brice_wernet
OK pour le cross SMT, mais le papier détaille 3 moyens, pas un seul. Et je disais juste que OpenBSD «&nbsp;bloque&nbsp;» certaines variantes, mais pas tout, comme les nouveaux schedulers bloquent ces variantes en ne permettant pas à des processus différents d’utiliser le même coeur sur 2 fils SMT sur d’autres OS et hyperviseurs (mais en conservant une partie du gain de perfs du SMT)
kijuhy
Mais les trois moyens reposent sur le cross-SMT thread donc openBSD n’est pas vulnérable et puis c’est tout c’était mon premier message. OpenBSD jusque la bloque toutes les variantes justement.
brice_wernet
Je ne l’ai pas compris comme cela, il m’a semblé que les 2 autres n’ont pas besoin de cross SMT. Et non, jusque là, OpenBSD ne bloque pas toutes les variantes. Il bloque les plus faciles à exploiter c’est vrai. Tout comme le fait d’avoir un CPU sans SMT (i5 6C/6T) ou un scheduler qui interdit de mélanger les VMs/les processus au sein d’un même couple SMT.
kijuhy
Ok je crois que tu as raison pour les deux autres, elles ne sont pas liées au SMT, mais à voir plus tard si openBSd est oui ou non vulnérable.<br /> Par contre le truc qui est certain c’est qu’il n’y a toujours pas eu de CVE pour ces problèmes ni même un POC, pas mal d’expert doutent de l’utilisation concrète de la «&nbsp;trouvaille&nbsp;».<br /> Au plaisir
tfpsly
@clubic Une autre faille touchant les CPU Intel et AMD :<br /> Ars Technica<br /> A new vulnerability in Intel and AMD CPUs lets hackers steal encryption keys<br /> Hertzbleed attack targets power-conservation feature found on virtually all modern CPUs.<br />
Palou
tfpsly:<br /> Une autre faille touchant les CPU Intel<br /> … ET les CPU AMD !<br /> Pourquoi cibler spécialement Intel seulement ?
tfpsly
J’ai lu trop vite un résumé au boulot
Voir tous les messages sur le forum
Haut de page

Sur le même sujet