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

03 mai 2021 à 12h32
36
Fotolia Meltdown Spectre
© 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

Modifié le 03/05/2021 à 12h32
Soyez toujours courtois dans vos commentaires.
Respectez le réglement de la communauté.
36
25
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.
clockover
Tu es sur Clubic ^^
clockover
Ahaha ^^
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
Voir tous les messages sur le forum

Lectures liées

Un japonais utilise de l'IA pour
Microsoft a (encore) signé un pilote qui était en fait un logiciel malveillant
Campus Cyber, le vaisseau amiral de la cybersécurité française, ouvrira ses portes en février 2022
Cybersécurité : les entreprises délaissent le mot de passe et se tournent vers l'authentification biométrique
Guerre de l'information : le ministère des Armées se dote d'une
Google communique sur les attaques informatiques qui visent les youtubeurs depuis 2019
L'Argentine victime d'un piratage hors norme, les données de Lionel Messi dans le lot
La Chine et la Russie soupçonnées d'ingérences numériques, ces mesures qui vont permettre de surveiller la campagne présidentielle
Une vulnérabilité critique découverte dans un langage de programmation utilisé pour des mods de jeux vidéo
Plusieurs vulnérabilités ont été trouvées dans WP Fastest Cache, un plugin WordPress populaire
Haut de page