La correction du canal secondaire nouvellement découverte (voir aussi: https://planete-warez.net/topic/4601/les-pirates-peuvent-forcer-les-navigateurs-ios-et-macos-à-divulguer-les-mots-de-passe-et-bien-plus-encore?_=1711098143319) aura probablement un impact négatif sur les performances.
Une vulnérabilité récemment découverte dans les puces de la série M d’Apple permet aux attaquants d’extraire les clés secrètes des Mac lorsqu’ils effectuent des opérations cryptographiques largement utilisées, ont révélé des chercheurs universitaires dans un article publié jeudi.
La faille – un canal secondaire permettant des extractions de clés de bout en bout lorsque les puces Apple exécutent des implémentations de protocoles cryptographiques largement utilisés – ne peut pas être corrigée directement car elle découle de la conception microarchitecturale du silicium lui-même. Au lieu de cela, il ne peut être atténué qu’en intégrant des défenses dans des logiciels cryptographiques tiers qui pourraient dégrader considérablement les performances de la série M lors de l’exécution d’opérations cryptographiques, en particulier sur les générations M1 et M2 précédentes. La vulnérabilité peut être exploitée lorsque l’opération cryptographique ciblée et l’application malveillante dotée des privilèges système utilisateur normaux s’exécutent sur le même cluster de processeurs.
Méfiez-vous des optimisations matérielles
La menace réside dans le prérécupérateur de données dépendant de la mémoire des puces, une optimisation matérielle qui prédit les adresses mémoire des données auxquelles le code en cours d’exécution est susceptible d’accéder dans un avenir proche. En chargeant le contenu dans le cache du processeur avant qu’il ne soit réellement nécessaire, le DMP, comme la fonctionnalité est abrégée, réduit la latence entre la mémoire principale et le processeur, un goulot d’étranglement courant dans l’informatique moderne. Les DMP sont un phénomène relativement nouveau que l’on retrouve uniquement dans les puces de la série M et dans la microarchitecture Intel Raptor Lake de 13e génération, bien que les anciennes formes de prélecture soient courantes depuis des années.
Les experts en sécurité savent depuis longtemps que les prélecture classiques ouvrent un canal secondaire que les processus malveillants peuvent sonder pour obtenir des clés secrètes à partir d’opérations cryptographiques. Cette vulnérabilité est le résultat du fait que les préchargeurs effectuent des prédictions basées sur des modèles d’accès précédents, ce qui peut créer des changements d’état que les attaquants peuvent exploiter pour divulguer des informations. En réponse, les ingénieurs en cryptographie ont conçu une programmation en temps constant, une approche qui garantit que toutes les opérations prennent le même temps, quels que soient leurs opérandes . Pour ce faire, il maintient le code exempt d’accès ou de structures mémoire dépendant d’un secret.
L’avancée de la nouvelle recherche est qu’elle expose un comportement jusqu’alors négligé des DMP dans le silicium Apple : ils confondent parfois le contenu de la mémoire, tel que les éléments clés, avec la valeur du pointeur utilisée pour charger d’autres données. En conséquence, le DMP lit souvent les données et tente de les traiter comme une adresse pour effectuer un accès à la mémoire. Ce « déréférencement » des « pointeurs » – c’est-à-dire la lecture de données et leur fuite via un canal secondaire – est une violation flagrante du paradigme du temps constant.
L’équipe de chercheurs est composée de :
Boru Chen, Université de l’Illinois Urbana-Champaign
Yingchen Wang, Université du Texas à Austin
Pradyumna Shome, Institut de technologie de Géorgie
Christopher W. Fletcher, Université de Californie, Berkeley
David Kohlbrenner, Université de Washington
Riccardo Paccagnella, Université Carnegie Mellon
Daniel Genkin, Institut de technologie de Géorgie
Dans un e-mail, ils ont expliqué :
Les préfetchers examinent généralement les adresses des données consultées (en ignorant les valeurs des données consultées) et tentent de deviner les futures adresses qui pourraient être utiles. Le DMP est différent en ce sens car en plus des adresses, il utilise également les valeurs des données afin de faire des prédictions (prédire les adresses auxquelles aller et pré-extraire). En particulier, si une valeur de données « ressemble » à un pointeur, elle sera traitée comme une « adresse » (alors qu’en fait ce n’est pas le cas !) et les données de cette « adresse » seront amenées dans le cache. L’arrivée de cette adresse dans le cache est visible, fuite via les canaux côté cache.
Notre attaque exploite ce fait. Nous ne pouvons pas divulguer directement les clés de chiffrement, mais ce que nous pouvons faire, c’est manipuler les données intermédiaires à l’intérieur de l’algorithme de chiffrement pour ressembler à un pointeur via une attaque d’entrée choisie. Le DMP voit alors que la valeur des données « ressemble » à une adresse et introduit les données de cette « adresse » dans le cache, ce qui entraîne la fuite de « l’adresse ». Nous ne nous soucions pas de la prélecture de la valeur des données, mais le fait que les données intermédiaires ressemblent à une adresse est visible via un canal de cache et suffit à révéler la clé secrète au fil du temps.
Dans le journal de jeudi, l’équipe l’a expliqué légèrement différemment :
Notre idée clé est que même si le DMP déréférence uniquement les pointeurs, un attaquant peut créer des entrées de programme de telle sorte que lorsque ces entrées se mélangent avec des secrets cryptographiques, l’état intermédiaire résultant peut être conçu pour ressembler à un pointeur si et seulement si le secret satisfait un attaquant. prédicat choisi. Par exemple, imaginez qu’un programme ait un secret s, prenne x comme entrée, calcule puis stocke y = s ⊕ x dans sa mémoire de programme. L’attaquant peut créer différents x et déduire des informations partielles (voire complètes) sur s en observant si le DMP est capable de déréférencer y. Nous utilisons d’abord cette observation pour briser les garanties d’une primitive standard d’échange à temps constant recommandée pour une utilisation dans les implémentations cryptographiques. Nous montrons ensuite comment briser des implémentations cryptographiques complètes conçues pour être sécurisées contre les attaques à entrée choisie.
Plus de détails sur GoFetch
L’attaque, que les chercheurs ont nommée GoFetch , utilise une application qui ne nécessite pas d’accès root, mais uniquement les mêmes privilèges utilisateur requis par la plupart des applications tierces installées sur un système macOS. Les puces de la série M sont divisées en ce que l’on appelle des clusters. Le M1, par exemple, dispose de deux clusters : l’un contenant quatre cœurs d’efficacité et l’autre quatre cœurs de performances. Tant que l’application GoFetch et l’application de cryptographie ciblée s’exécutent sur le même cluster de performances (même sur des cœurs distincts au sein de ce cluster), GoFetch peut extraire suffisamment de secrets pour divulguer une clé secrète.
L’attaque fonctionne à la fois contre les algorithmes de chiffrement classiques et contre une nouvelle génération de chiffrement renforcée pour résister aux attaques anticipées des ordinateurs quantiques. L’application GoFetch nécessite moins d’une heure pour extraire une clé RSA de 2 048 bits et un peu plus de deux heures pour extraire une clé Diffie-Hellman de 2 048 bits. L’attaque prend 54 minutes pour extraire le matériel nécessaire à l’assemblage d’une clé Kyber-512 et environ 10 heures pour une clé Dilithium-2, sans compter le temps hors ligne nécessaire au traitement des données brutes.
L’application GoFetch se connecte à l’application ciblée et lui transmet des entrées qu’elle signe ou décrypte. Ce faisant, il extrait la clé secrète de l’application qu’il utilise pour effectuer ces opérations cryptographiques. Ce mécanisme signifie que l’application ciblée n’a pas besoin d’effectuer seule aucune opération cryptographique pendant la période de collecte.
Les clés RSA et Diffie-Hellman ont été traitées sur des implémentations de Go et OpenSSL et Kyber et Dilithium de CRYSTALS-Kyber et CRYSTALS-Dilithium. Les quatre implémentations utilisent une programmation en temps constant, prouvant que les DMP du silicium Apple déjouent la défense largement déployée.
61086927-536b-489c-880a-529a7a6fde5a-image.png
ésultats expérimentaux de quatre PoC d’attaque cryptographique. Cela montre la moyenne de trois exécutions de chaque PoC. Le temps en ligne fait référence au temps requis pour un processus d’attaquant colocalisé, qui comprend (1) la génération d’ensembles d’expulsion standard ; (2) découverte d’un ensemble d’expulsions composées ; et (3) fuite de DMP. Le temps hors ligne est le temps de post-traitement (par exemple, réduction du réseau) nécessaire pour terminer la récupération de la clé secrète. Le temps nécessaire à la phase de collecte de signatures hors ligne de Dilithium-2 n’est pas inclus.
GoFetch n’est pas la première fois que des chercheurs identifient des menaces cachées dans les DMP Apple. L’optimisation a été documentée pour la première fois dans une recherche de 2022 qui a découvert un « DMP de poursuite de pointeur » jusqu’alors inconnu dans le M1 et dans la puce A14 Bionic d’Apple pour les iPhones. La recherche, menée par un autre groupe d’universitaires, a donné naissance à Augury , une attaque qui a identifié et exploité un canal secondaire de mémoire qui a divulgué des pointeurs. En fin de compte, Augury n’a pas pu mélanger les données et les adresses lorsque des pratiques en temps constant étaient utilisées, une lacune qui a pu donner l’impression que le DMP ne représentait pas une grande menace.
“GoFetch montre que le DMP est nettement plus agressif qu’on ne le pensait et pose donc un risque de sécurité beaucoup plus important”, ont écrit les auteurs de GoFetch sur leur site Internet. « Plus précisément, nous constatons que toute valeur chargée depuis la mémoire est susceptible d’être déréférencée (littéralement !). Cela nous permet de contourner de nombreuses limitations d’Augury et de démontrer des attaques de bout en bout sur du code réel en temps constant.
Des performances pénalisantes
Comme les autres canaux microarchitecturaux latéraux du processeur, celui qui rend GoFetch possible ne peut pas être corrigé dans le silicium. Au lieu de cela, la responsabilité d’atténuer les effets néfastes de la vulnérabilité incombe aux personnes qui développent le code pour le matériel Apple. Pour les développeurs de logiciels cryptographiques fonctionnant sur des processeurs M1 et M2, cela signifie qu’en plus de la programmation en temps constant, ils devront recourir à d’autres défenses, qui entraînent presque toutes des pénalités de performances importantes.
L’une des mesures d’atténuation les plus efficaces, connue sous le nom d’aveuglement du texte chiffré, en est un bon exemple. L’aveuglement fonctionne en ajoutant/supprimant des masques aux valeurs sensibles avant/après avoir été stockées/chargées depuis la mémoire. Cela rend effectivement aléatoire l’état interne de l’algorithme cryptographique, empêchant l’attaquant de le contrôler et neutralisant ainsi les attaques GoFetch. Malheureusement, selon les chercheurs, cette défense est à la fois spécifique à l’algorithme et souvent coûteuse, pouvant même doubler les ressources informatiques nécessaires dans certains cas, comme pour les échanges de clés Diffie-Hellman.
Une autre défense consiste à exécuter des processus cryptographiques sur les cœurs d’efficacité mentionnés précédemment, également appelés cœurs Icestorm, qui ne disposent pas de DMP. Une approche consiste à exécuter tout le code cryptographique sur ces cœurs. Cette défense n’est pas non plus idéale. Non seulement il est possible que des modifications inopinées ajoutent des fonctionnalités DMP aux cœurs d’efficacité, mais l’exécution de processus cryptographiques ici augmentera également probablement le temps nécessaire pour terminer les opérations dans une marge non négligeable. Les chercheurs évoquent plusieurs défenses ponctuelles, mais elles sont tout aussi problématiques.
Le DMP du M3, la dernière puce d’Apple, possède un élément spécial que les développeurs peuvent invoquer pour désactiver la fonctionnalité. Les chercheurs ne savent pas encore quel type de pénalité se produira lorsque cette optimisation des performances sera désactivée. (Les chercheurs ont noté que le DMP trouvé dans les processeurs Intel Raptor Lake ne divulgue pas les mêmes types de secrets cryptographiques. De plus, la définition d’un bit DOIT spécial désactive également efficacement le DMP.)
Les lecteurs doivent se rappeler que les sanctions qui en résulteront ne seront ressenties que lorsque le logiciel concerné effectue des opérations cryptographiques spécifiques. Pour les navigateurs et de nombreux autres types d’applications, le coût en termes de performances peut ne pas être perceptible.
“À plus long terme, nous pensons que la bonne solution consiste à élargir le contrat matériel-logiciel pour tenir compte du DMP”, ont écrit les chercheurs. « Au minimum, le matériel doit offrir au logiciel un moyen de désactiver sélectivement le DMP lors de l’exécution d’applications critiques pour la sécurité. Cela constitue déjà un précédent dans l’industrie. d’Intel Par exemple, les extensions DOIT mentionnent spécifiquement la désactivation de leur DMP via une extension ISA. À plus long terme, on souhaiterait idéalement un contrôle plus fin, par exemple pour contraindre le DMP à effectuer une prélecture uniquement à partir de tampons spécifiques ou de régions de mémoire non sensibles désignées.
Les représentants d’Apple ont refusé de commenter officiellement la recherche GoFetch.
Les utilisateurs finaux concernés doivent rechercher les mises à jour d’atténuation GoFetch disponibles pour les logiciels macOS qui implémentent l’un des quatre protocoles de chiffrement connus pour être vulnérables. Par prudence, il est probablement également sage de supposer, du moins pour l’instant, que d’autres protocoles cryptographiques sont probablement également sensibles.
“Malheureusement, pour évaluer si une implémentation est vulnérable, une cryptanalyse et une inspection du code sont nécessaires pour comprendre quand et comment les valeurs intermédiaires peuvent ressembler à des pointeurs de manière à divulguer des secrets”, ont conseillé les chercheurs. “Ce processus est manuel et lent et n’exclut pas d’autres approches d’attaque.”
Source: https://arstechnica.com/security/2024/03/hackers-can-extract-secret-encryption-keys-from-apples-mac-chips/
