Attaque Downfall
(downfall.page)- Il s’agit de la vulnérabilité CVE-2022-40982 affectant les processeurs Intel largement utilisés sur les ordinateurs personnels et dans le cloud, permettant de voler les données d’autres utilisateurs partageant la même machine
- Le cœur de la vulnérabilité est que, lors du processus d’optimisation mémoire, l’instruction Gather expose le contenu interne du fichier de registres vectoriels pendant l’exécution spéculative
- L’attaque est mise en œuvre via les techniques GDS et GVI et, dans la démonstration, montre des fuites au-delà des frontières d’isolation, notamment des clés AES, des données du noyau Linux et la surveillance de caractères imprimables
- La plage d’impact va des Intel Core de 6e génération Skylake à la 11e génération Tiger Lake, et les utilisateurs du cloud peuvent être touchés même sans posséder directement un appareil Intel
- La mise à jour de microcode d’Intel bloque les résultats transitoires de Gather, mais certaines charges de travail peuvent subir jusqu’à 50 % de surcharge après application de l’atténuation
La vulnérabilité visée par Downfall
- Downfall cible une faille importante dans des processeurs récents utilisés sur les ordinateurs personnels et dans le cloud
- Cette vulnérabilité est identifiée sous le nom CVE-2022-40982
- Elle permet d’accéder aux données d’autres utilisateurs partageant le même ordinateur et de les voler
- Une application malveillante téléchargée depuis un app store peut dérober des informations sensibles comme des mots de passe, des clés de chiffrement, des informations bancaires, des e-mails privés ou des messages
- Dans le cloud, un client malveillant peut voler les données et les identifiants d’autres clients partageant la même machine cloud
Cause technique de la vulnérabilité
- Une fonction d’optimisation mémoire des processeurs Intel expose involontairement à des logiciels le contenu de registres matériels internes
- Un logiciel non fiable peut ainsi accéder à des données d’autres programmes auxquelles il ne devrait normalement pas avoir accès
- L’instruction Gather, utilisée pour lire plus rapidement des données dispersées en mémoire, divulgue le contenu du fichier de registres vectoriels internes pendant l’exécution spéculative
- Les techniques Gather Data Sampling (GDS) et Gather Value Injection (GVI) sont utilisées pour exploiter cette faille
- Les détails techniques sont regroupés dans le papier Downfall
Exemples de fuites confirmés par la démonstration
- La démonstration de Downfall montre que des données sensibles peuvent fuiter à travers différentes frontières d’isolation
Systèmes affectés et conditions de l’attaque
- Les appareils affectés sont les équipements informatiques basés sur des processeurs Intel Core de 6e génération Skylake à 11e génération Tiger Lake
- Une liste plus complète des processeurs affectés sera fournie dans la liste des processeurs affectés d’Intel
- Les utilisateurs du cloud peuvent être touchés même s’ils ne possèdent pas d’appareil physique basé sur Intel
- Intel détient plus de 70 % du marché des serveurs
- Les attaquants peuvent viser des identifiants à forte valeur comme les mots de passe et les clés de chiffrement
- Le vol d’identifiants peut conduire non seulement à une atteinte à la confidentialité, mais aussi à d’autres attaques compromettant la disponibilité et l’intégrité des systèmes
- GDS est relativement facile à mettre en œuvre dans une attaque réelle
- Il a fallu deux semaines pour développer une attaque de bout en bout volant des clés de chiffrement dans OpenSSL
- Il suffit que l’attaquant et la victime partagent le même cœur physique du processeur
- Sur les ordinateurs modernes mettant en œuvre le multitâche préemptif et le multithreading simultané, ce partage se produit fréquemment
Frontières d’isolation, SGX et impact sur les navigateurs
- Downfall affecte aussi des frontières d’isolation courantes
- machines virtuelles
- processus
- isolation utilisateur-noyau
- Intel SGX est également affecté
- Intel SGX est une fonctionnalité de sécurité matérielle des CPU Intel destinée à protéger les données des utilisateurs contre les logiciels malveillants
- Une exploitation à distance via un navigateur web est théoriquement possible
- Davantage de recherche et de travail d’ingénierie sont toutefois nécessaires pour démontrer une attaque réussie dans un navigateur
Période d’exposition et difficulté de détection
- Les utilisateurs sont exposés à cette vulnérabilité depuis au moins 9 ans
- Les processeurs concernés existent depuis 2014
- Les attaques Downfall sont difficiles à détecter
- Leur exécution ressemble pour l’essentiel à celle d’applications légitimes
- En théorie, il serait possible de construire un système détectant des comportements anormaux, comme des défauts de cache excessifs, à l’aide de compteurs de performance matériels
- Les antivirus commerciaux classiques ne peuvent pas détecter cette attaque
Mesures d’atténuation et surcharge de performance
- Intel a diffusé une mise à jour de microcode
- Cette mise à jour bloque les résultats transitoires de l’instruction Gather
- Elle empêche le code de l’attaquant d’observer les données spéculatives produites par Gather
- Le coût de l’atténuation dépend de la présence de Gather sur le chemin d’exécution critique du programme
- Selon Intel, certaines charges de travail peuvent subir jusqu’à 50 % de surcharge
- Il n’est pas sûr de désactiver l’atténuation sous prétexte que la charge de travail n’utilise pas Gather
- Les CPU récents utilisent des registres vectoriels pour optimiser des tâches courantes, comme la copie mémoire ou le basculement du contenu des registres
- Dans ce processus, des données peuvent fuiter vers du code non fiable exploitant Gather
Calendrier de publication et code de reproduction
- Cette vulnérabilité est restée sous embargo pendant près d’un an
- Elle a été signalée à Intel le 24 août 2022
- Downfall a été présenté le 9 août 2023 à BlackHat USA et le 11 août 2023 à l’USENIX Security Symposium
- Le code de reproduction est publié sur GitHub POC
Points d’attention pour les autres concepteurs de processeurs
- D’autres processeurs possèdent eux aussi en interne des mémoires SRAM partagées, comme des fichiers de registres matériels et des fill buffers
- Les fabricants doivent concevoir avec plus de soin les unités mémoire partagées afin d’éviter les fuites de données entre différents domaines de sécurité
- Ils doivent investir davantage dans la vérification et les tests de sécurité
Nom et vulnérabilités associées
- Le nom Downfall vient du fait qu’elle fait tomber la plupart des frontières de sécurité de base des ordinateurs
- Downfall peut être considéré comme un successeur des précédentes vulnérabilités de fuite de données CPU Meltdown et Fallout
- Dans cette lignée, Downfall contourne à nouveau les atténuations précédentes
Recommandations des éditeurs et documentation technique
- Recommandations de sécurité :
- MITRE : CVE-2022-40982
- Intel : INTEL-SA-00828
- AWS : AWS-2023-007
- GCP : GCP-2023-024
- Debian : CVE-2022-40982
- Ubuntu : CVE-2022-40982
- Red Hat : CVE-2022-40982
- VMware : Réponse à Gather Data Sampling
- Documentation technique d’Intel :
1 commentaires
Avis sur Hacker News
Même après les premières attaques Spectre, il paraît étrange que des chercheurs externes continuent de trouver des attaques similaires, puis que les fabricants de puces les corrigent ensuite
En principe, ce sont les fabricants de puces qui sont les experts de l’exécution spéculative ; ils savent précisément comment fonctionnent leurs puces et disposent de suites de vérification, de simulateurs, voire de spécifications internes lisibles par machine, ce qui devrait les placer dans la meilleure position pour les découvrir
Les chercheurs externes, eux, doivent explorer une boîte noire et faire de la rétro-ingénierie à partir de sources bien moins favorables, comme les brevets ; pourtant, même des années plus tard, des individus ou des groupes externes trouvent encore ce type de vulnérabilités
Avant Spectre, on peut comprendre que ce vecteur d’attaque n’ait pas été envisagé, mais une fois le mécanisme général révélé, les fabricants de puces n’auraient-ils pas dû réunir leurs meilleurs cerveaux et leur dire : « passez tout au peigne fin et trouvez les autres attaques de type Spectre » ?
Peut-être qu’ils les connaissent déjà toutes, mais les enterrent en espérant qu’elles ne soient pas rendues publiques, pour éviter de perdre la face et de dégrader les performances
Quand quelque chose est utilisé par des milliards de personnes, il est normal que davantage de problèmes, de défauts et d’exploits soient découverts par l’extérieur que par ceux qui l’ont conçu. Le simple fait que ces problèmes existent ne permet ni d’étayer ni de réfuter des conclusions supplémentaires sur leurs causes
Les chercheurs en sécurité ont intérêt à trouver quelque chose pour se construire une réputation. Il arrive souvent qu’ils présentent comme une faille de sécurité susceptible d’ébranler le monde quelque chose qui n’a guère d’intérêt pour de vrais attaquants
A-t-on déjà observé des attaques par exécution spéculative dans des environnements réels ? Probablement pas. Dans ce cas, les fabricants de puces ont peu de raisons d’y consacrer des sommes énormes
Les vrais clients ne subissent pas de préjudice, sauf quand un chercheur externe force la main et fait publier un nouveau microcode qui ralentit les performances
Il est aussi notable que les mesures d’atténuation de ces attaques soient toujours accompagnées d’un interrupteur pour les désactiver. Ce n’est pas une forme courante pour un correctif de sécurité, mais dans beaucoup de cas c’est parce que ces attaques n’ont pas grande importance
Les logiciels qui tournent sur le même cœur physique ou le même CPU physique ont généralement le même niveau de confiance, ou bien sont isolés dans une sandbox suffisamment forte pour ne pas pouvoir mener l’attaque
Intel conçoit sans aucun doute ses puces « aussi intelligemment que possible » et, par définition, elles ne peuvent donc pas être entièrement déboguées
Il est aussi important de noter que ce ne sont pas des bugs. La conception fonctionne comme prévu. On savait que les performances d’un CPU pouvaient varier selon le code exécuté précédemment, et cela avait été accepté parce que le coût des alternatives en matière de consommation, de performances et de surface était jugé trop élevé. C’est cela, l’ingénierie : peser les alternatives et choisir
Dans ce cas, les CPU sont devenus suffisamment rapides pour qu’une infime fraction de bit par itération devienne une bande passante exploitable, mais il a fallu que quelqu’un le démontre pour que l’industrie le comprenne. C’est ce qui a changé le jugement d’ingénierie
Le lien vers l’article d’Intel est mort, et le bon lien semble être celui-ci : https://www.intel.com/content/www/us/en/developer/articles/t...
Comme remarque générale, y a-t-il encore beaucoup de clouds qui exécutent les workloads de différents utilisateurs sur le même cœur physique ? Je pensais que la plupart avaient modifié leurs ordonnanceurs il y a quelques années pour empêcher les fuites inter-domaines entre hyperthreads.
L’affirmation selon laquelle cela affecte tous les internautes me paraît très exagérée. Je ne vois pas non plus d’exploit basé sur le navigateur, et même s’il en existait un, il ne toucherait qu’une infime minorité d’utilisateurs ciblés. Plusieurs années ont passé depuis Spectre, et je me demande si des attaques par exécution spéculative ont déjà été observées en conditions réelles.
Ce qui est plus intéressant, c’est que ces bogues d’exécution spéculative semblent toujours pouvoir être corrigés par microcode. Quand ils sont apparus, on craignait de devoir jeter et remplacer en masse des puces physiques, mais est-ce que cela a déjà été nécessaire en pratique ?
À ma connaissance, tous les bogues ont pu être traités par une combinaison de changements logiciels et de microcode, avec parfois seulement un certain coût en performances. Aucun bogue n’a nécessité de nouveau silicium. Les seules exceptions seraient des cas réellement impossibles à patcher, comme les premières versions d’AMD SEV qui ont effectivement été « jailbreakées ».
Bien sûr, il existe des cas partagés comme la série T d’AWS, et d’autres clouds doivent avoir des équivalents, mais j’imagine qu’on peut empêcher les fuites entre tenants en ajoutant des « flushs » supplémentaires entre utilisateurs.
Évidemment, les fuites entre processus au sein d’un même tenant restent un problème, que ce soit dans le cloud ou on-premise, et il faut finalement décider à quel point on fait confiance aux processus de sa propre machine pour ne pas devenir malveillants.
Exécuter du code appartenant à différents domaines de sécurité sur le même cœur de processeur physique semble impossible à faire correctement, et il est sans doute temps d’arrêter.
Les cas courants se résument en fait à deux choses : les VM et JavaScript.
Il faut renoncer aux VM. Il faut dédier certains cœurs à certaines VM, ou au minimum à certains clients.
JavaScript est plus compliqué.
Dans tous les cas, il ne faut pas sacrifier les performances dans le cas général.
L’IOPU serait chargé de piloter les autres matériels du système, sans avoir besoin d’être très performant.
Le SPU serait optimisé pour le code scalaire et le code très branché qui doivent tourner vite.
Le SPU n’aurait besoin que d’une sécurité minimale, par exemple l’empêcher de lire de la mémoire arbitraire lors des accès à la RAM. Comme il n’exécuterait qu’un seul programme à la fois, l’exécution spéculative ne poserait pas problème.
Sur mon système, peu de programmes ont besoin de beaucoup de puissance de calcul, et même quand c’est le cas, c’est intermittent ; il n’y aurait donc probablement pas beaucoup de changements de tâche sur le SPU.
Ces attaques CPU montrent qu’un système à temps partagé sûr, où les utilisateurs exécutent du code machine arbitraire, n’est plus réaliste.
Le temps partagé subsistera encore dans les cas où les utilisateurs se font confiance, par exemple des personnes d’un même projet partageant une machine de build.
L’idée qu’on puisse empêcher deux programmes s’exécutant sur un ordinateur de s’espionner mutuellement est du même ordre.
Avis de sécurité Intel : https://www.intel.com/content/www/us/en/developer/articles/t...
Fusion dans le noyau Linux : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Que seuls les processeurs jusqu’à la 11e génération soient concernés me surprend : il ne semble pas que cette vulnérabilité ait été divulguée à Intel assez tôt pour être corrigée dès la 12e génération. Du coup, je me demande si elle n’a pas été résolue par hasard en corrigeant autre chose.
En lisant l’article, on voit qu’il dit : « Intel a déclaré que les CPU récents comme Alder Lake, Raptor Lake et Sapphire Rapids ne sont pas affectés. Cela semble toutefois être davantage un effet secondaire de changements architecturaux importants qu’une considération de sécurité. »
Au final, elle a été corrigée de manière fortuite, ou du moins cet exploit précis ne fonctionne plus.
D’après la FAQ, les utilisateurs ont été exposés à cette vulnérabilité pendant au moins 9 ans, puisque les processeurs affectés existaient depuis 2014.
C’est étonnant qu’une vulnérabilité de ce type puisse passer inaperçue pendant des années, puis que quelqu’un ne mette que deux semaines à coder un exploit.
Voir aussi l’article de LWN : https://lwn.net/Articles/940783/
Sous Linux, pour les CPU ne disposant pas d’un microcode mis à jour, AVX est complètement désactivé comme mesure d’atténuation de ce problème. De mon point de vue, c’est assez radical et cela risque de se sentir nettement. J’ai maintenant envie de vérifier si je peux obtenir un microcode mis à jour.
gather_data_sampling=force. Par défaut, AVX reste activé et le système est marqué comme vulnérable.En regardant https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... :
si
gather_data_sampling=forceest spécifié, la mesure d’atténuation par microcode est utilisée lorsque c’est possible, et AVX est désactivé sur les systèmes affectés dont le microcode n’a pas été mis à jour pour inclure cette atténuation.Pour info, je travaille sur Linux chez Intel. Il est tout à fait possible que j’aie écrit ou retouché la documentation et les journaux de modifications qui embrouillent les gens.
[ 0.000000] microcode: updated early: 0x27 -> 0x28, date = 2019-11-12J’utilise Haswell. Existe-t-il une liste des CPU qui reçoivent un microcode mis à jour ? Dommage.
Il est aussi intéressant de noter que GCP a corrigé ce problème : https://cloud.google.com/support/bulletins#gcp-2023-024
Les données et les instances des clients AWS ne sont pas affectées par ce problème, et aucune action n’est requise de leur part.
AWS a conçu et mis en œuvre une infrastructure dotée de protections contre cette catégorie de problèmes. Les instances Amazon EC2, y compris Lambda, Fargate et les autres services de calcul et de conteneurs gérés par AWS, protègent les données des clients contre GDS grâce au microcode et à des mesures d’atténuation logicielles.
L’impact sur les performances est énorme. Il est annoncé comme pouvant aller jusqu’à 50 %, et 70 % des processeurs Intel récents seraient concernés.
https://access.redhat.com/solutions/7027704
L’impact sur les performances se limite aux applications utilisant les instructions gather fournies par Intel Advanced Vector Extensions (AVX2 et AVX-512), ainsi que l’instruction CLWB. L’impact réel dépend de la fréquence à laquelle l’application utilise ces instructions.
Si, après une analyse de risque approfondie, l’utilisateur décide de désactiver les mesures d’atténuation — par exemple si le système n’est pas multi-tenant et n’exécute pas de code non fiable — il peut le faire.
Après avoir appliqué les mises à jour du microcode et du noyau, il est possible de désactiver l’atténuation en ajoutant
gather_data_samping=offà la ligne de commande du noyau. Ou bien, pour désactiver toutes les mesures d’atténuation de l’exécution spéculative du CPU, y compris GDS, on peut utilisermitigations=off.Il faut toujours se méfier des affirmations du type « jusqu’à ».
La NES intégrait un chipset dans lequel tout un 6502 était enfoui, et pour le prix d’une pizza on peut acheter une puce ARM Rockchip avec des cœurs mixtes sur le die. Les fabricants de puces n’ont pas forcément à résoudre tous les cas limites pour l’éternité, et on pourrait peut-être renvoyer ce type de mitigation des attaques par canal auxiliaire vers nous, qui consommons ces puces.
Plutôt que d’en faire un choix binaire où l’on active ou désactive entièrement le SMT, pourquoi ne pas envoyer le code non fiable vers les « cœurs pourris », et demander aux clients de « prouver » qu’il peut être promu vers des cœurs avec SMT ?
Personne n’a envie de casser une puce qui exécute des traitements de paie ultra-critiques et sur laquelle personne ne peut ajouter autre chose à la carte. Mais être obligé d’étiqueter ce qui peut tourner en toute sécurité avec SMT, et sinon se retrouver cantonné à des cœurs plus sûrs, ça me semble acceptable.
Un stagiaire qui n’a aucune idée de ce que c’est pourrait tomber dessus en cherchant, comprendre ce qu’est réellement ce vecteur d’attaque, et élaborer un plan de défense.
C’est moi qui suis bizarre ?
Cœurs performance × cœurs efficacité, c’est possible.
Mais personne ne voudra être celui qui propose des cœurs de confiance × des cœurs non fiables « pourris ». Même avec tous les avantages du monde, ça sera enterré sous le discours selon lequel cela « alimente l’anxiété ». C’est comme ça.