Puce Apple Silicon

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

Alors que revoilà le canal auxiliaire

Avatar de l'auteur
Vincent Hermann

Publié dans

Sécurité

26/03/2024 8 minutes
9

Puce Apple Silicon

Apple a un nouveau problème sur les bras : ses puces Apple Silicon, qui équipent ses Mac, ont une faille. Elle peut être exploitée pour récupérer des clés cryptographiques. Pourtant, il s’agit du même type de vulnérabilité que l’on observe dans les processeurs depuis des années.

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.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Le fonctionnement du DMP

Le fonctionnement de la faille

Ce ne sera pas facile à corriger

Apple « remercie les chercheurs »… et maintenant ?

Les chercheurs militent pour un contrôle plus fin

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (9)


Ça a l'air exactement pareil que Spectre/Meltdown. Comment est-il possible qu'ils n'y aient pas pensé avant chez Apple ?
Parce-que le FBI / NSA à demandé de ne pas y penser? 🤫
Donc, Apple, qui parle de vie privée H24, répond :

" cette recherche fait progresser notre compréhension de ce type de menaces "

D'accord
Je me pose la question, mais est-ce que les processeurs ARM ont du microcode patchable ? En effet, il me semble qu'Intel et AMD ont réussi à combler les failles de Meltdown et Spectre via un patch du microcode de leur processeur. Cependant, je n'ai pas l'impression que les processeurs ARM possède une telle capacité. Si c'est le cas (pas de microcode patchable), alors Apple va bien en chier pour corriger la faille. Plus encore, il y a peut-être des risques de voir ça du coté des autres puces ARM.
Sur ton premier point, non, il n'y a pas de microcode dans les processeurs ARM.

Sur ton dernier point (les autres puces ARM), elles ne semblent pas affectées si l'on en croit ce papier de chez eux :
Arm’s implementations of memory-dependent prefetchers prevent both exploitative control and predictive leakage attacks, as predictions are only accessible in the context that was generated in.


Le DMP de la puce Apple a l'air d'être de conception Apple à en lire le papier qui parle de cette faille : ils ont fait du reverse engineering en s'aidant d'un brevet sur le sujet déposé par Apple. Donc les puces ARM standards n'utilisent pas ce DMP.

fred42

Sur ton premier point, non, il n'y a pas de microcode dans les processeurs ARM.

Sur ton dernier point (les autres puces ARM), elles ne semblent pas affectées si l'on en croit ce papier de chez eux :
Arm’s implementations of memory-dependent prefetchers prevent both exploitative control and predictive leakage attacks, as predictions are only accessible in the context that was generated in.


Le DMP de la puce Apple a l'air d'être de conception Apple à en lire le papier qui parle de cette faille : ils ont fait du reverse engineering en s'aidant d'un brevet sur le sujet déposé par Apple. Donc les puces ARM standards n'utilisent pas ce DMP.
Merci pour ta réponse. Je lirai l'article de ZNet plus tard, il semble intéressant.

Bon, ben ça sent assez mauvais pour ces puces du coup.
Est-ce que Apple va bien en chier pour corriger la faille ? Bien sûr. Si la solution était simple, elle serait déjà appliquée.

alex.d.

Est-ce que Apple va bien en chier pour corriger la faille ? Bien sûr. Si la solution était simple, elle serait déjà appliquée.
Ils auraient du l’appeler puce L, histoire de rester inviolable.
Il faut corriger au niveau du système et des applications critiques, dans le code et dans la compilation, comme sur linux sur les machines qui n'ont pas de patch via microcode.