Récit de la découverte effarante des failles Spectre et Meltdown

Nicolas Furno |

L’année a commencé sur les chapeaux de roue dans le monde de l’informatique ! Dès le 2 janvier, on découvrait l’existence d’une faille de sécurité vieille de dix ans touchant tous les processeurs Intel. Ce n’était que la partie émergée de l’iceberg ; on découvrait le lendemain l’existence de deux failles, surnommées Meltdown et Spectre, concernant tous les processeurs récents (lire : Meltdown et Spectre : tout savoir sur les failles historiques des processeurs).

Les correctifs sont en train d'arriver, au moins pour Meltdown, une faille qui ne touche que les processeurs Intel, mais qui est aussi très simple à exploiter. Corriger Spectre nécessitera davantage de temps, puisque c’est une faille liée à la conception même de tous les processeurs récents, mais il y a aussi des solutions à court terme pour limiter son impact — Apple a déployé des patchs sur macOS comme sur iOS.

Maintenant que l’on commence à respirer un petit peu, on peut revenir sur l’un des aspects les plus fascinants de ces failles. Il n’y a pas qu’un seul chercheur en sécurité qui a déniché Spectre et Meltdown, ni même une seule équipe ; en l’espace de quelques mois, ce ne sont pas moins de quatre personnes ou équipes qui ont trouvé ces failles, et ce en parallèle.

L’une des équipes de chercheurs qui a trouvé la faille Meltdown. (montage MacGeneration) Cliquer pour agrandir

Comment est-ce possible ? Des articles de Wired et de Bloomberg permettent d’en savoir plus sur ces découvertes. C’est passionnant, mais aussi un petit peu inquiétant… on vous dit tout.

Une faille trop énorme pour être inconnue, pensent des chercheurs

La découverte d’une faille de sécurité prend toujours du temps. C’est encore plus vrai pour des failles aussi importantes que celles qui ont été identifiées dans tous les processeurs modernes. Les chercheurs qui ont finalement découvert Meltdown et Spectre ont travaillé à partir des résultats d’autres chercheurs remontant jusqu’au milieu des années 2000.

Le nom de Yuval Yarom, chercheur à l’université d’Adélaïde en Australie, est présent dans la liste des personnes qui ont déniché Spectre. Pourtant, il n’a pas mené de recherches sur le sujet en 2017, mais ses trouvailles en 2005 contiennent plusieurs idées de base qui ont servi à exploiter les faiblesses des processeurs modernes.

Le papier académique qui présente la faille de sécurité Spectre liste les noms de dix chercheurs en sécurité qui ont commencé pour la plupart à aborder le problème séparément. Cliquer pour agrandir

C’est en 2013 que la première pierre est posée avec la découverte de la faille KASLR, une vulnérabilité qui permet d’accéder au modèle du noyau depuis le système d’exploitation. C’est loin d’être aussi grave que les failles Spectre et Meltdown, puisqu’il n’y a pas d’accès aux données elles-mêmes. C’est plutôt une menace théorique, un accès aux méthodes utilisées par le noyau pour protéger les données en questions. Mais KASLR est la base utilisée pour une partie des découvertes réalisées en 2017.

À l’occasion de la conférence Black Hat de Las Vegas en août 2016, une équipe de chercheurs de l’université de Graz, en Autriche, présente un moyen de protéger les processeurs Intel contre la faille KASLR. La technique, nommée KAISER, ne bloque pas l’accès à la mémoire réservée au noyau, mais elle masque la position de la mémoire pour éviter les attaques. Cette approche présente toutefois l’inconvénient de réduire les performances et à ce stade, personne dans l'équipe ne croit à une faille plus large qui permettrait d'accéder aux données.

Les trois chercheurs en sécurité de l’université de Graz. Cliquer pour agrandir

L’un des chercheurs de Graz, Daniel Gruss, a l’occasion d’échanger avec Anders Fogh, qui pense le contraire. Pour le dire autrement, ce chercheur considérait la possibilité des failles Spectre et Meltdown plus d’un an et demi avant leurs révélations, mais il n’avait que des doutes et aucune preuve.

C’est pour cette raison qu’il essaie de convaincre d’autres chercheurs de l’aider, mais ses confrères restent sceptiques. Si une telle faille existait, les fabricants de processeurs l’auraient certainement trouvée et ils l’auraient corrigée ! Cette faille semble tellement énorme que les trois chercheurs de Graz n’envisagent pas de lui accorder du temps.

Anders Fogh ne lâche pas son idée toutefois et c’est en janvier 2017 qu’il entrevoit la possibilité d’utiliser l’exécution spéculative, qui permet d’accélérer les processeurs en essayant de deviner les prochaines commandes et en les exécutant sans attendre d’en recevoir l’ordre, pour élargir la brèche. Le chercheur allemand considère que cette fonction pourrait servir à déjouer les sécurités mises en place pour protéger le noyau et ainsi extraire des données.

Il pressent qu'un programme pourrait accéder à une partie de la mémoire réservée au noyau, avant même que le processeur n’ait le temps de vérifier s’il a bien le droit de le faire. C’est l’une des conséquences de l’exécution spéculative : parfois, le processeur se trompe et il exécute des commandes qu’il n’aurait pas dû. Ces erreurs de spéculation sont rapidement effacées, mais le programme peut puiser dans le cache, une section de la mémoire qui sert à stocker des données fréquemment utilisées pour accélérer encore les opérations.

Le logo du blog d’Anders Fogh. Cliquer pour agrandir

Les détails techniques sont complexes, mais l’idée est assez simple à comprendre. Anders Fogh imagine qu’un programme pourrait embrouiller l’exécution spéculative des processeurs modernes pour les forcer à afficher des informations qui doivent rester confidentielles. Il évoque cette possibilité lors d’une conférence donnée en début d’année, puis publie un article sur son blog à la fin du mois de juillet.

Cet article est important, car il décrit assez largement la faille Meltdown, mais il n’a aucun impact immédiat. Et pour cause, il reste uniquement théorique et n’apporte aucune preuve. En effet, même si ce chercheur a les bonnes intuitions sur les processus qui serviront à l’attaque, il ne parvient pas à les mettre en œuvre. À la fin de son article, il mentionne en passant une autre recherche dans la même veine et décrit ce qui sera la faille Spectre, la qualifiant à ce stade de « boîte de Pandore » par l’ampleur qu’elle pourrait avoir.

Un intérêt soudain et suspect pour KAISER

Entre la fin de l’été 2017 et le début de l’automne, il se passe quelque chose d’étonnant dans la communauté Linux. KAISER, le patch créé par les trois chercheurs de l’université de Graz pour combler la faille KASLR, commence à intéresser Google, Amazon et Microsoft et les autres acteurs majeurs du cloud. Ils essaient de convaincre les développeurs du noyau Linux d’intégrer le patch et surtout, ils ne veulent pas dire pourquoi.

D’abord flattés, les chercheurs suspectent vite qu’il y a quelque chose de louche et que les motivations derrière l’adoption de KAISER sont importantes. Surtout que leurs estimations d’impact sur les performances étaient fausses, et pas qu’un peu. Les premiers tests montrent qu’il peut y avoir des baisses de l’ordre de 30 % dans certains cas, ce qui est énorme dans l’univers des serveurs.

Un des exemples les plus spectaculaires de l’impact de Meltdown sur les performances : celui d’Epic Games, éditeur de jeux qui fait tourner de nombreux serveurs. Cliquer pour agrandir

Pourquoi s’entêter à vouloir intégrer KAISER dans ces conditions ? Les chercheurs autrichiens font alors le lien avec les recherches d’Anders Fogh et suggèrent que leur patch est en fait utilisé pour combler une faille beaucoup plus sérieuse dans les processeurs. Pour la première fois, ils enquêtent sérieusement et testent les suggestions de leur confrère pour lever le lièvre.

Très peu de temps après, les trois spécialistes mettent au point un concept qui prouve l’existence de la faille Meltdown. Ils créent un programme qui affiche toutes les données du noyau, des informations qui restent en théorie parfaitement masquées. Leur première réaction est horrifiée :

C’était vraiment, vraiment flippant. Vous ne vous attendez pas à lire vos conversations privées dans un programme qui n’a aucune permission pour accéder aux données.

Voici à quoi ressemble le programme développé par l'équipe. Ce script exploite la faille de sécurité pour lire les données du noyau, puis les affiche sous la forme de code machine, avant de les traduire en texte lisible. On y voit de tout, des textes affichés sur l’écran, des mots saisis sur l’ordinateur et aussi tous les mots de passe utilisés, en clair.

La surprise : Intel était déjà au courant

Face à la gravité de leur découverte, les chercheurs de Graz réagissent au plus vite. Dès le lendemain, ils envoient un message à Intel pour révéler l’existence de la faille. Première surprise, l’entreprise ne répond pas immédiatement. Une bonne semaine s'écoule avant la réponse.

Mais la plus grosse surprise, c'est le contenu du message. Intel connaissait déjà l’existence de cette faille, et qui plus est ils n’étaient pas les premiers à les avertir, mais les quatrièmes. Comment était-ce possible ?

Image de base : Christiaan Colen (CC BY-SA 2.0) Cliquer pour agrandir

L’université de Graz a été devancée de quelques semaines par Thomas Prescher, un chercheur en sécurité allemand qui travaille pour Cyberus Technology. C’est dans le courant du mois de novembre qu’il s’intéresse à la théorie d’Anders Fogh. Il explique être tombé par hasard sur l’article de blog et avoir essayé à son tour de créer la preuve que son confrère n’avait pas réussi à trouver. Il découvre la faille Meltdown peu après et il alerte Intel dans la foulée. Mais lui aussi reçoit une réponse l’informant que la faille était déjà connue.

Avant l’université de Graz, avant Cyberus Technology et même avant l’article d’Anders Fogh, les failles Meltdown et Spectre avaient été découvertes par Jann Horn. Cet employé de Google travaille dans le cadre de Project Zero, une équipe spécialisée dans la découverte de failles « zero day », des failles inconnues des fabricants. C’est en juin qu’il découvre Meltdown et Spectre.

Comment ce chercheur de 22 ans a-t-il pu trouver les failles seul et avant tout le monde ? Si vous lui posez la question, Jann Horn vous répondra simplement : en lisant le manuel. Ses découvertes commencent fin avril, alors qu’il travaille avec un collègue sur un programme qui dépend du fonctionnement précis des processeurs Intel et en particulier de l’exécution spéculative.

C’est en créant ce programme et en lisant la documentation qu’il réalise que des informations censées rester secrètes peuvent se retrouver par accident dans le cache du processeur et ainsi être récupérées. En théorie, il est envisageable de récupérer par ce biais les données que le processeur doit protéger. Le chercheur commence alors à s’intéresser plus spécifiquement à cette hypothèse et il met au point, en quelques jours seulement, une technique qui exploite la faille qui sera connue plus tard sous le nom Spectre.

Il informe Intel, AMD et ARM de ses découvertes le premier juin, tout en continuant à travailler sur le sujet. Trois semaines plus tard, il découvre aussi la faille Meltdown et informe cette fois seulement Intel, puisque c’est le seul acteur concerné. Le fondeur était ainsi au courant dès l’été et les travaux commencent très vite pour trouver la parade. Ce qui explique pourquoi à l’automne plusieurs acteurs militent pour adopter KAISER, et pourquoi Apple avait déjà bloqué la faille Meltdown dans High Sierra à la fin de l’année.

Pour être complet, le quatrième acteur impliqué est Paul Kocher, chercheur en sécurité américain qui a profité d’un congé sabbatique pour enquêter sur les processeurs. Comme Anders Fogh, il a l’intuition que les techniques employées par les fabricants pour accélérer leurs processeurs se font au détriment de la sécurité. Il parvient à démontrer l’existence de Spectre courant septembre, en se concentrant lui aussi sur l’exécution spéculative.

Qui d’autre connaissait la faille ?

En l’espace de quelques mois, quatre chercheurs ou équipes de chercheurs ont réussi à démontrer l’existence d’une faille de sécurité qui touche tous les processeurs depuis plusieurs années. La coïncidence est troublante, mais surtout, une question embarrassante se pose vite : est-ce que quelqu'un d’autre connaissait ces failles, mais n’a rien dit ?

Impossible de le savoir avec certitude, mais Paul Kocher ne serait pas surpris d’apprendre que des services de renseignement connaissaient et exploitaient ces failles le plus discrètement du monde. La NSA a indiqué au Washington Post n’avoir aucune connaissance des failles, mais même si c’était le cas ils ne l’avoueraient probablement pas. Et puis la NSA est loin d’être la seule agence de renseignement et peut-être qu'un autre pays était au courant… On ne sait pas.

L’ancien centre de surveillance de la NSA de Teufelsberg, à côté de Berlin. Il est abandonné depuis la fin de la Guerre froide. Image Dennis Skley (CC BY-ND 2.0). Cliquer pour agrandir

Cette découverte simultanée ne surprend pas les spécialistes du domaine en tout cas. Il y a des tendances dans le monde de la sécurité informatique qui font que plusieurs personnes vont suivre plus ou moins naturellement les mêmes pistes. Dans le cas de Spectre et Meltdown, les travaux d’Anders Fogh ont probablement influencé plusieurs chercheurs, même si ce n’est pas le cas pour Jann Horn. Ce dernier a indiqué sur Twitter s’être inspiré de recherches antérieures pour trouver Spectre. Elles sont publiques depuis l’automne 2016 et si elles ont permis à un chercheur de trouver ces vulnérabilités, elles ont peut-être servi à d’autres.

Impossible de répondre, mais cette crainte peut expliquer l’embargo imposé par Intel. C’est la règle tacite dans le milieu ; les chercheurs laissent aux acteurs concernés le temps de corriger leurs failles avant de publier leurs recherches. Étant donnée l’ampleur de Spectre et Meltdown, Intel a demandé un délai nettement plus long que la normale et l’entreprise comptait tenir le secret jusqu’au 9 janvier 2018. Son idée était apparemment de mitiger la mauvaise nouvelle avec l’ambiance de fête du CES qui se déroulait la même semaine, mais cela ne s’est pas passé comme prévu. The Verge revient sur cet embargo de plusieurs mois et son arrêt prématuré.

Il n’y a pas que les chercheurs de Graz qui ont été alertés par les modifications du noyau Linux, de nombreux observateurs ont aussi noté ces changements en profondeur et non justifiés. Pour maintenir l’embargo, le noyau Linux a été modifié avec des commentaires partiels, ce qui est inhabituel. Autre chose étrange, une modification à la dernière minute par Linus Torvalds, créateur du noyau Linux, sans passer par le processus classique de validation.

Un commentaire incomplet dans le code source du noyau Linux. Cliquer pour agrandir

Les premières corrections pour Meltdown concernaient tous les processeurs, y compris ceux d’AMD. Mais les puces de ce dernier n’étant en réalité pas concernées, AMD l’a fait savoir juste après Noël, dévoilant au passage la faille concernant l’exécution spéculative. C’est ce qui a poussé le site The Register à enquêter et finalement publier un article le 2 janvier, le premier à dévoiler publiquement l’existence de la faille.

L’embargo était rompu, une semaine en avance par rapport au planning décidé par Intel. Nous avons publié un article sur le sujet comme de nombreux sites, et Intel et les autres acteurs impliqués ont été forcés de répondre, tandis que les chercheurs en sécurité publiaient leurs résultats. Cet emballement a eu un impact négatif sur la qualité des correctifs et deux semaines après la découverte des failles, tout n’est pas encore au point.

Microsoft a publié des mises à jour qui ont bloqué certains ordinateurs, tandis que du côté de Linux, l’impact sur les performances est parfois plus important qu’escompté, ce qui retarde les déploiements. Cette faille est de toute façon trop importante et nécessite des correctifs à un trop bas niveau pour ne pas poser quelque problème que ce soit. On va probablement en entendre parler pendant encore très longtemps…

avatar fousfous | 

Mais y a tout le temps des failles sur les appareils et y en aura toujours, pourquoi faire un foin particulièrement sur celles la?
Après moi ça me dérange pas de taper sur Intel hein.

avatar zarghol | 

@fousfous

Parce que ces failles sont très difficile à parer, fonctionne sur tous les processeurs actuels, et exploitable très facilement. :)

avatar tigre2010 | 

@zarghol

Et elles sont invisibles, impossible de savoir si sur une machine la faille à été exploitée ou non

avatar C1rc3@0rc | 

@fousfous

Pourquoi?

1) elles touchent plusieurs generations de processeurs depuis 2000 au moins
2) Spectre se retrouve dans des architectures radicalement différentes et antagonistes (RISC/CISC)
3) elles touchent plusieurs classe de processeurs (serveur, station, PC, portable, smartphone)
4) elles donnent un acces sans trace...
5) elles sont accessibles a distance (Spectre est accessible par une page WEB...)
6) elles passent la barrière de la virtualisation
7) elles sont liées a la performance des processeurs...
8) elles permettent d'exploiter indirectement les données des GPU (on va attendre plus d'infos mais c'est flippant)

Surtout ce sont des "meta-backdoor". Ça veut dire qu'elles permettent de creer des exploitations multiples et variées qui ont l'avantage de ne pas laisser de trace. Et surtout que ces exploitations sont universelles, puisqu'elles touchent tous les PC quels que soient leur OS.

Cela a pour conséquence de démontrer qu'aucune société informatique qui assurent que ses materiels/logiciels protègent des données qui sont contenues ne dit la verité.
On peut meme affirmer que depuis qu'elles ont ete informées officiellement de ces backdoor, toute communication ventant la securité d'un materiel est une tromperie.

Je reviens sur 2 points cruciaux:
- la virtualisation.
Il y a 10 ans je travaillais sur des serveurs virtualisés ou l'on utilisait la virtualisation pour isoler les environnement pour éviter les corruptions et les vols de données suite a des infections ou intrusions. Et puis on a reçu la visite de "conseillers" d'une société de sécurité, pas très connue a l’époque, qui nous on dit que c’était pas suffisant, qu'il était possible de lire la mémoire du processeurs sous les systèmes de virtualisation, donc entre les machines virtuelles... Ils nous avaient alors laissé penser que le probleme venait du système de virtualisation.

- la liaison performance et Spectre.
Il faut comprendre que si Intel nous enfume depuis des années avec la finesse de gravure, en terme de performance ou de consommation c'est de la foutaise. Le dernier saut de performance qu'on a vu avec la finesse de gravure c'est de passage de 32 nm a 22nm. Et encore. Toutes les autres améliorations viennent soit de l’intégration de coprocesseurs (dont les proc vectoriel et de crypto) soit de l'optimisation de l'architecture, soit de l’exécution prédictive et la mise en cache. Sur le x86 c'est quasi le seul élément d’amélioration et Intel a lourdement investit sur le développement d'heuristiques issu de profilage de fonctionnement...

Ça veut dire que pour chaque usage il y a un set d'heuristiques qui sont fonctionnelles et qui seront totalement inopérante sur un autre usage. C'est pour cela qu'Intel fait tellement de gammes de processeurs et qu'il faut vraiment bien choisir le bon proc pour le bon usage.

Intel a des catalogues entier de comportements de processeurs et d'heuristiques. Ça relève clairement du big data et du deeplearning. Mais ça veut dire aussi qu'ils sont atteint les limites du possible et que les moindre petites optimisations se gagnent sur la fiabilité et la securité. Pour les 5 dernieres generations de x86 ont a 5% au mieux d’amélioration sur le core, c'est anecdotique et on est en bout de course.

Finalement la conséquence de tout ça:
- aucune donnée aujourd'hui ne peut être considérée comme ayant ete en securite nulle part et surtout pas sur des serveurs (ou datacenter) Ce qui explique pourquoi Amazon, Google ou Apple veulent développer leur propres architectures depuis plusieurs annees...
- l'impact sur les performance des processeurs est enorme, puisque on peut avoir dans certains cas des retours aux performances datant d'il y a 10 ans.
- plus le logiciel repose sur l'optimisation a l'execution, plus ses performances sont degradées.
- plus le logiciel est programmé pour des processeurs de récentes generations plus ses performances sont degradées

Les conséquences et les implications sont énormes et systémique. De plus on en apprend chaque jour un peu plus et on s’aperçoit que le probleme est ancien et connu de plus en plus de monde...

avatar Glop0606 | 

Merci pour le complément d'infos :). En gros on est loin d'en voir la fin et la seule façon d'être un tant soit peu en sécurité c'est de ne pas avoir son réseau branché sur le net...
D'un autre côté, c'est peut-être une chance de voire de nouveaux acteurs rentrés sur le marché avec des solutions différentes. Pure curiosité: Les power PC des G5 sont ils touchés par cette faille?

avatar Link1993 | 

@Glop0606

Yes, G5 et G4 touché aussi :/

avatar C1rc3@0rc | 

-

avatar C1rc3@0rc | 

En gros tous les processeurs qui font usage d'un système de réordonnancent prédictifs sont potentiellement touchés par Spectre.
Apres, la mise en oeuvre peut etre differente, l'impact sur les performances des solutions de colmatage sont pus ou moins importantes et des solutions de protection dans les prochaines generations sont possibles comme la "randomisation" effective de l'adressage en memoire.

Les PowerPC G3 et 7400 ne sont pas touchés, mais le 7450 oui.. Par contre les processeurs derivés des Power 7+ jusqu'aux Power9 sont plus ou moins touchés.

On peut se poser la question de l'utilité du re-ordonnancement.
On sait que cette pratique est une source de problemes et de failles majeures. Deja son principe annule les techniques de preuves logiciel: le flux et l'etat du programme n'est plus determinable, donc on ne peut plus en prouver la fiabilité complete et le developpeur ne peut en aucun cas garantir l'integrité et le confidentialité des donnees pendant le traitement...

Est ce que face a ce danger le benefice est justifié?
pour le x86 la question ne se pose pas puisque c'est quasi la seule cause d'augmentation de performance des 10 dernieres generations, avec une moyenne de 5% par generation.

Pour les ARM et autres RISC, ou l'on a des augmentation de 50% de performance en moyenne par generation c'est plus discutable.

La grande question aujourd'hui c'est de savoir exactement combien de % de performances on peut obtenir en optimisant le logiciel. Et par la je veux dire l'otpiisation globale, du plus haut niveau, jusqu'aux optimisations finales lors de la compilation. Si on desactive totalement le systeme predictif, le developpeur sait donc exactement comment son code sera excecuté sur le core (dans le cas du multicore c'est plus complexe, mais ça peut aussi se modeliser).
A ce moment la, en disposant d'un langage adpaté, d'un compilateur performant, d'un OS optimisé et tout ça entre les mains d'un ingenieur en informatique bien formé, on a un programme qui certes statique, mais qui sera optimisé.
Pour compenser la perte de performance du a Meltdown qui est estimé entre 30% et 65% selon les usages et machines, il faut donc que le soft gagne 65% de performance... Est ce realiste?

Je vais donner un exemple tout bete: Javascript.
Aujourd'hui de plus en plus d'applications sont ecrites en Javascript en embarquant un moteur comme celui de Chrome ou Safari dans une application qui tourne en local sur la machine.
Si on compare avec le meme soft ecrit en C++ on a une performance de C++ qui se situe entre 10 et 20 (selon les test on arrive meme a 300 fois mieux pour C++) fois meilleure que Javascript avec une exploitation du processeur qui tend vers les 100% alors que Javascript plafonne a 80% dans les meilleurs cas.

Le hic c'est que l'efficacité du code C++ va dépendre de la compétence du développeur, alors que pour Javascript cela va dépendre de son moteur...

Si on considère des processeurs RISC "purs", l'impact de la qualité du programmeur est encore plus important. Si on considère une architecture parallèle comme l'EPIC 100% de l'efficacité dépend du programmeur et de son compilateur...

avatar Trillot Bernard | 

@C1rc3@0rc

Ben tu vois que tu peux ne pas dire des conneries! Bravo!

avatar renaudpro | 

Super article 👍

avatar frankm | 

@renaudpro

Résumé : le peu de puissance gagnée est anéanti par les correctifs

avatar DarthThauron | 

Apple a déployé ? Le verbe n'est pas très juste... Elle a limité les correctif à quelques dernières versions...

avatar SyMich | 

Tout à fait... Apple n'a déployé que TRÈS partiellement (seul HighSierra a reçu un correctif de macOS pour Meltdown). Ce ne sont que les correctifs logiciels de l'OS (et accessoirement de Safari) qui ont été diffusés et toujours pas les correctifs du microcode des processeurs qu'Intel a développé.

On n'a pas non plus les correctifs de NVidia pour les Macs ayant ce type de cartes vidéo.

avatar Malum | 

L’important est de savoir s’il faut ou non un accès direct à la machine. Ensuite il serait bon de savoir, vu le parc machines concerné, combien auraient été impactées.

avatar bugman | 

@Malum

D'après Mozilla, non.

avatar Malum | 

Il n’y a pas besoin d’accès direct ?
(Merci)

avatar Bigdidou | 

@Malum

« Il n’y a pas besoin d’accès direct ? »
Non, on nous a déjà expliqué qu’elles pouvaient être exploitées avec un simple script contenu dans une page web.

De toute façon, la question n’est pas de savoir si une faille nécessite ou pas un accès direct.
C’est si elle peut être facilement mise en oeuvre par un malware ou pas.
Les ransomwares nécessitent un accès. On a vu les dégats monstrueux.

avatar C1rc3@0rc | 

@Malum

Non.
Mais c'est pire que ça em fait. D'une part on peut acceder directement a Spectre depuis un navigateur Web qui fait tourner un javascript tout con, mais en plus Meltdown et Spectre sont des "meta' backdoor. Ça veut dire qu'on peut exploiter une autre faille comme celles de l'AMT par exemple, puis utiliser Meltdown pour lire tout ce que fait le processeur, recuperer des cle de chiffrage, des adresses, ...

Les 2 avantages majeurs de ces backdoor c'est qu'elles ont un spectre (si si) d'exploitation immense et surtout que leur exploitation ne laisse aucune trace, vu qu'elles interviennent a un niveau plus bas que l'OS... meme avec un scanner reseau on peut louper leurs exploitations.

avatar spece92 | 

Ce sont les agences du gouvernement américain qui sont la source.

avatar 7X | 

Et les agences russes, nord-coréennes, les israéliennes, les chinoises, les françaises, allemandes...
Puis les grands groupes industriels pour s'espionner entre eux. Puis les moins grands groupes.
Dans six mois un cocu pourra acheter sur le "dark net" un logiciel à 50€ pour espionner sont conjoint. Les "agences du gouvernement américain" sont très loin d'être les seules à avoir des oreilles indiscrètes.

avatar C1rc3@0rc | 

@spece92

Ben y en a qui peuvent bien hurler a la theorie du complot, mais quand meme:
- une faille qui permet de lire toutes les données qui sont traitées dans un processeur sans laisser de trace.
- une faille commune aux principales architectures de processeur, meme si ces architectures sont radicalement differentes
- une faille qui existe sur toute les generations de processeurs depuis l'an 2000 (voir avant)

Tout ces processeurs ont ete cree aux USA et la NSA comme la CIA et l'armée sont incontournable pour commercialiser quelques composants eletroniques traitant de donnees en AmeriqueS....

Le jours on l'on presentera un processeur chinois ou russe qui dispose de la meme faille, on pourra commencer a avoir des doutes, mais la quand meme.

avatar Cric | 

Top article, digne d'un roman d'espionnage !
À quand le film ?

avatar mysticx | 

@Cric

Il y en a eu pour moins que ça !

avatar NEWIPHONE76 | 

Article très intéressant et très fouillé, merci

avatar Dimitri64500 | 

Et donc le patron d'Intel qui a revendu ses actions n'a plus aucune excuse, il était forcément au courant...

Pages

CONNEXION UTILISATEUR