GoFetch : les puces Apple Silicon laissent fuiter des clés de chiffrement

Des chercheurs ont annoncé avoir trouvé une faille de sécurité dans les processeurs M1, M2 et M3 d’Apple (les puces Ax des iPhone ne sont pas concernées). Baptisée GoFetch, elle est liée aux mécanismes de prédiction, que l’on retrouve dans les processeurs depuis longtemps, bien qu'ici à un degré plus poussé.

Les puces Apple Silicon vont cependant plus loin et intègrent – comme chez Intel depuis la 13ᵉ génération Core – un mécanisme élargissant le concept de prédiction. C’est malheureusement là que réside la brèche, le Data Memory-dependent Prefetcher (DMP) devenant un canal auxiliaire.

Le fonctionnement du DMP

Ce mécanisme n’existe aujourd’hui que dans quelques générations récentes de puces. Il étend les capacités de la prédiction de branche. Celle-ci consiste, pour le processeur, à « deviner » les prochaines étapes d’un calcul via des algorithmes.

Les avantages sont connus depuis longtemps. On en parlait déjà beaucoup à l’époque du Pentium 4 et sa grande longueur de pipeline. Quand le processeur parvient en effet à deviner correctement, l’application n’a plus qu’à récupérer les données dont elle a besoin dans la mémoire cache, extrêmement rapide. Le processeur peut alors travailler sur d’autres opérations en parallèle, avec un gain de performances à la clé. Dans le cas contraire, le pipeline doit être vidé, entrainant une légère chute des performances, puisqu’il faut recommencer les calculs.

Ce mécanisme a été largement amélioré dans le temps et la prédiction n’a fait que se renforcer. Le DMP va un cran plus loin cependant. Avant lui, la prédiction ne fonctionnait qu’avec des adresses en mémoire, pour pointer les données dont les applications pouvaient avoir besoin. Le Data Memory-dependent Prefetcher, lui, analyse ces mêmes données à la recherche de pointeurs, autrement dit d’adresses en mémoire. S’il en trouve, il précharge les données en mémoire cache du processeur. Son travail est, dans les grandes lignes, de deviner la prochaine adresse qui sera chargée par une instruction.

Le fonctionnement de la faille

Vous l’avez peut-être vu venir : l’efficacité du mécanisme se base entièrement sur la capacité du DMP à reconnaître un pointeur dans un lot de données. Ou, plus exactement, ce qu’il pense être un pointeur. C’est ce qu’exploite GoFetch : déguiser des informations en pointeur pour déclencher le préchargement en mémoire cache.

Dans le rapport des chercheurs ayant fait cette découverte, on peut lire ainsi qu’ils arrivent à faire précharger des données qui ne devraient pas y être. En l’occurrence, des clés cryptographiques qu’ils arrivent à récupérer, même si l’opération est assez lente, sans pour autant que ce soit une vraie barrière.

Il faut en effet un peu moins d’une heure pour récupérer une clé RSA-2048. Il ne semble pas y avoir de limitation sur les solutions de chiffrement. Seul le temps varie dans l’obtention de la clé. Une clé Diffie-Hellman de 2048 bits nécessite deux heures environ par exemple, 54 minutes pour une clé Kyber-512, ou encore 10 heures pour une clé Dilithium-2.

Cette récupération peut être réalisée depuis une application spécialement conçue pour exploiter la faille. Point très négatif pour la sécurité, cette application n’a pas besoin de droits particuliers, car elle s’exécute avec ceux de l’utilisateur actif. Pour rappel, sur macOS, les comptes n’ont par défaut pas les droits administrateur. Le système réclame des autorisations pour toute opération significative ou liée au système, à la sécurité ou à la vie privée.

Pour parvenir à ce résultat, les chercheurs ont alimenté en données les applications visées, pour provoquer des opérations de chiffrement et déchiffrement. Avec des données contenant ce qui s’apparentait à des pointeurs, des données qui n’auraient jamais dû y être se sont retrouvées en mémoire cache. Les chercheurs examinaient pendant ce temps cette dernière, récupérant petit à petit ce dont ils avaient besoin pour reconstituer la clé.

Ce ne sera pas facile à corriger

L’exploitation de la faille ne fonctionne cependant pas dans tous les cas. Il y a en effet un prérequis : le code doit être exécuté sur le même groupe (cluster) de cœurs au sein de la puce que celui de l’application attaquée. Une précision importante, les puces Apple Silicon possédant des cœurs dédiés aux performances et d’autres plus économes en énergie. Seuls les cœurs performants se servent du DMP.

Mais même sans cette limitation, on est dans un nouvel exemple d’attaque par canal auxiliaire. Au cours de la dernière décennie, on en a découvert plusieurs, les plus connues étant sans doute Meltdown et Spectre, d’abord chez Intel et finalement un peu partout. Depuis, ce type de vulnérabilité a nettement attiré l’attention, aussi bien des chercheurs que des pirates.

On sait donc que ces failles sont très complexes à corriger, car elles relèvent de l’architecture matérielle. On ne peut pas la colmater avec un simple correctif logiciel. Les solutions ne sont pas légions :

• • Effectuer les calculs cryptographiques sur les cœurs à basse consommation

• • Modifier les applications elles-mêmes pour prendre en compte ce risque

• • Désactiver le DMP pour une application spécifique

Seulement voilà, toutes ces solutions ont des inconvénients. La première entraine bien sûr une chute des performances, les cœurs basse consommation étant moins puissants. Même chose pour la deuxième selon les chercheurs, qui évoquent une chute potentiellement grande. Quant à la dernière, elle est réservée aux puces M3 et n’est guère pratique, d’autant plus qu’elle suppose que les utilisateurs connaissent ce risque et veuillent s’y atteler.

Apple « remercie les chercheurs »… et maintenant ?

Selon les chercheurs, Apple a été informé de la faille le 5 décembre 2023, soit plus de trois mois avant de la rendre publique. La société ne semble pas avoir réagi pour le moment. Ils indiquent aussi qu’ils proposeront « bientôt » un prototype d’application pour exploiter cette vulnérabilité.

Apple a simplement fait une non-réponse à The Register : « Nous souhaitons remercier les chercheurs pour leur collaboration alors que cette recherche fait progresser notre compréhension de ce type de menaces ». L’entreprise renvoie vers sa documentation technique, avec des solutions déjà mises en avant par les chercheurs. Elle confirme au passage les pertes de performances.

Les chercheurs militent pour un contrôle plus fin

« Nous pensons que la bonne solution consiste à élargir le contrat matériel-logiciel pour tenir compte du DMP. Au minimum, le matériel devrait exposer au logiciel un moyen de désactiver sélectivement le DMP lors de l'exécution d'applications critiques pour la sécurité. Il existe déjà un précédent dans l'industrie. Par exemple, les extensions DOIT d'Intel mentionnent spécifiquement la désactivation de leur DMP par le biais d'une extension ISA. À plus long terme, l'idéal serait de disposer d'un contrôle plus fin, par exemple pour contraindre le DMP à n'effectuer le préchargement qu'à partir de tampons spécifiques ou de régions de mémoire non sensibles désignées », expliquent les chercheurs.

Soulignons enfin que le DMP avait déjà fait parler de lui en 2022. Comme le rappelle Ars Technica, une recherche avait été menée sur les puces M1 des Mac et A14 Bionic des iPhone et avait abouti à une attaque baptisée Augury. Un canal auxiliaire était ouvert dans la mémoire, dans laquelle des chercheurs arrivaient à récupérer des informations. Elle n’atteignait cependant pas l’efficacité de GoFetch.