Mitigation de la vulnérabilité spectre

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 la vulnérabilité spectre, laissant alors une faille de sécurité sur de nombreux systèmes informatiques.

La recherche permanente sur l'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

On peut résumer la plupart des défenses face aux attaques spectres 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.

Ces trois catégories de mitigation peuvent être appliquées soit par des solutions logicielles, soit par des solutions matérielles.

Solutions matérielles

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 elle 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 (ce qui signifie que l'instruction est autorisée par le processeur et ne donne pas accès à des données sensibles), 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]. Dans la même idée, des chercheurs de l'université d'Illinois sont en train de développer une solution similaire à Safespec. 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 et 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

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 Trampoline) 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

Rétablir la sécurité

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 à 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 les fabricants concernés 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é existe toujours sur son système puisque de nouvelles variantes de Spectre ont été découvertes après les premiers correctifs[23].

Des moyens sont mis à 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

On peut mesurer les pertes de performances des techniques de mitigation 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 mitigation appliqués.

Des analyses ont été réalisées sur des calculs haute performance parallélisés 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 environ 2 à 3% plus lent pour des travaux parallèles à un nœud, et 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 de 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 après application des paramètres, 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

Processeur

Intel

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^e génération visant à augmenter la protection des données[16],[35].

AMD

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

Microsoft

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

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

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. Les mêmes informations peuvent être obtenues à l'aide de la commande linux lscpu

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

Google

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],[19]. À partir de Chrome 67, l'objet a été réactivé à condition que l'isolation de site soit activée dans le navigateur[46],[19].

Mozilla

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

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

Mozilla travaille en outre sur le projet Fission, qui traduit une réorganisation de l’architecture de Firefox afin de permettre l’isolation complète des sites web, comme une solution préventive plus générale de ces attaques. Cette fonctionnalité est activable à fins de test depuis la version 69 nightly[49],[50],[51].

Références

1. University of Technology 2018, p. 9
2. Jann Horn 2018, p. 12.
3. Shadow structure 2018, p. 10.
4. 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. retpoline 2018
17. Lazy 2018, p. 4.
18. bleepingcomputer 2018.
19. Mozilla 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. Chromium 2018
46. Chromium 2018.
47. Mozilla 2018
48. Mozilla 2018.
49. Mike Conley, « OOP iframes somewhat work now on Nightly! », Mozilla, 12 juillet 2019
50. « Fission Engineering Newsletter #1 », 4 février 2019
51. Anny Gakhokidze et Neha Kochar, « Introducing Site Isolation in Firefox », Mozilla, 18 mai 2021

Bibliographie

• (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,‎ 13 novembre 2018 (lire en ligne)
• (en) « Spectre Attacks: Exploiting Speculative Execution », 2018, p. 19
• (en) Esmaeil Mohammadian Koruyeh, Khaled N. Khasawneh, Chengyu Song et Nael Abu-Ghazaleh, « Spectre Returns! Speculation Attacks using the Return Stack Buffer », WOOT,‎ 20 juillet 2018 (lire en ligne)
• (en) Mengjia Yan, Jiho Choi, Dimitrios Skarlatos, Adam Morrison, Christopher W. Fletcher et Josep Torrellas, « InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy », IEEE,‎ 2018 (ISBN 978-1-5386-6240-3, DOI 10.1109/MICRO.2018.00042, lire en ligne)
• (en) Robert N. M. Watson, Peter G. Neumann, Jonathan Woodruff, Michael Roe, Jonathan Anderson, John Baldwin, David Chisnall, Brooks Davis, Alexandre Joannou, Ben Laurie, Simon W. Moore, Steven J. Murdoch, Robert Norton et Stacey Son, « Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture (Version 6) » (ISSN 1476-2986)
• (en) Jonathan Woodruff, Robert N. M. Watson, David Chisnall, Simon W. Moore, Peter G. Neumann, Michael Roe, Jonathan Anderson, Brooks Davis, Ben Laurie et Robert Norton, « The CHERI capability model: Revisiting RISC in an age of risk », IEEE,‎ 2018 (ISSN 1063-6897, DOI 10.1109/ISCA.2014.6853201)
• (en) Robert N. M. Watson, Jonathan Woodruff, Michael Roe, Simon W. Moore et Peter G. Neumann, « Capability Hardware Enhanced RISC Instructions (CHERI): Notes on the Meltdown and Spectre Attacks » (ISSN 1476-2986)
• (en) « Intel Analysis of Speculative Execution Side Channels », janvier 2018, p. 12
• (en) AMD64 Technology, « AMD - General-Purpose Programming », septembre 2007
• (en) « RFC: Speculative Load Hardening (a Spectre variant #1 mitigation) »
• (en) « Retpoline: A Branch Target Injection Mitigation », juin 2018
• (en) Julian Stecklina et Thomas Prescher, « LazyFP: Leaking FPU Register State using Microarchitectural Side-Channels », arxiv,‎ 19 juillet 2018 (lire en ligne)
• (en) « Mozilla Confirms Web-Based Execution Vector for Meltdown and Spectre Attacks », 4 janvier 2018
• « MDN web docs - SharedArrayBuffer », sur developer.mozilla.org, octobre 2018
• (en) Jann Horn, « Reading privileged memory with a side-channel », Project Zero,‎ 3 janvier 2018 (lire en ligne)
• (en) Thomas Brewster, « Massive Intel Vulnerabilities Just Landed -- And Every PC User On The Planet May Need To Update », Forbes,‎ 3 janvier 2018 (lire en ligne)
• (en) James Sanders, « A year after Spectre and Meltdown, how well do patches work? », Techrepublic,‎ 21 décembre 2018 (lire en ligne)
• (en) Giridhara Raam, « One Year Later, Looking Back at Meltdown and Spectre Bugs », Dzone,‎ 3 janvier 2019 (lire en ligne)
• (en) « Spectre CPU Vulnerability Online Checker »
• (en) « Spectre JS PoC for Chrome », sur github.com
• (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, janvier 2018
• (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 », septembre 2018 (DOI 10.1109/HPEC.2018.8547554), p. 4
• (en) « Is CPU microcode available to address CVE-2017-5715 via the microcode_ctl package? », octobre 2018
• (en) « KAISER: hiding the kernel from user space », novembre 2017
• (en) « Kernel panic! What are Meltdown and Spectre, the bugs affecting nearly every computer and device? », janvier 2018
• (en) « PaX - kernel self-protection », 9 octobre 2012, p. 46
• (en) « Nightmares (Meltdown/Spectre/L1TF) never goes away », aout 2018
• (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,‎ 16 juin 2018 (lire en ligne)
• (en) Tamara Silbergleit Lehman, Andrew D. Hilton et Benjamin C. Lee, « Poisonivy: safe speculation for secure memory », MICRO-49,‎ octobre 2016 (DOI 10.1109/MICRO.2016.7783741)
• (en) swiat, « Mitigating speculative execution side channel hardware vulnerabilities », Security Research & Defense,‎ 15 mars 2018 (lire en ligne)
• swiat, « Mitigating speculative execution side channel hardware vulnerabilities », Security Research & Defense,‎ 15 mars 2018 (lire en ligne)
• « Mitigating Spectre variant 2 with Retpoline on Windows », 5 décembre 2018
• « À propos des vulnérabilités de l’exécution spéculative au sein des processeurs basés sur l’architecture ARM et Intel », 5 juin 2018
• (en) « [PATCH v4 00/10] prevent bounds-check bypass via speculative execution », 18 janvier 2018
• (en) « Meltdown/Spectre mitigation for 4.15 and beyond », 15 janvier 2018
• (en) « AMD Processor Security Updates », sur www.amd.com
• (en) « Site Isolation - The Chromium Projects », sur www.chromium.org
• (en) « Mitigating Side-Channel Attacks », sur www.chromium.org
• (en) « Post-Spectre Threat Model Re-Think », 29 mai 2018
• (en) « Re-enable SharedArrayBuffer + Atomics », 13 mai 2018
• « MDN web docs - SharedArrayBuffer », sur developer.mozilla.org, octobre 2018
• « Mitigations landing for new class of timing attack », sur blog.mozilla.org, 3 janvier 2018
• « MDN web docs - performance.now() », sur developer.mozilla.org, septembre 2018

Voir aussi

Autres sources bibliographiques

• (en) Jonathan Corbet, « Meltdown and Spectre mitigations — a February update », LWN.net,‎ 5 février 2018 (lire en ligne)
• (en) Jonas Depoix et Philipp Altmeyer, « Detecting Spectre Attacks by identifying Cache Side-Channel Attacks using Machine Learning », 5 février 2018, p. 11
• (en) « About the security content of macOS High Sierra 10.13.3 », 17 novembre 2018
• (en) Lars Müller, « KPTI a Mitigation Method against Meltdown », août 2018
• (en) « Site Isolation Design Document »
• (en) Vladimir Kiriansky, Ilia Lebedev, Saman Amarasinghe, Srinivas Devadas et Joel Emer, « DAWG: A Defense Against Cache Timing Attacks in Speculative Execution Processors », octobre 2018 (DOI 10.1109/MICRO.2018.00083), p. 14