GoFetch : une nouvelle attaque par canal auxiliaire exploitant un préchargeur dépendant des données en mémoire
(gofetch.fail)- Le préchargeur dépendant des données en mémoire (DMP) traite des valeurs de données du code cryptographique comme des adresses, ce qui peut entraîner une fuite de clé secrète même dans des implémentations en temps constant
- Sur les CPU Apple m-series, lorsque la valeur chargée depuis la mémoire ressemble à un pointeur, le DMP tente de la déréférencer, ce qui remet en cause l’hypothèse de programmation en temps constant de séparation entre données et adresses
- Les chercheurs ont démontré sur Apple m1 une extraction de clé de bout en bout contre OpenSSL Diffie-Hellman, le déchiffrement RSA de Go, CRYSTALS-Kyber et CRYSTALS-Dilithium, et ont observé un comportement DMP similaire sur m2 et m3
- Sur m3, le bit DIT désactive efficacement le DMP, mais cela ne s’applique pas à m1 et m2 ; un bit de configuration HID découvert en avril 2024 est difficile à exploiter immédiatement faute de prise en charge par le noyau macOS
- Les mesures d’atténuation incluent le maintien à jour des logiciels, l’usage des bits DIT/DOIT sur certains CPU, le masquage des entrées et l’évitement du partage matériel ; l’évaluation de la vulnérabilité nécessite cryptanalyse et inspection du code
Le cœur de l’attaque GoFetch
- GoFetch est une attaque par canal auxiliaire microarchitectural qui exploite un préchargeur dépendant des données en mémoire (DMP)
- Elle permet d’extraire des clés secrètes même depuis des implémentations cryptographiques écrites en temps constant
- Les cibles démontrées par les chercheurs sont les suivantes
- OpenSSL Diffie-Hellman Key Exchange
- Go RSA decryption
- CRYSTALS-Kyber
- CRYSTALS-Dilithium
- L’article et les outils sont disponibles ici : Paper, Tools
Comment le DMP brise l’hypothèse du temps constant
- Le DMP des CPU Apple m-series s’active lorsqu’une donnée chargée depuis la mémoire ressemble à une valeur de pointeur et tente alors de la déréférencer
- La programmation en temps constant impose de séparer données et adresses afin que les branches, boucles, accès mémoire et indices de tableau ne varient pas selon des valeurs secrètes
- Même si le code victime respecte cette règle, le DMP peut créer à sa place, au niveau matériel, des accès mémoire dépendants du secret
- Il en résulte des écarts de temps observables dans un code qui devrait être en temps constant, ouvrant la voie à une attaque d’extraction de clé
Déroulement de l’attaque
- L’attaquant construit des entrées choisies pour l’opération cryptographique de façon à ce qu’une valeur intermédiaire ressemblant à un pointeur n’apparaisse que si une partie de la clé secrète a été correctement devinée
- Il vérifie ensuite par analyse temporelle du cache si le DMP a effectué un déréférencement, afin de valider son hypothèse
- Une fois la bonne hypothèse confirmée, il procède de la même manière pour le groupe suivant de bits de clé
- Cette procédure permet une extraction de clé de bout en bout sur des implémentations de cryptographie classique comme post-quantique
Processeurs touchés et observations
- L’attaque GoFetch de bout en bout a été réalisée sur du matériel équipé de processeurs Apple m1
- Les CPU m2 et m3 présentent eux aussi des schémas d’activation du DMP exploitables de manière similaire
- D’autres variantes m-series comme le m2 Pro n’ont pas été testées, mais elles utilisent probablement la même microarchitecture que les modèles simples, ce qui laisse penser qu’un DMP exploitable pourrait aussi y être présent
- La microarchitecture Raptor Lake de 13e génération d’Intel dispose également d’un DMP
- Cependant, ses critères d’activation sont plus restrictifs, ce qui la rend robuste face à l’attaque GoFetch
Différence avec Augury
- Le DMP des Apple m-series a été découvert pour la première fois par Augury
- Augury estimait que le DMP pouvait, dans certaines conditions, mélanger données et adresses
- Les chercheurs de GoFetch jugent les critères d’activation du DMP décrits par Augury trop restrictifs
- En pratique, toute valeur chargée depuis la mémoire peut devenir candidate au déréférencement, ce qui mène à une attaque de bout en bout contre du vrai code cryptographique en temps constant
Contexte : cache et préchargeurs
- Les processeurs modernes utilisent des caches pour réduire la latence des accès mémoire
- Les données déjà consultées restent dans le cache, ce qui accélère les accès suivants
- Un attaquant exécuté sur la même machine peut observer l’état du cache partagé et en déduire les schémas d’accès de la victime
- Un préchargeur classique prédit les futures adresses mémoire à partir de l’historique des adresses déjà consultées
- Le DMP, lui, prend aussi en compte le contenu mémoire pour décider quelles données charger, afin de gérer des schémas d’accès irréguliers comme les parcours de listes chaînées
- Comme ce mécanisme mélange données et adresses au niveau matériel, il peut faire se comporter toute la pile de calcul comme si elle n’était pas en temps constant
Évaluer la vulnérabilité et atténuer le risque
- Pour déterminer si une implémentation est vulnérable, il faut savoir à quel moment et de quelle manière des valeurs intermédiaires peuvent, selon le secret, ressembler à des pointeurs
- Cette évaluation nécessite cryptanalyse et inspection du code ; elle est manuelle, lente et ne permet pas d’exclure d’autres modes d’attaque
- Sur certains processeurs, il est possible de désactiver le DMP
- En avril 2024, Hector Martin (marcan) a découvert sur les CPU m1 et m2 un bit de configuration HID désactivant le DMP :
SYS_APL_HID11_EL1[30]- Ce chicken bit nécessite une prise en charge par le noyau
- macOS ne fournit actuellement pas cette prise en charge
- Plus d’informations dans le billet de @marcan
- Il est recommandé aux utilisateurs d’utiliser les logiciels les plus récents et d’appliquer régulièrement les mises à jour
- Les développeurs de bibliothèques cryptographiques peuvent activer les bits DIT/DOIT lorsque le CPU le permet
- Le masquage des entrées peut aider, pour certains schémas cryptographiques, à éviter des valeurs intermédiaires contrôlées par l’attaquant
- Éviter le partage matériel afin que l’attaquant ne puisse pas mesurer l’activation du DMP peut aussi renforcer la sécurité des protocoles cryptographiques
Publication et mises à jour ultérieures
- Les chercheurs ont communiqué leurs résultats à Apple le 5 décembre 2023, soit 107 jours avant la publication publique
- En août 2024, GoFetch a reçu le Pwnie Award 2024 Best Cryptographic Attack
- En décembre 2024, des travaux de suivi ont rétroconçu la sémantique du DMP d’Intel et montré une technique permettant des fuites d’information même lorsque le DMP déréférence des pointeurs invalides
- L’article de suivi : Peek-a-Walk: Leaking Secrets via Page Walk Side Channels
- Le code est disponible dans le dépôt GitHub de Peek-a-Walk
1 commentaires
Avis sur Hacker News
À l’époque où l’on intègre des choses comme des cœurs efficients, il nous faudra peut-être aussi des cœurs cryptographiques dans les architectures modernes.
Ces cœurs devraient fournir explicitement des garanties liées aux algorithmes en temps constant, et ne pas faire de préchargement, de prédiction de branchement, etc.
Un peu comme Itanium, mais limité au « processeur cryptographique » ; avec beaucoup de fonctionnalités en moins, la surface de silicium du cœur lui-même ne devrait en principe pas être très grande.
Pour quelqu’un qui implémente du code cryptographique, ce genre de problème doit être à donner envie de boire. C’est déjà un combat difficile dans le meilleur des cas, mais même si tout est correctement implémenté, les innombrables fonctionnalités actuelles et futures des processeurs peuvent casser le code à tout moment.
Mais un coprocesseur cryptographique est une solution beaucoup trop disruptive. Il faudrait construire toute une montagne d’infrastructure pour basculer vers ce cœur et en revenir, partager la mémoire, etc.
Plus grave encore, on ne peut pas simplement déplacer la multiplication RSA sur ce cœur et en rester là. La clé a bien été analysée quelque part : le parseur doit-il lui aussi tourner sur le cœur crypto ? Et si elle arrive par le réseau ? Même si toutes les clés sont protégées, est-ce acceptable si un canal auxiliaire CPU divulgue les messages chiffrés ? Peut-on dire que ce n’est pas grave parce que ce ne sont pas des clés ?
Si l’on voit moins ce type d’attaque dans le code non cryptographique, c’est parce que trouver une cible est beaucoup trop spécifique à chaque application, alors que dans les bibliothèques crypto tout le monde s’accorde à dire qu’une fuite de clé est mauvaise.
Au final, les concepteurs de processeurs ne doivent pas casser les hypothèses, et au minimum ils devraient nous parler avant de le faire.
L’unité d’abstraction serait probablement au niveau du thread.
https://support.apple.com/guide/security/secure-enclave-sec5...
Mais les architectures cloud optimisées pour les coûts se sont rabattues sur du matériel grand public et ont fini par dominer le marché des CPU ; désormais, même pour les applications à grande échelle, les CPU grand public sont la seule option réaliste.
Pour permettre de nouveaux algorithmes, il pourrait aussi être utile d’ajouter quelques instructions d’opérations cryptographiques primitives.
Selon l’article, « OpenSSL a indiqué que les attaques par canal auxiliaire locales étaient hors de son modèle de menace, et l’équipe Go Crypto considère que la gravité de cette attaque est faible ».
La conclusion ultime de ce genre d’attaque par canal auxiliaire serait un CPU qui ne fait aucune optimisation, et où chaque instruction s’exécute dans le même nombre de cycles dans toutes les situations.
Mais cela n’arrivera jamais. Personne ne veut d’un CPU lent.
Si ce n’est pas exploitable à distance, je ne pense pas que ce soit un problème dont il faille s’inquiéter. Bien sûr, la virtualisation cloud multi-tenant, elle, est exclue.
Pas d’exécution spéculative, pas de préchargement, un cœur comme le pipeline en 5 étapes qu’on voit dans un cours d’architecture des ordinateurs 101.
Il existe bien quelques fournisseurs cloud qui louent du temps de calcul sur des Mac Mini en rack, mais ils ne sont pas nombreux, et c’est pour des charges de travail ou des tâches de build très spécifiques.
Cela peut poser problème à ceux qui paient cher pour ce type de service, mais l’immense majorité des appareils Apple Silicon n’hébergeront jamais de services cloud.
Si l’on isole du code sur un cœur précis, alors, en supposant que tout fonctionne comme prévu, l’exploit ne peut pas compromettre d’autres tenants.
À la question « Peut-on désactiver le DMP ? », il est répondu : « Oui, mais seulement sur certains processeurs. Sur les CPU M3, le réglage du bit DIT désactive effectivement le DMP, mais ce n’est pas le cas sur les M1 et M2. »
Il doit bien y avoir quelque part un chicken bit pour le désactiver, non ?
Est-ce possible en Swift, ou faut-il de l’assembleur ?
À la lecture, on dirait que des bibliothèques comme libsodium pourraient simplement définir le bit de désactivation avant les opérations cryptographiques sensibles sur M3 et versions ultérieures.
Il semble aussi qu’il faille connaître à l’avance certains aspects de la clé.
C’est très élégant, mais ça n’a pas l’air particulièrement pratique.
Cela m’a rappelé l’attaque Augury de 2022. Elle exploitait elle aussi le préchargement DMP des CPU Apple Silicon.
[1] : https://www.prefetchers.info
Pourquoi Apple a-t-elle autant de portes dérob… de simples bugs matériels ?
Pour répondre à cette théorie du complot absurde sur les portes dérobées : les gens veulent des CPU rapides, donc les processeurs ont des caches et des écarts de timing. On ne peut pas avoir à la fois du temps constant et des performances élevées, et Apple n’est pas la seule entreprise à avoir du préchargement.
Voici la documentation d’Apple sur la façon d’activer des opérations en temps constant pour la cryptographie. On dirait presque que c’est conçu intentionnellement dans le matériel. Très étrange : https://developer.apple.com/documentation/xcode/writing-arm6...
Si vous écrivez des routines cryptographiques, utilisez la bibliothèque cryptographique de la plateforme ou suivez la documentation.
https://developer.apple.com/documentation/xcode/writing-arm6...
Les analyses antimalware et les antivirus ont maintenant du sens aussi sur Mac et iPad.
L’attaquant doit s’exécuter sur le même matériel.