Utilisateur:Seysn/Brouillon

Une page de Wikipédia, l'encyclopédie libre.

Cet article est une ébauche concernant l’informatique.

Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.

La mitigation de la vulnérabilité Spectre est un ensemble de techniques visant à supprimer une faille de sécurité informatique. Cette problématique s'est posée à la découverte et à la popularisation de cette dernière, laissant alors une faille de sécurité sur de nombreux systèmes informatiques.

La recherche permanente d'amélioration des performances a poussé les constructeurs à mettre en place une exécution spéculative du code à l’intérieur du processeur, mais cela a un coût en matière de sécurité. La mitigation de la vulnérabilité Spectre vise à rétablir une sécurité qu'on pensait acquise, mais qui a été sacrifiée pour la hausse des performances offerte par l'exécution spéculative des processeurs.

Principe de mitigation[modifier | modifier le code]

On découpe généralement les défenses face aux attaques spectre en 3 catégories[1] :

  1. Mitigation ou réduction de la précision des canaux couverts pour extraire les données ;
  2. Mitigation ou abandon de la spéculation en cas de données potentiellement accessibles durant l'exécution ;
  3. S’assurer que les données cachées ne sont pas accessibles.

C'est trois méthodes de mitigation sont ensuite séparés en 2 catégories, les solutions matérielles et les solutions logicielles.

Solutions matérielles[modifier | modifier le code]

La solution la plus efficace de mitigation est de désactiver l’exécution spéculative sur les processeurs, qui est nécessaire pour réaliser des attaques de type Spectre. Cette solution n'est pas réaliste car conduirait à une perte de performance significative[2].

Une solution possible de mitigation de Spectre du nom de Safespec est d'utiliser une structure temporaire comme mécanisme de protection des adresses de retour d'une procédure. Cette structure sert à protéger les données sur lesquelles l'exécution spéculative va s'effectuer. Si l'instruction qui cherche les données se termine avec succès, les données sont déplacées vers les structures dites permanentes (Mémoire cache). Sinon les données sont supprimées de la structure temporaire et ne sont jamais transmises à la mémoire cache. Par conséquent, les données des instructions qui ne retournent pas un succès sont invisibles pour l'attaquant, car elles ne finissent pas dans la mémoire de l'ordinateur. Cette solution demande l'ajout d'un espace mémoire réservé à la structure temporaire qui permettra de se protéger complètement des vulnérabilités de type Spectre[3],[4]. Néanmoins, SafeSpec n'est pas la seule solution matérielle possible. Une solution similaire est en cours de développement par des chercheurs de l'université d'Illinois. Cette solution appelée Invispec vise à rendre invisible les chargements liés à l'exécution spéculative dans le cache. Cette dissimulation fonctionne avec une mémoire tampon spéculative dont le fonctionnement est similaire aux structures temporaires de SafeSpec qui stockent les informations chargées à la place du cache[5],[6]. Selon les dires de l'Université, InvisiSpec est capable de gérer la cohérence des données du cache ainsi que la gestion des exécutions Multi-Thread à la différence de SafeSpec et ses structures temporaires[4].

PoisonIvy est une solution permettant le suivi de l'exécution spéculative et de prévenir l'exposition des données en dehors du circuit intégré. Cette solution cherche à prévenir ou limiter la potentielle écoute d'un tiers sur le bus mémoire. PoisonIvy surveille le flux d'information pour traquer les données générées lors de l'exécution spéculative ou des données qui en dépendent.[7],[8].

L'Université de Cambridge a commencé à développer en 2010 une architecture appelée CHERI (Capability Hardware Enhanced RISC Instructions)[9]. Le développement d'un prototype de processeur correspondant à l'architecture CHERI est actuellement en cours. Ce prototype est en cours de développement est vise pour le moment à être utilisé sur un Circuit logique programmable ou FPGA (Field-programmable gate array)[10]. De plus, l'université a également créé une implémentation de CHERI fonctionnant sous QEMU. Enfin ce processeur possède sa propre adaptation de FreeBSD qui permet de lancer le processeur mais également d'utiliser ses options de protection de la mémoire. L'université a publié un rapport technique en février 2018 traitant des performances du processeur face aux attaques de type Spectre et Meltdown. Les processeurs de types CHERI sont protégés contre les attaques spectre de type 1 et 3[11].

Solutions logicielles[modifier | modifier le code]

Une solution logicielle recommandée est d'utiliser l'instruction assembleur LFENCE. Cette instruction permettrait d’empêcher au processeur d’exécuter des opérations en avance, et ainsi contrer la variante 1 de Spectre. Toutefois, elle doit être utilisée de manière judicieuse, sinon les performances peuvent être considérablement compromises[12].

Dans certaines architectures comme les architectures ARMv8 par exemple il est possible de mettre des conditions sur les MOV avec les commandes assembleur CMOV sans utiliser de branche[13],[14]. De ce fait, il est possible de mitiger une partie des attaques Spectre. Dans certaines implémentations, la spéculation reste possible, dans ce cas il faut coupler les MOV conditionnels avec des barrières. Cependant, cette solution seule reste suffisante pour un bon nombre de micro-architecture courantes[15].

Retpoline (Return Tranpoline) est une solution visant à protéger des attaques spectres de type 2. Cette solution se base sur un échange des branches de retour ainsi que la pollution du RSB (Return Stack Buffer). La mise en place de Retpoline demande un accès au code source et l'autorisation d'agir sur la compilation[16]. Le principe original de pollution de la mémoire tampon est de bloquer l’exécution spéculative avec des ajouts de commandes assembleur générant une boucle infinie jusqu'à une détection par le processeur de la prédiction dangereuse. Un attaquant cherche à obtenir des informations à l'aide du return stack buffer, sur lequel sont normalement stockées les adresses de retour des commandes assembleur CALL. Ces données sont ensuite récupérables à l'aide d'un appel de retour où le processeur va chercher les données directement sur le return stack buffer. Néanmoins, Retpoline offre un moyen de se protéger en modifiant l’adresse de retour de la stack pour créer une différence entre le return stack buffer et le bus mémoire. Enfin, avec cette différence le processeur peut vider le return stack buffer et continuer l'exécution du code avec l'adresse récupérée depuis le bus mémoire[17].

Les navigateurs web sont aussi touchés par la faille Spectre[18]. Pour la mitiger, la plupart des navigateurs ont décidé de désactiver l'objet Javascript SharedArrayBuffer qui permettait de créer un tableau en utilisant la mémoire partagée[19].

Enjeux de la mitigation[modifier | modifier le code]

Rétablir la sécurité[modifier | modifier le code]

Le 3 janvier 2018, des chercheurs du Project Zero publient un article concernant leurs découvertes sur la vulnérabilité Spectre et la vulnérabilité Meltdown[20]. Cet article a eu une grande visibilité, ce qui a permis a des personnes malveillantes de réaliser des attaques dans le but d'avoir des informations cachées dans un système informatique[21]. Étant donné que la faille touche une fonctionnalité des processeurs, il était important pour ces fabricants de proposer rapidement une correction afin que l'impact soit le moins important possible.

En décembre 2018, un bon nombre de correctifs ont été mis en place et semblent contrer les attaques Spectre[22]. Toutefois, il reste assez difficile de savoir si la vulnérabilité n'est toujours pas existante sur son système puisque de nouvelles variantes de Spectre ont été découvertes après les premiers correctifs[23].

Des moyens sont mis a disposition pour vérifier si son système est vulnérable face à ces failles[24], ainsi que du code libre d'accès permettant de reproduire une attaque[25].

Limiter la perte de performance[modifier | modifier le code]

On peut mesurer les pertes de performances des techniques de mitigations actuellement mises en place et obtenir un ordre d'idée avec les résultats. Toutefois, il est difficile de donner un résultat précis étant donné que ces derniers peuvent varier en fonction du contexte et des principes de mitigations appliquées.

Des analyses ont été réalisées sur des calculs haute performance parallélises sur plusieurs nœuds en les comparant à des analyses réalisées sur des calculs à un nœud[26]. Ces analyses ont été réalisées avec CentOS Linux et une version mise à jour de son noyau réglant des failles d’exécution spéculative et de prédiction des branchements indirects utilisées lors d'attaques de type Spectre et Meltdown. Ces résultats sont de l'ordre d'environ 2-3% plus lent pour des travaux parallèles à un nœud, et d'environ 5-11% plus lent pour des travaux parallèles à plusieurs nœuds[27].

Des analyses plus détaillées ont été menées dans les laboratoires du MIT Lincoln pour analyser des techniques de mitigation sur Spectre et Meltdown[28]. Le but est savoir lesquelles sont les plus impactantes à partir d'une base d'un noyau Linux, en y ajoutant un ou plusieurs paramètres parmi :

  • La solution logicielle Retpoline ;
  • Une version mise à jour du BIOS, qui inclut un microcode mitigeant la version 2 de Spectre[29] ;
  • L'option de noyau PAGE_TABLE_ISOLATION, activant la fonctionnalité du noyau Linux appelée Kernel page-table isolation, utilisée pour contrer Meltdown[30],[31] ;
  • Modification Grsecurity sur le noyau, avec l'option PAX_MEMORY_UDEREF du patch PaX activée, utilisée pour contrer Meltdown[32],[33].

Ces différents paramètres sont testés dans trois contextes différents :

  • Connexion réseau (TCP), avec et sans Pare-feu ;
  • Accès sur le disque dur (lecture et écriture), avec et sans Lustre ;
  • Calcul intensif (travail sur le processeur), avec un exemple parallélisé de MATLAB ou avec Tensorflow.

Les résultats, exprimés en pourcentage moyen en termes de ralentissement, sont les suivants[34] :

Connexion réseau
Sans pare-feu Avec pare-feu
Sans Grsecurity 15% 21%
Avec Grsecurity 15% 61%

On remarque que l'impact est plus important lorsqu'on utilise ces techniques de mitigation avec un pare-feu. En effet, l'utilisation d'un pare-feu ajoute beaucoup de transitions de l'espace utilisateur vers l'espace noyau lors de l'acceptation des connexions TCP. Ces transitions ajoutent un nombre d'appels systèmes, qui sont touchés par les techniques de mitigations.

Accès au disque dur
Environnement local Lustre
Sans Grsecurity 50% 33%
Avec Grsecurity 90% 33%

Les résultats sur l'accès au disque dur sont flagrants. Lorsqu'il est question d'écriture et lecture sur le disque, le système réalise des appels systèmes qui sont couteux. Il est donc logique que de voir les performances diminuer fortement, surtout dans des tests intensifs. On remarque aussi que l'impact est plus important dans l'environnement local qu'avec Lustre. La raison est que Lustre est globalement plus lent lorsqu'il est utilisé avec des blocs de petites tailles, qui ont été nécessaires lors des tests.

Calcul intensif
MATLAB Tensorflow
Tous les paramètres de mitigation 21% 16%
Mise à jour BIOS uniquement 19% 15%

Dans ce dernier contexte, les résultats varient moins. Cela est dû au fait que les tests réalisent peu d'appels système. Toutefois, on peut voir que le ralentissement lorsqu'on applique tous les paramètres de mitigations cités avant coïncide avec les résultats lorsqu'on applique uniquement la mise à jour BIOS. Cela signifie qu'il est difficile de limiter la perte de performance à partir du moment où cette mise à jour est nécessaire.

Solutions appliquées[modifier | modifier le code]

Processeur[modifier | modifier le code]

Intel[modifier | modifier le code]

Le président de Intel a annoncé la mitigation de la variante 1 par des solutions logicielles et les variantes 2 et 3 par des modifications matérielles à partir des processeurs 8ᵉ génération visant à augmenter la protection des données[16],[35].

AMD[modifier | modifier le code]

Des mises à jour logicielles de sécurité ont été mises en place par AMD au cours de l'année 2018 pour mitiger la vulnérabilité spectre[36].

Système d'exploitation[modifier | modifier le code]

Microsoft[modifier | modifier le code]

Le 15 mars 2018, Microsoft publie un article proposant trois solutions pour mitiger les vulnérabilités d’exécution spéculative[37] : Prévenir les techniques de spéculation, Enlever les données sensibles de la mémoire et Enlever les canaux d'observation.

Pour leurs solutions face à la variante 1 de Spectre, ils ont réalisé des modifications sur leur compilateur, en plus d'avoir recompilé des binaires du système Windows. La variante 2 a été contrée en réalisant des appels de nouvelles instructions du processeur pour éliminer la spéculation de branche dans les situations à risque[38].

Le 5 décembre 2018, Microsoft annonce la décision d'utiliser la solution Retpoline développée par Google pour améliorer les performances de son système d'exploitation face à la variante 2 de spectre[39].

Apple[modifier | modifier le code]

Dans une note technique, Apple mentionne avoir publié des mises à jour pour iOS et macOS High Sierra visant à améliorer la protection contre Spectre sans détailler les techniques de mitigation utilisées[40].

Linux[modifier | modifier le code]

Sur Linux, il est possible de savoir si son système est vulnérable aux deux variantes de Spectre dans le dossier /sys/devices/system/cpu/vulnerabilities avec les fichiers spectre_v1 et spectre_v2.

Un exemple du contenu des fichiers avec un système mis-à-jour : 

/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling

La variante 1 de Spectre a été contrée dans le noyau Linux en améliorant la fonction get_user qui était vulnérable[41], et la variante 2 a été contrée en utilisant la solution Retpoline[42].

Navigateur web[modifier | modifier le code]

Google[modifier | modifier le code]

Le navigateur Google Chrome propose une isolation de chaque site web entre différents processus[43]. Cette isolation ne mitige pas entièrement les attaques spectres, à cause de limitations liées au CORB (Cross-Origin Read Blocking) qui ne protègent pas tous les types de contenu web[44]. Il est donc conseillé aux développeurs web de suivre des pratiques de sécurité pour maximiser la mitigation[45].

L'objet Javascript SharedArrayBuffer a été désactivé sur la mise à jour de Chrome 63[45],[46]. À partir de Chrome 67, l'objet a été réactivé à condition que l'isolation de site soit activée dans le navigateur[47],[46].

Mozilla[modifier | modifier le code]

Pour leur navigateur Firefox, Mozilla ont désactivé l'objet Javascript SharedArrayBuffer par défaut à partir de la version 57[48]. Il est toutefois possible de l'activer en changeant une variable dans les options du navigateur[46].

De plus, la fonction Javascript performance.now(), permettant de créer un horodatage, qui est censé être plus précise que la fonction Date.now(), a subit quelques modifications[48]. À partir de la version 60, le résultat retourné par la fonction est arrondi à la milliseconde[49].

Références[modifier | modifier le code]

  1. ↑ University of Technology 2018, p. 9
  2. ↑ Jann Horn 2018, p. 12
  3. ↑ Shadow structure 2018, p. 10
  4. ↑ a et b InvisiSpec 2018, p. 13
  5. ↑ University of Technology 2018, p. 10
  6. ↑ InvisiSpec 2018, p. 3
  7. ↑ safespec
  8. ↑ PoisonIvy
  9. ↑ CHERI Université de Cambridge 2010, p. 20
  10. ↑ CHERI Implementation 2018, p. 2
  11. ↑ CHERI notes 2010, p. 10
  12. ↑ Intel 2018, p. 8
  13. ↑ AMD 2018
  14. ↑ rfc 2018
  15. ↑ CHERI cmov 2010, p. 8
  16. ↑ a et b retpoline 2018
  17. ↑ Lazy 2018, p. 4
  18. ↑ bleepingcomputer 2018
  19. ↑ Chromium 2018
  20. ↑ Project Zero 2018
  21. ↑ Brewster 2018
  22. ↑ Techrepublic 2018
  23. ↑ Dzone 2019
  24. ↑ Tencent's Xuanwu Lab 2018
  25. ↑ ascendr 2018
  26. ↑ Simakov 2018, p. 2
  27. ↑ Simakov 2018, p. 3
  28. ↑ Andrew Prout 2018
  29. ↑ RedHat Octobre 2018
  30. ↑ Corbet Novembre 2017
  31. ↑ Coldewey Janvier 2018
  32. ↑ PaX Team Octobre 2012, p. 3
  33. ↑ Shawn C. Aout 2018
  34. ↑ Andrew Prout 2018, p. 3
  35. ↑ Intel name 2018
  36. ↑ amd 2018
  37. ↑ swiat 2018
  38. ↑ Microsoft 2018
  39. ↑ Microsoft 2018
  40. ↑ Apple 2018
  41. ↑ LWN.net 2018
  42. ↑ LWN.net 2018
  43. ↑ Chromium 2018
  44. ↑ Chromium 2018
  45. ↑ a et b Chromium 2018
  46. ↑ a b et c Mozilla 2018
  47. ↑ Chromium 2018
  48. ↑ a et b Mozilla 2018
  49. ↑ Mozilla 2018

Bibliographie[modifier | modifier le code]

  • (en) Claudio Canella, Jo Van Bulck, Michael Schwarz, Moritz Lipp, Benjamin von Berg, Philipp Ortner, Frank Piessens, Dmitry Evtyushkin et Daniel Gruss, « A Systematic Evaluation of Transient Execution Attacks and Defenses », arxiv,‎ (lire en ligne)
  • (en) Esmaeil Mohammadian Koruyeh, Khaled N. Khasawneh, Chengyu Song et Nael Abu-Ghazaleh, « Spectre Returns! Speculation Attacks using the Return Stack Buffer », WOOT,‎ (lire en ligne)


  • (en) Jann Horn, « Reading privileged memory with a side-channel », Project Zero,‎ (lire en ligne)
  • (en) Thomas Brewster, « Massive Intel Vulnerabilities Just Landed -- And Every PC User On The Planet May Need To Update », Forbes,‎ (lire en ligne)
  • (en) James Sanders, « A year after Spectre and Meltdown, how well do patches work? », Techrepublic,‎ (lire en ligne)
  • (en) Giridhara Raam, « One Year Later, Looking Back at Meltdown and Spectre Bugs », Dzone,‎ (lire en ligne)
  • (en) Nikolay A. Simakov, Martins D. Innus, Matthew D. Jones, Joseph P. White, Steven M. Gallo, Robert L. DeLeon et Thomas R. Furlani, « Effect of Meltdown and Spectre Patches on the Performance of HPC Applications », arxiv,
  • (en) Andrew Prout, William Arcand, David Bestor, Bill Bergeron, Chansup Byun, Vijay Gadepal, Michael Houle, Matthew Hubbell, Michael Jones, Anna Klein, Peter Michaleas, Lauren Milechin, Julie Mullen, Antonio Rosa, Siddharth Samsi, Charles Yee, Albert Reuther et Jeremy Kepner, « Measuring the Impact of Spectre and Meltdown », (DOI 10.1109/HPEC.2018.8547554), p. 4
  • (en) Khaled N. Khasawneh, Esmaeil Mohammadian Koruyeh, Chengyu Song, Dmitry Evtyushkin, Dmitry Ponomarev et Nael Abu-Ghazaleh, « SafeSpec: Banishing the Spectre of a Meltdown with Leakage-Free Speculation », arxiv,‎ (lire en ligne)
  • (en) Tamara Silbergleit Lehman, Andrew D. Hilton et Benjamin C. Lee, « Poisonivy: safe speculation for secure memory », MICRO-49,‎ (DOI 10.1109/MICRO.2016.7783741)

Voir aussi[modifier | modifier le code]

Autres sources bibliographiques[modifier | modifier le code]

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Utilisateur:Seysn/Brouillon&oldid=155737969 ».