IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Les CPU Intel depuis Skylake sont touchés par Plundervolt, une faille ciblant les mécanismes de l'overclocking,
Intel recommande de ne pas toucher aux valeurs par défaut du voltage CPU dans le BIOS

Le , par Christian Olivier

65PARTAGES

11  0 
Les processeurs Intel x86 souffriraient d'un défaut
Qui exposerait la mémoire noyau et impacterait surtout le marché serveur

Des rapports circulant depuis quelques jours sur la toile font état d’une vulnérabilité qui affecterait de manière spécifique (c’est encore spéculatif) les processeurs modernes de l’entreprise américaine Intel (génération ≥ Pentium Pro). Cette vulnérabilité pourrait être considérée comme majeure parce qu’elle mettrait en exergue un éventuel problème de sécurité sur les processeurs Intel suffisamment grave pour obliger Microsoft et Linus Torvalds à produire à la hâte des patchs spécifiques pour leurs OS respectifs.

Si au départ la vulnérabilité, telle qu’elle avait été rapportée, avait pu faire croire que l’ensemble des processeurs exploitant l’architecture x86 64-bits étaient concernés, une déclaration récente d’AMD a permis de voir un peu plus clair dans cette affaire.

« Les processeurs AMD ne sont pas concernés par les attaques contre lesquelles les techniques d’isolation de la table du noyau protègent. La microarchitecture AMD n’autorise pas les références mémoire, y compris les exécutions spéculatives, qui tentent d’accéder à des données à privilèges plus élevés alors qu’elles s’exécutent dans un mode privilégié inférieur quand cet accès est susceptible d’entraîner une erreur », pouvait-on lire dans le communiqué de la firme de Sunnyvale.

On pourrait donc supposer que la firme de Sunnyvale dispose d’informations encore sous embargo pour clamer ne pas être concernée même s’il faut éviter de tirer des conclusions hâtives tant que toute la lumière n’aura pas été faite sur cette affaire et les détails rendus publics. Au passage, il faut signaler que les processeurs basés sur les architectures ARM/RISC ne semblent pas être affectés.


L’exécution spéculative est essentiellement une forme de préemption qui tente de prédire quel code va être exécuté après un branchement, puis de l’extraire et de l’exécuter avant que l’ordre réel n’arrive. Les processeurs modernes ont une architecture en pipeline : ils traitent un grand nombre d'instructions simultanément, en avançant un petit peu dans chacune à chaque cycle. Si un branchement est mal prédit, tout le pipeline doit être vidé : la perte en performance est loin d'être négligeable. Cette technique a ses avantages, mais elle présente également un risque non négligeable pour la sécurité, car aucune vérification de privilège n’est présente au niveau du noyau du système d'exploitation.

Le problème réside dans le fait que vous pouvez exploiter cette fonctionnalité pour exécuter de manière spéculative un code qui devrait être normalement bloqué en stoppant l’exécution du code avant qu’une vérification puisse être effectuée. Cela signifie en gros qu’une application de niveau 3 (droits normaux) peut lire les données du noyau de niveau 0 (réservé à l'exécution du noyau) en utilisant une exécution spéculative, car la vérification de privilège ne sera pas effectuée avant que le code ne soit exécuté.

Tout serait parti d’un article de blog paru en juillet 2017. Son auteur y décrivait une expérience dans laquelle il tente d’accéder à la mémoire protégée utilisée par le noyau à partir de l’espace utilisateur, l’espace mémoire utilisé par les programmes classiques, en exploitant les mécanismes d’exécution spéculative intégrés dans les CPU x86 64-bits modernes.

Ces processeurs disposent d’unités spécialisées dans la gestion de la mémoire (MMU) qui permettent de contrôler les accès qu’un CPU fait à la mémoire de l’ordinateur. Ils peuvent fonctionner suivant au moins deux modes de fonctionnement, dont un mode noyau qui n’impose pas de restrictions sur les instructions exécutées, et un mode utilisateur qui limite ce que peuvent faire les instructions.

Habituellement, le système d’exploitation met en œuvre cette distinction en faisant fonctionner les autres programmes en mode utilisateur et en se réservant le mode noyau. Cette distinction entre espace utilisateur et espace noyau est à la base du contrôle d’accès qui empêche les instructions des applications de l’espace utilisateur d’accéder à une zone mémoire ne leur appartenant pas. On parle aussi de lecture d’une adresse mémoire non autorisée lorsque ce dysfonctionnement survient. Cette situation débouche rapidement sur une trappe du noyau et, en général, la fermeture du programme incriminé. Il faut noter que la trappe est déclenchée par une interruption matérielle et le mécanisme de protection mémoire ne peut être implémenté efficacement de façon logicielle.


L’auteur du blog a essayé de s’attaquer à ce mécanisme en tentant d’exploiter l’intervalle de temps pendant lequel une instruction non autorisée est exécutée et génère une interruption. Même s’il a précisé ne pas avoir réussi à lire la mémoire protégée grâce à sa méthode, il s’est rendu compte que le chargement mémoire interdit est bel et bien effectué par le CPU même si le processeur ne copie jamais l’information dans le registre. Il a remarqué que l’exécution spéculative se poursuivait dans les unités d’exécutions internes du CPU jusqu’à ce que l’interruption soit effective et que cette situation pouvait favoriser la survenue d’attaques potentielles basées, par exemple, sur les temps d’exécution des instructions pour déterminer les adresses mémoires utilisées par le noyau.

Qu’il soit possible, à partir d’un programme utilisateur, de déterminer les adresses mémoire utilisées par le noyau est une situation qui ne devrait pas se produire. Différentes techniques ont d’ailleurs été mises au point depuis des années pour respecter ce principe, l’une des méthodes les plus efficaces à l’heure actuelle étant l’ASLR (Address Space Layout Randomization). Cette dernière attribue un caractère aléatoire aux adresses mémoires utilisées par les applications et le noyau.

Cette « vulnérabilité matérielle » (parce que liée au fonctionnement spécifique des CPU modernes d’Intel comme semble le confirmer le mémo d’AMD) permettrait d’exploiter des processus en espace utilisateur en contournant la MMU et d’accéder à la mémoire noyau. Le problème étant matériel, dans la partie non reconfigurable du processeur, il ne serait apparemment pas envisageable de recourir à un patch via microcode pour corriger cette faille de sécurité.

La seule façon de contourner cette fonctionnalité au niveau logiciel serait d’utiliser une technique d’isolation de la table de correspondance (entre les adresses en mémoire virtuelle et en mémoire physique) du noyau (en anglais, KPTI) : cela rendrait le noyau complètement aveugle et le retirerait de l’espace mémoire virtuel jusqu’à ce qu’un appel système survienne. Il faudrait donc laisser aux éditeurs d’OS le soin de concevoir ces patchs via le système d’exploitation pour leurs produits respectifs.

À ce propos, il faut signaler que, durant ces derniers mois, KAISER, une nouvelle solution de sécurité proactive dédiée au noyau Linux, a vu le jour. Cette solution, qui a été renommée par la suite KPTI (Kernel Page Table Isolation), est censée limiter de manière significative l’impact d’éventuelles failles présentes ou à venir et mieux protéger les espaces mémoire du noyau. Il permettrait notamment de séparer les tables qui pointent vers les pages mémoires utilisées par le noyau de toutes les autres. Le 30 décembre dernier, Linus Torvalds a intégré KPTI directement dans la version 4.15-rc6 du noyau Linux et recommandé l’intégration de ce patch dans tous les noyaux encore maintenus, ce qui pourrait laisser penser que le problème devait être suffisamment grave pour que de telles mesures soient adoptées. Microsoft aurait également préparé des correctifs similaires à KPTI pour le noyau de Windows depuis novembre dernier.

Le problème avec ces patchs, c’est qu’ils introduisent une pénalité de temps pour le système et qu’ils ont un impact non négligeable sur les performances de certains types d’applications. Celles qui effectuent beaucoup d’appels aux instructions système devraient être les plus affectées. Pour une utilisation non serveur, tout semble pointer vers un impact nul ou infinitésimal. Côté serveur l’impact serait plus large et pourrait affecter massivement les infrastructures cloud où la virtualisation, très gourmande en appels système, est largement utilisée.

Source : Cyber WTF, AMD, Twitter info patch Windows, WccfTech

Et vous ?

Qu’en pensez-vous ?

Voir aussi

Les processeurs Intel x86 souffrent d'un défaut qui permet d'installer des logiciels malveillants dans l'espace protégé des puces
Vous avez lu gratuitement 1 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Christophe
Responsable Systèmes https://www.developpez.com
Le 13/12/2019 à 10:50
Ou, autrement dit : il faut déjà un accès quasi totale sur la machine pour pouvoir faire des mauvaises manipulations. Je pense que si quelqu'un à ring-0, il ne s'embêtera pas à compromettre la tension
Sauf à essayer de faire cramer le CPU par exemple.

Un accès "ring-0" et le niveau de privilège "NT authority" ...c'est la même chose ?
Non, le privilège NT authority correspond à des droits sous Windows. Il s'agit de comptes système avec des droits plus étendus que les comptes administrateurs, qui ne sont censés être utilsés que par les services Windows.

Le Ring 0 ne concerne que les CPU Intel/Amd. Le ring 0 étant le mode CPU avec le plus de privilèges, le ring 3 celui à moindre privilège (les ring 1 et 2 existent mais ne sont pas utilisés). Du code en Userland tournera en ring 3, du code Kernelland tournera en partie en ring 0 quand nécessaire. Le principe étant que le ring 0 restreint les accès matériel/mémoire/fonction CPU de modification de comportement pour le code en ring3. Quand un code en userland demande un accès qu'il n'a pas, l'OS va le gérer et lui attribuer ou non le droit (exemple, ajout de mémoire dans l'espace d'adressage pour un malloc : autorisé - accès à l'espace mémoire d'un autre processus : refus d'accès).

Les failles dont il est sujet ici évoque la possibilité d'accéder à des zones normalement accessibles qu'en ring0 par du code tournant en ring 3 par la mauvaise utilisation du cache par l’exécution spéculative. Les corrections effectuées sur les OS consistent à forcer l'invalidation des caches au moment opportun, ou de ne pas utiliser celui-ci. Voilà pourquoi ces patchs ont un impact sur les performances.

Les CPU Intel et AMD réagissent différemment car même si ils sont compatibles du point de vue code machine, brochage, ils ne sont pas câblés pareil à l’intérieur et ne font pas forcément exactement les mêmes choses pour arriver au même but. Le nombre d'attaques auxquelles les deux architectures sont sensibles est assez proche (il a été évoqué 5 pour Amd et 7 pour Intel). Et rien n'empêche de supposer que les CPU Amd peuvent être sensibles à des attaques auxquelles les CPU Intel ne le serait pas.

Un processeur non x86/Amd64 gèrera différemment avec par exemple un mode superviseur avec tous les droits et un mode utilisateur avec droits restreints. Un Windows 10 ARM n'aura donc pas de ring 0.

Mais pour moi le plus gros danger vient du Intel Management Engine qui contient un Minix un tourne ring -2 voire -3. (ring -1 étant l'hyperviseur pour les fonctions de virtualisation, au dessus du ring 0). A noter qu'il existe l'équivalent chez AMD le AMD Platform Security Processor (PSP) dont on entend moins parler mais qui n'est pas forcément mieux :
In September 2017, Google security researcher Cfir Cohen reported a vulnerability to AMD of a PSP subsystem that could allow an attacker access to passwords, certificates, and other sensitive information; a patch was rumored to become available to vendors in December 2017
6  0 
Avatar de eldran64
Membre extrêmement actif https://www.developpez.com
Le 12/12/2019 à 9:40
Les processeurs Intel sont vraiment daubés niveau archi.

La différence entre Intel et AMD c'est qu'AMD corrige ses failles de sécu d'une génération à l'autre.
Avec Intel, les failles de sécu ne sont pas corrigés et en plus comme leur archi datent de Mathusalem, le nombre de génération de processeurs touché par ses failles est très important.

Bref, avec Intel, il faut fuir comme la peste leur proco.
4  0 
Avatar de Ryu2000
Membre extrêmement actif https://www.developpez.com
Le 12/12/2019 à 10:18
Citation Envoyé par Christian Olivier Voir le message
La possibilité de modifier la tension et la fréquence des processeurs Intel à partir de l’OS permet d’utiliser des utilitaires dédiés à « l’overclocking ». Cependant, il s’avère finalement que les individus malveillants peuvent également tirer profit de cette fonctionnalité.
Dès que t'ajoutes une fonctionnalité ça créer des failles potentiels, du coup la phrase “La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer.” fonctionne quand on parle de technologie.

Citation Envoyé par Stérilux Voir le message
ses failles ne sont jamais mis en avant comme ce l'est pour intel.
Les processeurs Intel sont touché par plus de failles, les correctifs font perdre plus de performance aux processeurs Intel qu'aux processeur AMD, certaines failles qui touchent Intel, AMD, ARM sont plus difficilement exploitable avec les processeurs AMD et ARM, il y a plus de processeurs Intel que de processeurs AMD.

Citation Envoyé par Stérilux Voir le message
ses failles ne sont jamais mis en avant comme ce l'est pour intel.
Quand une faille touche AMD et ARM c'est dit dans l'article, Intel est touché par plus de failles que les autres.
AMD's CPUs, including the latest Ryzen and Epyc processors, are immune to:
  • Meltdown (Spectre v3)
  • Spectre v3a
  • LazyFPU
  • TLBleed
  • Spectre v1.2
  • L1TF/Foreshadow
  • SPOILER
  • SpectreRSB
  • MDS attacks (ZombieLoad, Fallout, RIDL)
  • SWAPGS
Il y a 7 attaques Meltdown et Spectre, les processeurs AMD sont affectés par 5 de ces failles, les processeurs Intel par 7 de ces failles.

===
Intel va revenir en force, il y a un gros plan qui a été lancé, la feuille de route prévoit une gravure en 1.4 nm d'ici 2029.
Si tout ce passe bien, dans 10 ans Intel va commercialisé des processeurs intéressants.
4  0 
Avatar de eldran64
Membre extrêmement actif https://www.developpez.com
Le 12/12/2019 à 10:33
Citation Envoyé par Stérilux Voir le message
J'avoue ne jamais avoir aimé intel mais quand même, tu le dis toi même, AMD corrige d'une génération à l'autre mais ses failles ne sont jamais mis en avant comme ce l'est pour intel.

Perso je regrette les CPU d'IBM et feu Motorola.
Il y a un effet "accumulation" et "sous le feux des projecteurs". Intel longtemps été le numéro 1 et a vendu des palettes de processeurs. Donc dès que les 1ère grosses failles sont apparus tout le monde en a parlé. Ensuite quand les autres sont apparus le focus est resté chez Intel.
AMD aussi a été décrié mais comme cela touchait moins de gen chez eux car leur archi est récente ET mise à jour, disons que c'est passé largement mieux.
3  0 
Avatar de LittleWhite
Responsable 2D/3D/Jeux https://www.developpez.com
Le 12/12/2019 à 22:06
Bonjour,

Je ne suis pas expert dans les failles, mais cela me semble bizarre. En réalité, les hackers qui s'intéressaient à la PS Vita au utilisée une technique similaire pour extraire des informations sensible d'une zone mémoire très protégée (permettant le chiffrement des données de la console et donc, protection anti copie et ainsi de suite).
Ici la conférence :
(à partir de la 20e minute.)

Le hacker en a fait un papier académique : https://arxiv.org/abs/1903.08102

Dans la conférence, il indique que si la tension n'est plus assez bonne, les transistors ne seront pas à la position attendue (ouvert/fermé) et du coup, le résultat est erroné.
Dans la vidéo de cette news, on voit un bit modifié dans le cas de la multiplication.

Je trouve (si je ne m'abuse pas) que ces deux travaux sont très proches et du coup, que l'attaque sur les CPU Intel :
  • ne sont pas nouvelles ;
  • ne sont pas spécifiques à Intel.


La vraie faille, c'est que l'OS puisse changer la tension du CPU et donc, si ce logiciel est non sécurisé, cela devient une opération réalisable par n'importe qui/n'importe quel programme.

Plundervolt nécessite des privilèges root étant donné que les logiciels qui permettent de modifier le vCore d’un processeur ont besoin d’un accès ring-0.
Ou, autrement dit : il faut déjà un accès quasi totale sur la machine pour pouvoir faire des mauvaises manipulations. Je pense que si quelqu'un à ring-0, il ne s'embêtera pas à compromettre la tension, il ira directement installé un keylogger ou je ne sais quel autre programmes malveillants (ou copier directement les données intéressantes).
3  0 
Avatar de Steinvikel
Membre expert https://www.developpez.com
Le 13/12/2019 à 5:53
Un accès "ring-0" et le niveau de privilège "NT authority" ...c'est la même chose ?
1  0 
Avatar de
https://www.developpez.com
Le 12/12/2019 à 8:48
Qu’en pensez-vous ?
Qu'il est étonnant que ce soit toujours intel qui soit cité mais jamais les autres, c'est curieux
A croire que les concurrents ont tous des CPU 100% fiable/sans faille...
2  2 
Avatar de
https://www.developpez.com
Le 12/12/2019 à 9:52
J'avoue ne jamais avoir aimé intel mais quand même, tu le dis toi même, AMD corrige d'une génération à l'autre mais ses failles ne sont jamais mis en avant comme ce l'est pour intel.

Perso je regrette les CPU d'IBM et feu Motorola.
0  0