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 grands éditeurs et fournisseurs de cloud s'activent pour patcher leurs produits
Contre les vulnérabilités dans les puces d'Intel, AMD et ARM

Le , par Michael Guilloux

382PARTAGES

7  0 
AWS, Microsoft et Google ainsi que d'autres fournisseurs ont informé leurs clients qu'ils risquent d'être confrontés à des interruptions et à une dégradation de performance à cause de leurs efforts pour accélérer la correction des bogues critiques présents dans de nombreux processeurs. Les bogues en question sont causés par des problèmes de conception de microprocesseurs qui pourraient potentiellement permettre à un code malveillant de lire le contenu de la mémoire du noyau d'un ordinateur. Ces problèmes affectent notamment les puces Intel qui dominent le marché des serveurs cloud, mais également des puces conçues par AMD et ARM, contrairement à ce que l’on pensait au début.

Ce problème a été découvert « tard l’année dernière » par l’équipe Project Zero de Google. Les principaux fournisseurs, qui ont été informés des vulnérabilités, ont eu également le temps de préparer des correctifs pour leurs produits et commencer à les déployer, mais il reste encore du travail à faire. Avec la divulgation de ces failles hier, elles n’ont plus donc le temps d’aller à leur rythme, mais doivent accélérer le processus pour éviter que des hackers commencent à exploiter les failles. Dans différents communiqués, AWS, Microsoft et Google ont informé leurs clients de ce qui a déjà été fait à leur niveau et d’éventuelles précautions à prendre.

Google

Dans un communiqué, Google affirme que depuis la découverte de la vulnérabilité affectant les microprocesseurs modernes, ses équipes d'ingénierie s'efforcent de protéger les clients contre la vulnérabilité de l'ensemble de la gamme de produits Google, y compris Google Cloud Platform (GCP), les applications G Suite et les produits Google Chrome et Chrome OS. Google dit également avoir collaboré avec les fabricants de matériel et de logiciels de l'industrie pour protéger leurs utilisateurs et le Web en général.

En ce qui concerne ses produits en particulier, Google affirme que « toutes les applications G Suite ont déjà été mises à jour pour bloquer tous les vecteurs d'attaque connus. Les clients et les utilisateurs de G Suite n'ont besoin d'aucune action pour se protéger de cette vulnérabilité. GCP a également déjà été mis à jour pour éviter toutes les vulnérabilités connues », mais « les clients qui utilisent leurs propres systèmes d'exploitation avec les services GCP pourraient avoir besoin d'appliquer des mises à jour supplémentaires à leurs images ». Enfin, Google fait savoir que les clients qui utilisent le navigateur Chrome, y compris G Suite ou GCP, peuvent tirer parti de la fonctionnalité d'isolation de sites pour renforcer leur sécurité sur les plateformes de bureau, y compris Chrome OS.

Amazon

Concernant la vulnérabilité, AWS indique qu'elle existe depuis plus de 20 ans dans les architectures de processeurs modernes telles que Intel, AMD et ARM sur des serveurs, desktops et périphériques mobiles ; avant d'ajouter que « tout sauf un petit pourcentage à un chiffre des instances de la flotte Amazon EC2 est déjà protégé ». Pour ce qui est des instances restantes, leur protection sera terminée « dans les prochaines heures » d'après Amazon. Le géant du cloud précise toutefois que si les mises à jour effectuées par AWS protègent l'infrastructure sous-jacente, afin d'être entièrement protégées contre ces problèmes, les clients doivent également patcher les systèmes d'exploitation de leur instance. Au passage, des mises à jour pour Amazon Linux sont disponibles et des instructions pour la mise à jour des instances existantes sont fournies.

Microsoft

Alors que Microsoft publiait son communiqué hier, la firme de Redmond a tenu à préciser qu'elle n'a reçu aucune information indiquant que ces vulnérabilités ont été utilisées pour attaquer les clients Azure. Et d'ajouter que « la majorité de l'infrastructure Azure a déjà été mise à jour pour corriger cette vulnérabilité. Certains aspects d'Azure sont toujours en cours de mise à jour et nécessitent un redémarrage des machines virtuelles des clients pour que la mise à jour de sécurité soit appliquée », explique Microsoft.

Beaucoup des clients Azure ont reçu une notification au cours des dernières semaines à propos d'une maintenance planifiée sur Azure et ont déjà redémarré leurs machines virtuelles pour appliquer le correctif. Pour ceux-ci, aucune autre action n'est requise. Avec la divulgation publique de la faille de sécurité mercredi, Microsoft a accéléré son calendrier de maintenance planifiée et a déjà commencé à redémarrer automatiquement les machines virtuelles restantes, comme l'entreprise l'a annoncé hier.

La majorité des clients Azure ne devraient pas voir d'impact notable sur les performances avec cette mise à jour. Seul « un petit groupe » de clients peut avoir un impact sur les performances de mise en réseau, mais cela peut être résolu en activant Azure Accelerated Networking (Windows, Linux), qui est une fonctionnalité gratuite disponible pour tous les clients Azure. Microsoft précise aussi que cette mise à jour de l'infrastructure Azure corrige la vulnérabilité révélée au niveau de l'hyperviseur et ne nécessite pas de mise à jour de vos images de machine virtuelle Windows ou Linux.

En ce qui concerne Windows, Microsoft a également réagi rapidement avec une mise à jour pour toutes les versions de Windows. Ce qu'il est important de savoir, cependant, c'est que seul Windows 10 reçoit automatiquement la mise à jour aujourd'hui, tandis que Windows 7 et Windows 8.1 se verront proposer la mise à jour avec le Patch Tuesday, la semaine prochaine. Les utilisateurs peuvent aussi l'installer manuellement via Microsoft Update Catalog.

DigitalOcean

DigitalOcean, un autre fournisseur cloud travaille également pour la protection de ses clients. « Depuis que nous avons appris ce problème, nous avons activement analysé et suivi l'activité du noyau Linux et notre équipe de développement a travaillé avec diligence pour obtenir autant d'informations que possible d'Intel. Malheureusement, l'embargo strict imposé par Intel a considérablement limité notre capacité à établir une compréhension globale de l'impact potentiel. »

« Sur la base de nos investigations et des informations que nous avons reçues jusqu'à présent, nous pensons qu'il peut être nécessaire de redémarrer les Droplets des clients affectés. Si les redémarrages s'avèrent être la bonne marche à suivre pour les utilisateurs de DigitalOcean, nous planifierons la maintenance urgente et aviserons les clients touchés. Nous continuons à surveiller cette situation et travaillons avec Intel pour obtenir plus de détails. »

Linux

La bonne nouvelle pour les linuxiens est que les développeurs de Linux ont déjà corrigé le noyau pour y faire face. Mais il y a aussi une mauvaise nouvelle ; c'est que le correctif va entraîner une baisse de performance d'au moins 5 %, et les applications peuvent voir leurs performances être beaucoup plus impactées. C'est le cas par exemple de PostgreSQL, comme cela est expliqué dans un message dans sa liste de diffusion.

« Les versions à venir du noyau Linux (et apparemment aussi de Windows et autres) incluront une nouvelle fonctionnalité qui a apparemment été implémentée avec hâte pour contourner un bogue matériel Intel. Le correctif va être fusionné dans la prochaine version du noyau Linux et est en train d'être intégré dans les anciennes versions. Intégrer une nouvelle entité complexe et envahissante dans une ancienne version indique que cela concerne un problème important », explique Andres Freund de l'équipe de développement de PostegreSQL. Avant d'annoncer que « le correctif entraînera malheureusement des régressions de performances » pour la base de données populaire. En ce qui concerne l'impact exact, dans certains cas, PostgreSQL pourrait connaitre un ralentissement d'au moins 17 % d'après des tests d'Andres Freund.

Sources : Google, AWS, Microsoft, Liste de diffusion PostgreSQL, DigitalOcean

Et vous ?

Qu'en pensez-vous ?

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

Avatar de jlliagre
Modérateur https://www.developpez.com
Le 05/01/2018 à 19:35
Citation Envoyé par chrtophe Voir le message
Je pense que les failles reposent sur le dispositif de prédiction de branchement.
Les trois failles reposent sur l'exécution spéculative, ce qui est un peu différent de la prédiction de branchement.

Avec la prédiction de branchement, lorsqu'il va y avoir un test (du style if/then/else) le processeur va charger l'instruction qu'il pense avoir le plus de chances d'être la suivante.

Avec l'exécution spéculative, le CPU charge une instruction qu'il estime avoir bonne chance d'être exécutée mais en plus, il l'exécute vraiment.

Dans les deux cas, si l'hypothèse est infirmée, l'exécution reprend vers la bonne instruction à exécuter. En théorie, on revient dans le même état que celui ou l'on aurait été sans ces optimisations, mais en pratique, l'exécution spéculative a des effets de bord: la perte de données qui étaient auparavant en cache et la présence dans le cache de données qui n'y seraient pas allées autrement.

Il n'y a pas d'instructions qui permettent de lire directement les données placées en cache par les techniques précédentes mais il existe des moyens détournés sophistiqués pour le deviner. Celui qui est le plus souvent décrit consiste à mesurer le temps mis à charger le contenu d'une adresse mémoire. Si ce temps est "long", c'est que le processeur est bien allé chercher la donnée en RAM. Si ce temps est court, c'est que cette adresse viens déjà d'être lue. On a donc réussi à lire le contenu du cache alors qu'il n'existe pas de moyen direct de le faire.

Avec Meltdown, on peut lire la totalité de la mémoire du noyau. On ne peut pas directement écrire dans cette mémoire, mais ce qu'on y lit, par exemple des mots de passe en clair ou des clefs privées pourra être exploité pour facilement devenir root.

Le cpu fait de l'exécution spéculative avec un gain de performance en cas de succès et une perte en cas d’échec, mais globalement cela donne un gain de perfs.
Il n'y a pas vraiment de perte de performance en cas d'échec (la durée du rollback doit être infime). Le temps passé par le CPU à faire de l'exécution spéculative aurait sinon été perdu à ne rien faire.


Corrompre les caches du CPU donnera un résultat aléatoire, je pense que c’est le principe de fonctionnement des exploits de ces failles.
Il n'y a pas de corruption des caches, mais au contraire chargement de données valides mais "interdites" dans les caches. Invalider complètement les caches supprimerait le risque mais serait inacceptable en terme de performance. Il faut cent à deux cents fois plus de temps pour charger des données de la RAM par rapport au cache niveau 1, vingt fois plus que le cache niveau 2.

Ces caches sont importants pour l'utilisation de la MMU, qui gère les droits d'accès aux pages mémoires.

Je pense que les patchs invalident les caches à des moments bien précis, ce qui fait perdre en perf.
Les patches qui sont disponibles pour Windows, Linux et OS X mettent en place une séparation franche entre espace mémoire utilisateur et espace mémoire noyau, ce qui n'était pas le cas jusqu'ici. L'objectif est de contrer Meltdown (spécifique aux processeurs Intel) mais avec un impact sur les performances qui est sujet à controverse (entre non mesurable et 30% suivant l'utilisation du processeur).

Il existe aussi des patches pour les compilateurs qui modifient le code assembleur généré pour contrer certains types d'attaques en replaçant les appels par un "retpoline" (return trampoline) et des patches pour le microcode des CPUs
10  0 
Avatar de emixam16
Membre chevronné https://www.developpez.com
Le 06/03/2019 à 14:45
D'un côté si il a fallu 20 ans pour trouver le problème, c'était pas si mal conçu que ça à la base.
Pas systématiquement.

Dans les cas de Spectre/Meltdown/Foreshadow/Spoiler, ces failles sont effectivement relativement balèzes (même si pas non plus exceptionnelles) et c'est compréhensible qu'elles aient mis du temps à être découvertes.

Mais des failles critiques, qui tiennent très longtemps dans le systèmes sont courantes. Voici deux exemples:
- La faille WinRar découverte récemment (https://www.developpez.com/actu/2479...-utilisateurs/) est très bête. Elle exploite une faille "bête" dans un format très peu utilisé (.ace). Et comme winrar ne prend pas en compte l'extension, en renommant simplement le fichier en .rar, je peux l'exploiter très facilement et compromettre une machine.
- L'idée derrière la faille HeartBleed était très basique aussi (principe expliqué en images par xkcd ici https://xkcd.com/1354/).

En résumé, qu'une faille n'ait été trouvé qu'après très longtemps ne veut pas dire que le logiciel était bien sécurisé... Juste qu'aucun chercheur en sécurité n'a regardé au bon endroit... Et vu le nombre d'endroits à regarder c'est compréhensible.
9  0 
Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 01/11/2019 à 22:38
@phil995511
Sauf que à ma connaissance pour mener ce type d'attaques il faut être physiquement présent sur une machine vulnérable dont les Bios / OS n'ont pas été patchés...
Tout le problème est là justement.
Les vulnérabilité découvertes dans les micro-archi Intel (et pour certaines même chez ARM/AMD) peuvent être exploités à "distances", puisqu'elles permettes de passer les barrières Mémoire/Processus mis en place par les OS pour empêcher les opérations d'écritures/lectures/exécutions sur une architecture à mémoire partagé.
Typiquement avec la bonne payload lancer sur un serveur cloud que ce soit dans un conteneur ou une VM, avec processeur Intel, il est possible de lire/écrire/exécuter des registres/buffers/instructions et leurs valeurs, sans que ce soit détectable.
De même une attaque par JS permettrait d'échapper à la sandbox mis en place par le navigateur est d'écouter en temps réelle tous ce qui passerait par le processeur.
Et ça, que la machine est été patché ou pas, puisque des dire même d'Intel, étant des bugs lié à la micro-architecture des processeurs, ce n'est pas "patchable".
La porté des attaques peut tout au plus être atténué, ce qui semble convenir à Intel ...moins à ses clients.

Intel de leur côté prétendent que la désactivation de l'Hyper Treading n'est pas nécessaire.
Tu m'étonne.
Tu voit une boite comme Intel venir expliquer à ses clients et leurs dires :
"Écouter, on s'est tromper il faudrait peut-être mieux désactiver l'HyperThreading sur nos processeurs en fin de compte.
Par contre vous allez perdre d'office 20% de performances et ne comptez pas sur un remboursement de notre part, même si c'est un vis cacher.
Parce qu'on à fait des erreurs OK, mais on ne va tout de même par rembourser tout le monde pour qu'ils aillent chez la concurrence".

Se mettraient-ils avec de telles affirmations potentiellement en porte à faux vis-à-vis de leurs clients au risque de les voir se retourner contre eux ?!
Là tu considère qu'Intel ne prend pas ses clients pour des pigeons, or ils démontrent tous les jours le contraire.
La preuve, ils continuent de vendre leurs processeurs/contrôleurs à des prix exorbitant, alors que ceux-ci sont toujours bugués et que les bios/UEFI des CM ne sont toujours pas systématiquement patchés en sortie d'usine (au bon vouloir des fabricants quoi ).
C'est un peu comme AMD qui demande à ses client de patcher une CM neuve pour pouvoir faire fonctionner leurs derniers Processeur "Compatible" .
Ça va 5 minute, mais ce n'est absolument pas normale.
Et quand une nouvelle faille apparait (ou qu'une fuite à lieu, parce que les Meltdown/Spectre c'est après 6 mois qu'on en a entendu parlé, alors qu'elles sont présentes dans tous les Processeurs Intel sortie depuis 95), leur premier réflexe a toujours été d'abord de le nier, puis d'en minimiser l'impact et enfin après un temps certain (pour ne pas dire un certain temps) de sortir des séries de patch bâclé qui font perdre X% de performances et qui finalement ne résolve rien puisque le problème est physique et ne peut être patché.

Finalement ils finissent par s'en sortir en promettant que la prochaine génération de processeurs sera exempt de failles, ce qui n'est pour l'instant toujours pas vrai.
Bref bel exemple de j'm'en bats les couillisme vis à vis de ses clients.

Au rythme auquel ils trouvent de nouvelles failles/vulnérabilités sur les CPU's ces derniers temps, si cela continue ainsi, on ne pourra bientôt plus rien faire de nos PC si ce n'est les recycler
C'est bien parce que l'on a pas vraiment le choix qu'ils ce permettent d'avoir ce comportement.
Si la masse de leurs clients avaient ne serait-ce qu'une architecture de replie, ils seraient plus avenant, or ce n'est pas le cas.
En l’état il n'existe aucunes architectures alternatives pour le grand publique.
L'industrie c'est orienté vers l'Intel x86 depuis l'IBM PC, finalement on va en subir les conséquences collectivement un jour ou l'autre.

En passant, j’attends encore les sanctions de l'Europe pour abus de position dominante d'Intel sur le x86 et divers autres IPs en leurs possessions.
9  0 
Avatar de codec_abc
Membre confirmé https://www.developpez.com
Le 04/01/2018 à 14:50
Citation Envoyé par abriotde Voir le message
Oui enfin c'est surtout que techniquement c'est assez difficile à exploiter, il semble falloir analyser tous l'espace d'adressage pour réussir à déterminer des adresse noyau (et a priori faire planter son programme des millions de fois) et ensuite arriver à comprendre qu'est-ce qu'il y a derrière ces adresses... la pluspart des malware n'ont pas envie de se casser la tête avec ça, il y a d'autres failles à exploiter plus facilement avant. Récupérer les données bancaires leur suffit
Par contre pour ceux qui se pencheront dessus, l'avantage que cela procure au programme c'est de pouvoir alors avoir un accès root mais plus que ça, pouvoir s'installer dans le système d'amorçage de l'ordinateur ou en mémoire noyau à un endroit ou il ne pourra pas être détecter par un anti-virus qui lui tourne en espace utilisateur (en root).
Alors il est vrai que ce n'est pas la peine de paniquer car ce sera peu exploiter et pas tout de suite mais ceux qui l'exploiteront auront tous de même un sacré avantage.
Comme dit dans le papier, il existe des techniques qui permettent de supprimer l'exception qui fait planter le programme, donc non le programme de plantera pas des millions de fois.

Aussi, il n'y pas pas besoin de dumper toute la mémoire car et la plupart des programmes (surtout natif) ont souvent des patterns d'allocations bien déterministe ce qui rend beaucoup plus rapide la recherche et l'analyse de la mémoire pour un programme malveillant. Bref, Meltdown n'est pas clairement pas impossible a mettre en œuvre, loin de la même. Pour rappel on a déjà eu Stuxnet qui consistait quand même a faire un virus qui reprogrammais les automates des centrifugeuses des centrales iraniennes pour ralentir leur programme nucléaire. Donc ça m'étonnerait que certaines organisation ne s'intéresse pas à cette faille qui leur laisse la porte ouverte a tout PC équipé d'un CPU Intel de moins de 10 ans.
7  0 
Avatar de e101mk2
Membre éclairé https://www.developpez.com
Le 08/01/2018 à 21:46
Entre Intel Management Engine, Meltdown et Spectre, Intel bat des records.

Les entreprises vont ce mettre à trembler dès qu'ils vont entendre parler d'Intel...
7  0 
Avatar de Nudger
En attente de confirmation mail https://www.developpez.com
Le 04/01/2018 à 16:17
Citation Envoyé par RyzenOC Voir le message
Depuis ce matin il semble que ce problème impacte aussi les cpu ARM et IBM Power 8/9.
AMD serait aussi un peu touché (Spectre) mais moins que intel.

A titre personnel je n'appliquerais pas le patch sur mes serveur linux. La perte de perf est trop importante et la faille est quand même difficilement exploitable pour un hacker. Il faut réunir quand même pas mal de condition pour l'exploiter.
Si vous êtes sur une machine dédiée et dont l'accès est suffisamment sécurisé, il n'y a pas trop d'inquiétude.
L'exécution d'un code qui exploite cette faille pourra difficilement se faire.

En revanche pour une machine virtuelle dans le cloud, c'est pas la même histoire : sur une même machine physique tourne plusieurs VM et rien ne dit qu'il n'y a pas un voisin malveillant qui va vouloir exploiter cette faille sur les CPU pour tenter de récupérer des données de votre propre VM.
6  0 
Avatar de benjani13
Membre extrêmement actif https://www.developpez.com
Le 28/05/2018 à 11:54
Citation Envoyé par dlandelle Voir le message
Désactiver les mises à jour, mettre un firewall, ça paraît plus efficace que d'avoir peur de ces menaces bidons ;-)
- Désactiver les mises à jour? Non. Voyez ce qu'à donné le manque applications des mises à jour quand le virus WannaCry a frappé.
- Mettre un firewall? Oui. Mais ça ne protège pas de tout, loin de là.
- Des menaces bidons? Soyons sérieux, ces vulnérabilités ont des impacts démontrés. Que votre PC personnel sois touché par une de ces vulnérabilités, il y a peu de chance. Ces attaques sont difficiles, extrêmement dépendantes de l'OS et du processeur (donc il faut faire du cas par cas). Votre PC personnel n'est pas une cible assez intéressante pour y mettre ces moyens. Les cibles de ces attaques seraient principalement les fournisseurs de cloud et d'autres infrastructures du type.

Citation Envoyé par pierre++ Voir le message
Ça me rappelle que dans les années 95 j'avais écris un petit programme en C qui explorait la mémoire du système ( windows 98, puis windows 98) à la recherche de la zone où était stockée la position des mines du jeu "Démineur". Histoire de ne pas sauter sur une bombe
Là c'est un peu plus subtile puisque c'est une exploration du cache du processeur, mais je doute que ce soit très compliqué pour un bricoleur de développer ça
Effectivement c'est plus subtile car, contrairement à la RAM, le cache ne peut être accédé directement. On ne peut pas aller demander à lire la case xxx dans le cache. Là il faut trouver des astuces pour, par déduction, obtenir des valeurs dans le cache. Dans le cas de spectre cela marche comme cela:
- On vise à obtenir la valeur à l'adresse X dans la RAM sans la lire directement
- On charge la donnée à l'adresse X dans un registre du processeur (on a pas le droit de le faire, mais l’exécution spéculatif va le faire tout de même)
- Si le dernier bit de la valeur à l'adresse X vaut 1, on charge une variable A qui correspond à une adresse Y dans la RAM.
- Sinon (le dernier bit de la valeur à l'adresse X vaut 0), on charge une variable B qui correspond à une adresse Z dans la RAM.

Après tout ça, la variable qui aura été chargé (A ou B), aura sa valeur dans le cache. On procède ensuite comme suit:
- On lance un timer 1
- On charge la variable A
- On mesure le temps écoulé
- On lance un timer 2
- On charge la variable B
- On mesure le temps écoulé

Et on analyse:
- Si le chargement de A est plus rapide, donc c'est A qui a été chargé tout à l'heure. Donc la condition "est-ce que le dernier bit de la donnée à l'adresse X vaut 1" était vrai.
- Sinon, B est plus rapide et donc le dernier bits vaut 0.

Et on recommence le processus pour chaque bits de la donnée à l'adresse X, et on obtient sa valeur sans jamais l'avoir lu directement, uniquement en inférant avec le comportement du cache.
6  0 
Avatar de 23JFK
Membre expert https://www.developpez.com
Le 15/06/2018 à 21:10
De correctif en correctif, le fière i9 sera bientôt aussi efficace qu'un 8080 si cela continue.
6  0 
Avatar de chrtophe
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 MiaowZedong
Membre extrêmement actif https://www.developpez.com
Le 04/01/2018 à 16:14
Citation Envoyé par codec_abc Voir le message
Ce n'est plus du tout spéculatif. Google a publié les papiers de recherche qui expliquent les vulnérabilités ont étés publiés. La plus grave (Meltdown), n'affecte que les processeurs Intel tandis que la moins facilement exploitable (Spectre) fonctionne sur pas mal de processeurs (Intel, AMD et ARM).

Lien: Spectre et Meltdown

En bonus, la mauvaise fois ultime d'Intel. Juste pour ça, mon prochain CPU sera un AMD, car foirer un design sur un CPU c'est déjà pas génial mais répondre "Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers." le jour de la publication de la faille c'est juste nous prendre pour des cons.
"Moins facile à exploiter", c'est vite dit. Spectre requiert certes un ralentissement qui sera visible de l'utilisateur, et un code complexe, mais potentiellement un JavaScript executé dans le browser sans rien demander à l'utilisateur pourrait piller des cookies d'authentification ou des mots de passe. Et pour le ralentissement (qui ferait sans doute rebooter sa machine à l'utilisateur lambda), les papiers précisent qu'il "y a de la place pour optimiser". Et encore heureux que ce soit difficile à executer, parce que ce n'est pas loin d'être la faille ultime.
5  0