Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #141
    Membre éclairé
    Profil pro
    Ingénieur système Linux N3
    Inscrit en
    juillet 2008
    Messages
    244
    Détails du profil
    Informations personnelles :
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur système Linux N3

    Informations forums :
    Inscription : juillet 2008
    Messages : 244
    Points : 737
    Points
    737
    Par défaut Hardware trojan
    Je suis allé il y a 2 semaines à une conférence sur les hardware trojans. Le conférencier a présenté 2 cas d'étude, mais qui sont extrèmement complexes à mettre en oeuvre et qui de plus requièrent un accès physique au matériel et qui sont en fait faciles à détecter. Donc ce vecteur d'attaque n'est pas utilisé.
    Je reste persuadé qu'on risque bien plus par des attaques de social engineering, même si ça n'excuse pas Intel.

  2. #142
    Chroniqueur Actualités

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    mars 2017
    Messages
    1 049
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2017
    Messages : 1 049
    Points : 28 651
    Points
    28 651
    Par défaut MDS : de nouveaux exploits liés à l'exécution spéculative qui affectent les CPU Intel jusqu’à Kaby Lake
    MDS : de nouveaux exploits liés à l'exécution spéculative qui affectent les CPU Intel jusqu’à Kaby Lake
    Et exposent les données des mémoires tampon

    Depuis 2018, plusieurs vulnérabilités affectant les processeurs d’Intel ont été dévoilées. Il a même été démontré que certaines d’entre elles existent depuis près de deux décennies. Ces exploits tirent parti de certains mécanismes d’optimisations implémentés dans les processeurs x86, notamment celui dit de l’exécution spéculative. Les plus connues sont probablement : Meltdown/Spectre, BranchScope, PortSmash, TLBleed et Foreshadow. Ces vulnérabilités permettraient à un attaquant d’accéder et de détourner différents types de données (mot de passe, historique de navigation d’un navigateur Web, clé cryptographique…) sur un système sans être détecté par les outils de sécurité traditionnels. Les processeurs produits par Intel sont presque toujours les plus sensibles ou les seuls concernés par ces exploits.

    Récemment un ensemble de failles de sécurité critiques étroitement liées affectant les processeurs de la firme de Santa Clara a été publié. Il inclut RIDL (rogue in-flight data load), Fallout, ZombieLoad et Microarchitectural Data Sampling (MDS). Ces failles ont été découvertes de manière indépendante par Intel et diverses équipes de recherche, notamment le département d’informatique de l’université de Vrije aux Pays-Bas (VU d’Amsterdam), le Worcester Polytechnic Institute, l’université du Michigan, l’Université de technologie de Graz, la KU Leuven en Belgique, Cyberus, Oracle… Intel utilise le terme « Microarchitect Data Sampling » (MDS) pour désigner ce nouvel ensemble de failles. L’entreprise a été pour la première fois informée de l’existence de cet ensemble de vulnérabilités en juin 2018.

    Nom : mds.jpg
Affichages : 2049
Taille : 61,4 Ko

    Signalons au passage que les chercheurs en cybersécurité du VU d’Amsterdam allèguent qu’Intel a tenté de les « soudoyer » dans l’espoir de les convaincre d’orienter leur critique après la divulgation de la dernière vulnérabilité de sécurité qui affecte les processeurs x86 du fondeur de Santa Clara. Le média néerlandais Nieuwe Rotterdamsche Courant a rapporté à ce propos qu’Intel aurait proposé aux chercheurs une récompense de 120 000 $ pour les amener à minimiser la gravité de RIDL (la vulnérabilité qu’ils ont découverte).

    L’origine du problème

    Chaque processeur a un comportement microarchitectural (le comportement d’une implémentation réelle de l’architecture) et un comportement architectural (le comportement documenté qui décrit le fonctionnement des instructions et sur lequel les programmeurs se basent pour écrire leurs codes). Celles-ci peuvent diverger de manière subtile. Par exemple, d’un point de vue architectural, une puce exécute chaque instruction séquentiellement, une à la fois, en attendant que toutes les opérations d’une instruction soient connues avant d’exécuter cette instruction. Ainsi, un programme qui charge une valeur d’une adresse particulière en mémoire attendra que l’adresse soit connue avant de tenter d’effectuer le chargement, puis attendra que le chargement se termine avant d’utiliser la valeur.

    Au niveau microarchitectural, toutefois, le processeur peut tenter de deviner l’adresse de manière spéculative de sorte qu’il puisse commencer à charger la valeur à partir de la mémoire (ce qui est lent) ou qu’il puisse deviner que la charge récupérera une valeur particulière (plus rapide). Pour ce faire, il utilisera généralement une valeur du cache ou de la mémoire tampon. Si la prévision n’est pas bonne, le processeur ignorera la valeur estimée et effectuera à nouveau le chargement, avec cette fois l’adresse correcte. Le comportement défini par l’architecture est ainsi préservé, comme si le processeur attendait toujours les valeurs avant de les utiliser.

    Toutefois, la génération de cette hypothèse erronée perturbe d’autres parties de la puce. L’approche principale consiste à modifier le cache en fonction de la valeur devinée, ce qui cause des différences de synchronisation subtiles (car il est plus facile de lire des données déjà en cache que des données qui ne le sont pas) qu’un attaquant peut mesurer. À partir de ces mesures, l’attaquant peut déduire la valeur estimée qui était en cache.

    MDS est globalement basé sur un schéma de fonctionnement similaire. Mais au lieu d’exposer les valeurs devinées qui sont enregistrées au niveau du cache, il expose les valeurs des divers tampons au sein du processeur. Le processeur dispose d’un certain nombre de mémoires tampons spécialisées qu’il utilise pour déplacer les données en interne. Par exemple, les tampons de remplissage de ligne (LFB) sont utilisés pour charger des données dans le cache de niveau 1. Lorsque le processeur lit dans la mémoire principale, il vérifie d’abord le cache de données de niveau 1 pour voir s’il connaît déjà la valeur. Si ce n’est pas le cas, il envoie une requête à la mémoire principale pour récupérer la valeur. Cette valeur est placée dans un LFB avant d’être écrite dans le cache. De même, lors de l’écriture de valeurs dans la mémoire principale, elles sont enregistrées temporairement dans des mémoires tampons. Grâce à un processus baptisé « store-to-load forwarding », le tampon peut également être utilisé pour gérer les lectures en mémoire. Enfin, il existe des structures qui permettent de copier des données de la mémoire dans un registre, ce sont des ports de chargement. Les mémoires tampons peuvent contenir des données périmées et transmettre un mélange de données nouvelles et anciennes.

    Comme d’autres attaques par canal latéral, les exploits récemment divulgués peuvent permettre aux pirates d’obtenir des informations qui seraient autrement considérées comme sécurisées, si elles n’avaient pas été traitées par le biais des processus d’exécution spéculatifs du CPU. Mais les attaques d’exécution spéculatives précédentes utilisaient une valeur périmée stockée dans le cache, alors que les nouvelles attaques MDS tirent parti des valeurs périmées stockées dans les différentes mémoires tampon du CPU. Les trois types de mémoires tampon peuvent être utilisés dans de telles attaques et l’utilisation de la technologie « Hyperthreading » augmente la facilité d’exploitation de MDS.

    Pour rappel, le Simultaneous Multi Threading (ou SMT) est une technologie orientée multitâche qui permet d’exécuter plusieurs threads de calcul en parallèle sur le cœur physique d’un processeur. La technologie Hyperthreading développée par Intel n’est qu’une implémentation du SMT permettant d’activer deux cœurs logiques pour chaque cœur physique disponible sur un die. L’Hyperthreading est ainsi censé permettre l’exécution de deux instances simultanément d’un même programme ou de deux programmes différents en utilisant au mieux les ressources du processeur.

    L’attaque peut être réalisée aussi bien sur un ordinateur que sur le cloud. Les chercheurs disent que cette faille peut être utilisée pour siphonner les données du processeur pratiquement en temps réel. Mais en règle générale, un attaquant a peu ou pas de contrôle sur ces tampons, car il n’existe pas de moyen simple d’obliger les mémoires tampon à contenir des informations sensibles. Les mémoires tampon peuvent contenir des données obsolètes issues de diverses opérations. Certaines d’entre elles peuvent intéresser un attaquant, mais elles peuvent être mixées à d’autres données non pertinentes. Par conséquent, rien ne garantit que les données divulguées seront utiles à l’attaquant et Intel estime que les nouvelles vulnérabilités présentent un risque faible ou moyen.


    La réaction d’Intel

    Intel a affirmé que des modifications logicielles importantes seront nécessaires pour renforcer les systèmes contre MDS, non seulement de sa part, mais également de la part des fournisseurs d’OS et des créateurs d’applications tierces. Une des solutions proposées par le fondeur de Santa Clara est de forcer la suppression ou l’écrasement des tampons chaque fois qu’un processeur passerait d’une application tierce à une autre, d’un processus Windows à une application tierce, ou même de processus Windows moins fiables à des processus plus fiables. Cela signifie un tout nouveau cycle de collecte et d’écriture de données à chaque fois que vous appelez un processus différent et implique une pénalité en termes de performance qu’Intel évalue au maximum à 9 %. S’appuyant sur des tests internes, Apple a déclaré que les utilisateurs pouvaient s’attendre à une perte de performances sur macOS (Mojave, High Sierra et Sierra) allant jusqu’à 40 % (selon le système et la charge de travail).

    La firme de Santa Clara a publié des mises à jour du microcode pour certains de ses processeurs, via Windows Update pour certaines, afin d’adresser ces nouvelles vulnérabilités. Dans son document d’orientation, Intel a révélé que tous les processeurs Core et Xeon allant jusqu’à l’architecture Sandy Bridge de 2e génération sont concernés. Un certain nombre de microarchitectures ciblant des puces à faible consommation, telles que « Gemini Lake », « Cherry View », « Apollo Lake » et « Amber Lake » sont aussi concernés.

    Intel a assuré que ses processeurs x86 des 8e et 9e générations intègrent des protections matérielles contre MDS, mais que les architectures antérieures sont toutes vulnérables. En général, les mesures d’atténuation ont un coût en termes de performances pour l’implémentation de la technologie SMT d’Intel, l’Hyperthreading. Toutefois, pour ceux qui attachent plus d’importance à la sécurité qu’aux performances lors de l’utilisation, Intel a admis que la désactivation de l’Hyperthreading pourrait être justifiée pour mieux se protéger contre les attaques MDS. À l’heure actuelle, il semble que l’implémentation de la technologie SMT développée par AMD soit plus sécurisée que celle d’Intel.

    Nom : 1.jpg
Affichages : 2029
Taille : 34,1 Ko

    Dans un communiqué, la société AMD a confirmé que ses processeurs x86 ne sont pas affectés par les vulnérabilités RIDL, Fallout et ZombieLoad : « Sur la base de notre analyse et de nos discussions avec les chercheurs, nous pensons que nos produits ne sont pas susceptibles à “Fallout”, “RIDL” ou “ZombieLoad” en raison des vérifications de la protection matérielle de notre architecture. Nous n'avons pas été en mesure de démontrer ces exploits sur les produits AMD et nous n'avons pas connaissance que d'autres l'auraient fait ». Il est important de noter ici que la vulnérabilité Fallout à laquelle AMD fait référence dans cette déclaration fait référence à l’une des quatre vulnérabilités MDS divulguées par Intel, et non à la vulnérabilité « Fallout », dénommée de manière identique et découverte par CTS Labs en 2018, prétendument affectant la gestion de la mémoire sécurisée des processeurs « Zen » de la marque.

    Source : AMD, Apple, NRC, Wired

    Et vous ?

    Qu’en pensez-vous : nouveau coup dur pour Intel ?
    Quel impact pourrait avoir cette annonce sur les parts d'Intel sur les marchés des CPU x86 grand public et serveur ?
    Le nombre élevé de failles de sécurité auxquelles sont exposés les CPU d’Intel pourrait-il vous inciter à migrer vers un système basé sur des CPU AMD ?

    Voir aussi

    L'architecture de tous les CPU Intel remise en question après la découverte de SPOILER, une nouvelle faille difficile à corriger par voie logicielle
    AMD pourrait vendre plus de CPU serveur dédiés au cloud computing, après le scandale des vulnérabilités matérielles touchant surtout les CPU Intel
    Les techniques de mitigation logicielles ciblant Spectre ne peuvent compenser les défauts de conception structurels des puces touchées, selon Google
    Des chercheurs révèlent de nouveaux défauts de fabrication dans les CPU, une nouvelle génération de vulnérabilités Spectre et Meltdown ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  3. #143
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    8 564
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : juillet 2006
    Messages : 8 564
    Points : 12 179
    Points
    12 179
    Par défaut
    Citation Envoyé par Christian Olivier Voir le message
    Toutefois, la génération de cette hypothèse erronée perturbe d’autres parties de la puce. L’approche principale consiste à modifier le cache en fonction de la valeur devinée, ce qui cause des différences de synchronisation subtiles (car il est plus facile de lire des données déjà en cache que des données qui ne le sont pas) qu’un attaquant peut mesurer. À partir de ces mesures, l’attaquant peut déduire la valeur estimée qui était en cache.
    Moi, j'aimerais bien qu'on m'explique ce que j'ai mis en gras.

    Et comment un attaquant s'y prendrait pour faire la différence entre 01010101 et 10101010, données qui devraient mettre environ le même temps pour être lues (données schématisées pour montrer l'idée, s'il s'agit de mots de 64 bits vous multipliez par 8).

    Citation Envoyé par Christian Olivier Voir le message
    L’attaque peut être réalisée aussi bien sur un ordinateur que sur le cloud.
    Ah ouais ? Dans le cloud ? Depuis le garage avec un simple câble RJ45 pour attaquer le cloud ?

    Restons sérieux 5 minutes : en labo, avec des sondes de tous les côtés piquées sur la carte-mère et en y passant des mois, peut-être qu'on trouverait un numéro de téléphone ou une adresse email, mais sinon, franchement, comment ça peut fonctionner ce genre d'attaque ?
    Parce que ce n'est pas le tout que des données aient la faculté d'être devinées à cause de ce qui est décrit dans l'article, encore faut-il qu'il y ait quelque chose pour les récupérer, non ?
    Puis les mettre en forme, et enfin les exploiter.

    Je reste perplexe…
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

  4. #144
    Membre extrêmement actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    février 2016
    Messages
    185
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2016
    Messages : 185
    Points : 411
    Points
    411
    Par défaut
    j'aurais aimé comprendre sur quels bases on spécule que amd n'est pas affecté.

    En effet la solution proposé par intel, de vider les caches au changement de focus (lol), semble radicale quand on prend le temps de considérer le nombre de processus total qui tourne sur un desktop ou un mobile. Les caches seraient vidés en permanence, ce que semble dire apple avec ses 40% de dégradations de performance annoncées.

    m'enfin je trouve cela tout de même inquiétant, les failles se multiplient et à chaque fois les performances sont un peu plus grignotées alors que nous sommes très concrètement actuellement en fin de loi de moore -ça peut changer, restons optimiste pour le pire et pour le meilleur (le quantique c'est pas bon pour la crypto).

    Peut être que nous allons bientot repartir dans une ère d'errance d'innovations technologique tatonnant pour trouver une voie de développement stable, multipliant les standards empressés et la dislocation de l'intégration que l'infromatique à réussit à atteindre après toutes ces décennies -souvenez vous de ces vieilles machines qui n'encodaient pas avec le même byte order etc.
    Peut être que ces changement auront des impacts plus profond sur notre manière d'architecturer nos système, nous poussant à réserver toujours plus d'espaces à des machines de calculs pour lesquels nous ne serions pas seulement inquiet, mais certains, de leurs défaillances sécuritaires.
    On peut même pousser et imaginer que les hébergeurs proposent des machines secure et des machines non secure dans différentes offres pour effectuer differentes taches en fonctions des impacts de securite.

    Peut être aussi que le ralentissement des processeurs aura pour effet de rendre plus acceptable les impacts de performances des implémentations en parallel processing, rendant celui ci relativement plus efficace et donc plus populaire encore!

    on a pas fini de programmer!

  5. #145
    Membre expert Avatar de marsupial
    Homme Profil pro
    DevOp, Tech leader
    Inscrit en
    mars 2014
    Messages
    1 055
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : DevOp, Tech leader

    Informations forums :
    Inscription : mars 2014
    Messages : 1 055
    Points : 3 802
    Points
    3 802
    Par défaut
    Je n'ai pas entendu parler d'attaques exploitant ces failles ce qui ne certifie pas qu'aucune n'ait eu lieu (qui savait avant Snowden ?). Pourtant je suis certain de la possibilité donnée aux pirates de faire très mal. Pour l'instant, le niveau de complexité pour l'exploitation protège, mais un jour viendra où un Etat s'en servira. Les pirates pilotent bien des attaques avec de l'IA (source Ziff Davis). Si les éditeurs de navigateurs et les fournisseurs de Cloud ont patché à toute vitesse, y compris les distributions GNU/Linux, je pense qu'ils ne le font pas pour la gloire mais bien en prévention d'un bon black hat qui se lache dessus.
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

  6. #146
    Responsable Systèmes


    Homme Profil pro
    Technicien maintenance
    Inscrit en
    août 2011
    Messages
    11 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : août 2011
    Messages : 11 716
    Points : 26 198
    Points
    26 198
    Par défaut
    Je pense que ce n'est que le début :



    Pour ceux qui peuvent suivre, c'est flippant.
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur la création d'un système : http://chrtophe.developpez.com/tutoriels/minisysteme/
    Mon article sur le P2V : http://chrtophe.developpez.com/tutoriels/p2v/
    Consultez nos FAQ : Windows, Linux, Virtualisation

  7. #147
    Chroniqueur Actualités

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    mars 2017
    Messages
    1 049
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2017
    Messages : 1 049
    Points : 28 651
    Points
    28 651
    Par défaut Un développeur du noyau Linux rappelle qu’à cause des failles matérielles qui affectent les CPU Intel
    Un développeur du noyau Linux rappelle qu’à cause des failles matérielles qui affectent les CPU Intel
    Il faut désactiver l'hyperthreading et s’attendre à une réduction des performances de 20 %

    Le développeur du noyau Linux Greg Kroah-Hartman estime que la technologie SMT (Simultaneous Multithreading) d’Intel - également connu sous le nom d’Hyperthreading - devrait être désactivée pour des raisons de sécurité à cause des failles de sécurité MDS (Microarchitectural Data Sampling) dévoilées plus tôt cette année. S’exprimant lors du sommet Open Source organisé récemment à Lyon, il n’a pas caché ses préoccupations vis-à-vis des lacunes en matière de sécurité des processeurs x86 Intel qui exploitent la technologie Hyperthreading. Kroah-Hartman précise que « Linux n’est ni moins sûr ni plus sûr » que les autres solutions, mais que tout le problème vient des failles matérielles qui affectent les puces.

    À ce propos, il a déclaré : « J’ai donné une conférence l’année dernière sur Spectre et comment Linux y a réagi ; et puis cette année, le sujet porte sur les éléments trouvés depuis le dernier entretien ». Selon lui, ces problèmes sont devenus récurrents, sont là pour durer et ne disparaitront pas de sitôt. Kroah-Hartman assure par ailleurs que la base de données CVE des problèmes de sécurité n’est pas pertinente quand il s’agit du noyau Linux : « Les CVE ne signifient rien, pour le noyau. Très peu de CVEs sont assignés au noyau ».

    Nom : gregkh.jpg
Affichages : 14592
Taille : 20,8 Ko

    Pour rappel, depuis 2018, plusieurs vulnérabilités affectant les processeurs d’Intel ont été dévoilées et il a été démontré que certaines d’entre elles existent depuis près de deux décennies. Ces exploits tirent parti de certains mécanismes d’optimisations implémentés dans les CPU x86, notamment celui dit de l’exécution spéculative. Les plus connues sont probablement : Meltdown/Spectre, PortSmash, BranchScope, TLBleed et Foreshadow. Ces vulnérabilités permettraient à un attaquant d’accéder et de détourner différents types de données (mot de passe, historique de navigation d’un navigateur Web, clé cryptographique…) sur un système sans être détecté par les outils de sécurité traditionnels. Les processeurs produits par Intel sont presque toujours les plus sensibles ou les seuls concernés par ces exploits.

    En mai 2019, un ensemble de failles de sécurité critiques étroitement liées affectant les processeurs de la firme de Santa Clara a été publié. Il inclut RIDL (rogue in-flight data load), Fallout, ZombieLoad et Microarchitectural Data Sampling (MDS). Ces failles ont été découvertes de manière indépendante par Intel et diverses équipes de recherche. Pour désigner ce nouvel ensemble de failles, Intel préfère utiliser le terme « Microarchitect Data Sampling » (MDS).

    Comprendre MDS

    Chaque processeur a un comportement microarchitectural (le comportement d’une implémentation réelle de l’architecture) et un comportement architectural (le comportement documenté qui décrit le fonctionnement des instructions et sur lequel les programmeurs se basent pour écrire leurs codes). Celles-ci peuvent diverger de manière subtile. Par exemple, d’un point de vue architectural, une puce exécute chaque instruction séquentiellement, une à la fois, en attendant que toutes les opérations d’une instruction soient connues avant d’exécuter cette instruction. Ainsi, un programme qui charge une valeur d’une adresse particulière en mémoire attendra que l’adresse soit connue avant de tenter d’effectuer le chargement, puis attendra que le chargement se termine avant d’utiliser la valeur.

    Au niveau microarchitectural, toutefois, le processeur peut tenter de deviner l’adresse de manière spéculative de sorte qu’il puisse commencer à charger la valeur à partir de la mémoire (ce qui est lent) ou qu’il puisse deviner que la charge récupérera une valeur particulière (plus rapide). Pour ce faire, il utilisera généralement une valeur du cache ou de la mémoire tampon. Si la prévision n’est pas bonne, le processeur ignorera la valeur estimée et effectuera à nouveau le chargement, avec cette fois l’adresse correcte. Le comportement défini par l’architecture est ainsi préservé, comme si le processeur attendait toujours les valeurs avant de les utiliser.

    Toutefois, la génération de cette hypothèse erronée perturbe d’autres parties de la puce. L’approche principale consiste à modifier le cache en fonction de la valeur devinée, ce qui cause des différences de synchronisation subtiles (car il est plus facile de lire des données déjà en cache que des données qui ne le sont pas) qu’un attaquant peut mesurer. À partir de ces mesures, l’attaquant peut déduire la valeur estimée qui était en cache.

    MDS est globalement basé sur un schéma de fonctionnement similaire. Mais au lieu d’exposer les valeurs devinées qui sont enregistrées au niveau du cache, il expose les valeurs des divers tampons au sein du processeur. Le processeur dispose d’un certain nombre de mémoires tampons spécialisées qu’il utilise pour déplacer les données en interne. Par exemple, les tampons de remplissage de ligne (LFB) sont utilisés pour charger des données dans le cache de niveau 1. Lorsque le processeur lit dans la mémoire principale, il vérifie d’abord le cache de données de niveau 1 pour voir s’il connaît déjà la valeur. Si ce n’est pas le cas, il envoie une requête à la mémoire principale pour récupérer la valeur. Cette valeur est placée dans un LFB avant d’être écrite dans le cache. De même, lors de l’écriture de valeurs dans la mémoire principale, elles sont enregistrées temporairement dans des mémoires tampons. Grâce à un processus baptisé « store-to-load forwarding », le tampon peut également être utilisé pour gérer les lectures en mémoire. Enfin, il existe des structures qui permettent de copier des données de la mémoire dans un registre, ce sont des ports de chargement. Les mémoires tampons peuvent contenir des données périmées et transmettre un mélange de données nouvelles et anciennes.

    MDS et Hyperthreading

    Comme d’autres attaques par canal latéral, les exploits récemment divulgués peuvent permettre aux pirates d’obtenir des informations qui seraient autrement considérées comme sécurisées, si elles n’avaient pas été traitées par le biais des processus d’exécution spéculatifs du CPU. Mais les attaques d’exécution spéculatives précédentes utilisaient une valeur périmée stockée dans le cache, alors que les nouvelles attaques MDS tirent parti des valeurs périmées stockées dans les différentes mémoires tampon du CPU. Les trois types de mémoires tampon peuvent être utilisés dans de telles attaques et l’utilisation de la technologie « Hyperthreading » augmente la facilité d’exploitation de MDS.

    Pour rappel, le Simultaneous Multi Threading (ou SMT) est une technologie orientée multitâche qui permet d’exécuter plusieurs threads de calcul en parallèle sur le cœur physique d’un processeur. La technologie Hyperthreading développée par Intel n’est qu’une implémentation du SMT permettant d’activer deux cœurs logiques pour chaque cœur physique disponible sur un die. L’Hyperthreading est ainsi censé permettre l’exécution de deux instances simultanément d’un même programme ou de deux programmes différents en utilisant au mieux les ressources du processeur.

    L’attaque peut être réalisée aussi bien sur un ordinateur que sur le cloud. Les chercheurs disent que cette faille peut être utilisée pour siphonner les données du processeur pratiquement en temps réel. Mais en règle générale, un attaquant a peu ou pas de contrôle sur ces tampons, car il n’existe pas de moyen simple d’obliger les mémoires tampon à contenir des informations sensibles. Les mémoires tampon peuvent contenir des données obsolètes issues de diverses opérations. Certaines d’entre elles peuvent intéresser un attaquant, mais elles peuvent être mixées à d’autres données non pertinentes. Par conséquent, rien ne garantit que les données divulguées seront utiles à l’attaquant et Intel estime que les nouvelles vulnérabilités présentent un risque faible ou moyen.

    Open BSD avait raison

    Tous ces éléments font dire à Kroah-Hartman qu’Open BSD avait raison : « Il y a un an, ils ont dit de désactiver l’Hyperthreading, il va y avoir beaucoup de problèmes ici. Ils ont choisi la sécurité plutôt que la performance à un stade plus précoce que n’importe qui d’autre. Désactivez l’Hyperthreading, C’est la seule façon de résoudre certains de ces problèmes ».

    Selon lui, le déploiement de ces mesures d’atténuation à un impact négatif plus ou moins important sur les performances (qu’il estime à environ 20 %) et ralentit la machine des utilisateurs, l’ampleur du ralentissement dépendant de la charge de travail. « En tant que développeurs de noyau, nous nous battons pour une augmentation de 1 %, 2 % de la vitesse. Mettez ces trucs de sécurité et on revient en arrière d’un an en termes de performance. C’est triste », a-t-il confié à ce sujet.

    Kroah-Hartman voit cette précaution comme un moindre mal. Il recommande d’ailleurs de toujours s’assurer que vous utilisez le patch de sécurité, la mise à jour ou la version du noyau Linux la plus récente sur votre système. Et il est catégorique : « Si vous n’utilisez pas une distribution supportée ou un noyau stable à long terme, vous avez un système non sécurisé. C’est aussi simple que ça. Tous ces appareils embarqués, qui ne sont pas mis à jour, sont faciles à pirater. Si vous travaillez dans un environnement sécurisé et que vous faites confiance à vos applications et à vos utilisateurs, vous récupérez la vitesse. Sinon, dans un environnement partagé, avec un code non fiable, vous avez besoin d’être sécurisé ».

    Et vous ?

    Que pensez-vous des propos de Kroah-Hartman ?

    Voir aussi

    L'architecture de tous les CPU Intel remise en question après la découverte de SPOILER, une nouvelle faille difficile à corriger par voie logicielle
    AMD pourrait vendre plus de CPU serveur dédiés au cloud computing, après le scandale des vulnérabilités matérielles touchant surtout les CPU Intel
    Les techniques de mitigation logicielles ciblant Spectre ne peuvent compenser les défauts de conception structurels des puces touchées, selon Google
    Des chercheurs révèlent de nouveaux défauts de fabrication dans les CPU, une nouvelle génération de vulnérabilités Spectre et Meltdown ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  8. #148
    Membre habitué
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    août 2018
    Messages
    68
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : Autre

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : août 2018
    Messages : 68
    Points : 137
    Points
    137
    Par défaut
    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... Intel de leur côté prétendent que la désactivation de l'Hyper Treading n'est pas nécessaire. 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 ?!

    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

  9. #149
    Membre averti
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    mai 2015
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2015
    Messages : 117
    Points : 340
    Points
    340
    Par défaut
    @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.

  10. #150
    Membre éprouvé Avatar de eldran64
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2008
    Messages
    255
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2008
    Messages : 255
    Points : 972
    Points
    972
    Par défaut
    Juste pour la petite info, désactivé l'hyperthreading sur un core I3 de 10ème génération, c'est perdre un peu plus de 30% de performance et non 20%.
    Ça a fait partie des arguments qui m'ont poussé à passer sur une plateforme AMD à la place d'Intel.
    Tout le monde devrait avoir de l'esprit critique car personne ne pourra m'apporter la preuve de l'absence celui-ci

Discussions similaires

  1. Macro qui s'exécute sur tous les onglets
    Par idckhorne dans le forum Macros et VBA Excel
    Réponses: 4
    Dernier message: 27/05/2009, 12h56
  2. Réponses: 2
    Dernier message: 04/12/2008, 18h41
  3. Arret de l'exécution de tous les jobs
    Par ahlemahlem dans le forum Oracle
    Réponses: 1
    Dernier message: 05/10/2006, 18h57
  4. Réponses: 12
    Dernier message: 22/06/2006, 11h26

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo