Une faille matérielle touche les puces M1, M2 et M3, Réactions à la publication du 22/03/2024

[Lionel]

Des chercheurs en sécurité ont découvert une faille dans les puces Apple Silicon.

La faille est liée à des optimisations permettant d'améliorer les performances mémoire en réalisant des prédictions. Pour faire simple, la puce va tenter de prédire quelles données mémoire seront demandées par le code exécuté en cours et les charger pour les mettre à sa disposition.
En cas de succès, on gagne du temps, en cas d'échec on en perd seulement un tout petit peu.
Le système n'est cependant pas parfait et il s'avère que celui utilisé par Apple permet via une attaque de récupérer les clés de chiffrement utilisées par la puce pour protéger les contenus et ainsi les rendre lisibles
Une preuve de concept fonctionnelle existe déjà.

Mauvaise nouvelle, tous les systèmes dont nous vous parlons sont codés en dur dans les puces. Il n'est donc pas possible de les corriger sauf à modifier de manière matérielle ces dernières.
On peut bien entendu imaginer une atténuation logicielle mais elle pèserait considérablement sur les performances de ces processeurs. Intel a déjà connu ça par le passé.

Apple s'en remettra. Il reste seulement à trouver le moyen de régler le problème et que les machines dans le futur ne soient pas concernées. Pour les actuelles c'est une autre histoire.

Lien vers le billet original

[Laszlo Lebrun]

... Intel a déjà connu ça par le passé.

C'est bien ce que je me suis dit en lisant le début de l'article: Il y a comme un déja vu.
"Think different" but make the same mistakes?

[g4hd]

Des chercheurs en sécurité ont découvert une faille dans les puces Apple Silicon.

… bah, que cherchent-ils à nous vendre ?

[JayTouCon]

Des chercheurs en sécurité ont découvert une faille dans les puces Apple Silicon.

… bah, que cherchent-ils à nous vendre ?

vu qu'il n'existe pas de patchs possible, rien.

[Paul Emploi]

C'est une faille qui a été identifiée depuis longtemps sur le M1, considérée comme théorique mais extrêmement difficile si pas impossible à exploiter.
Cet exploit est vraiment fabuleux mais il a encore des limites énormes dans le monde réel.

D'abord l'attaque doit se faire depuis le même cluster de cœurs qu'utilise la cible.
Ensuite il faut que ça soit un cluster de cœurs de type Performance et non Économie, ces derniers étant privé du mécanisme de prefetching fautif.
Ensuite ça nécessite du temps avec 3 processus tournant 100% du temps, la cible réutilisant toujours la même clé privée, sans autre processus venant brouiller les cartes au niveau du cache L2 sur les autres cœurs du cluster, prendre du temps d'un des 3 cœurs utilisés, ni qu'un de ces processus ne change de cluster.

Des conditions extrêmement complexes à obtenir hors d'un laboratoire, en attendant de possibles progrès en matière d'exploitation.
Apple pourrait désactiver le prefetching erroné sur le processus faisant les calculs, même uniquement pendant l'exécution des primitives cryptographiques, résolvant alors le problème, ou alternativement modifier ses implémentations pour que le prefetcher actif fasse toujours tous les accès mémoire.

Pour résumer: bravo, mais heureusement ça n'a pas d'impact réel.

Il faut noter qu'il ne faut pas coder cela dans son logiciel ni utiliser de biblio bizarres ou même connues, mais faire confiance au système pour tout ce qui concerne la cryptographie dont CryptoKit chez Apple, les IA n'aidant vraiment pas puisque ne comprenant rien de ce qu'elles écrivent et répétant les erreurs du passé.

ChatGPT 4 me propose ce code, pour une comparaison crypographiquement sûre de chaînes de caractères, bien que m'ayant indiqué que le temps devait être constant à même longueur de chaînes.

Code

// Returns 1 if the strings are equal, 0 otherwise.
int constant_time_compare(const char *a, const char *b, size_t len) {
    const unsigned char *ua = (const unsigned char *)a;
    const unsigned char *ub = (const unsigned char *)b;

    unsigned char result = 0;
    for (size_t i = 0; i < len; i++) {
        result |= ua[i] ^ ub[i];
    }

    return result == 0;
}

Cela ne repose que sur les limitations actuelles des compilateurs, en l'absence de PRAGMA désactivant les optimisations, et d'ailleurs si on demande à ChatGPT4 d'optimiser lui-même ce code, il insère de lui-même un beau "if (result != 0) { return 0; }" dans la boucle, CQFD!

Il y a évidemment une autre faille dans ce code, faille qui date d'une soixangtaine d'année...
Qui la trouvera?

[ChaG]

Il y a évidemment une autre faille dans ce code, faille qui date d'une soixangtaine d'année...
Qui la trouvera?

Pas de contrôle de la longueur des chaînes par rapport à len ?

[Hebus]

Y a plein de manière de rendre ce code plus secure

Mais la plus évidente est que l’on déréférence les pointeurs de chaîne sans vérifier qu’ils ne sont pas nuls

Intrinsèquement y a rien de secure la dedans car qui dit que l’appelant respecte le contrat que les deux chaînes sont de même longueur ? Quid de la vérification de fin des chaînes…


Les algo d’imbecilité artificielles auto régressive LLM n’ont rien d’intelligents, et ils divergent exponentiellement en fonction de la longueur de la chaîne produite (voir la vidéo postée de Yann LeCun)

Ça impressionne juste parce que on entraine ces machines avec des milliards de données numériques qui ne sont pas plus fiables que cela

Ce message a été modifié par Hebus - 23 Mar 2024, 01:46.

[amike]

...
Cet exploit est vraiment fabuleux mais il a encore des limites énormes dans le monde réel.
...
Pour résumer: bravo, mais heureusement ça n'a pas d'impact réel.

C'est pourquoi cette phrase m'a tout de suite gênée :

Une preuve de concept fonctionnelle existe déjà.

Fonctionnel ne veut pas dire "qui marche, réalisé, fonctionne", mais "adapté pour le besoin qu'on veut en faire" ; ici, pirater, attaquer, ...

Une voiture fonctionnelle ne veut pas dire qu'elle démarre et qu'elle roule selon les specs, mais qu'elle est disponible et conforme aux besoins de ses utilisateurs. Alors, certes, la voiture doit d'abord être opérationnelle, mais évitons de confondre les étapes.

[zarck]

C'est rien toutes les machines vendues seront échangées contre une version M4 corrigeant ce défaut...

[g4hd]

C'est rien toutes les machines vendues seront échangées contre une version M4 corrigeant ce défaut...

Et vive l'obsolescence programmée

[Benzebut]

Mauvaise nouvelle, tous les systèmes dont nous vous parlons sont codés en dur dans les puces. Il n'est donc pas possible de les corriger sauf à modifier de manière matérielle ces dernières.
On peut bien entendu imaginer une atténuation logicielle mais elle pèserait considérablement sur les performances de ces processeurs. Intel a déjà connu ça par le passé.

Pas évident qu'il s'agisse d'une "faille", mais simplement des limites de l'architecture des microprocesseurs actuels.
Tous les fabricants font des optimisations permettant d'améliorer les performances mémoire en réalisant des prédictions pour optimiser l'usage des multi-cœurs qui composent les puces. Donc il y a effectivement un processus de prédiction des processus et la répartition du code exécuté pour raccourcir les temps d'allocation. Le problème étant que le code "reste" en cache et que la fréquence d'actualisation est connue, il devient alors parfaitement possible de l'identifier et donc de le lire. Il serait possible de changer les allocations mémoire et fréquences, voire de les chiffrer, mais celles-ci feraient perdre en temps de traitement, atténuant l'intérêt du multi-cœurs. Puis elles seraient alors caractérisables à leur tour, donc il en faudrait de nouveau, pour refaire un cycle...

Bref, rien de nouveau, ce fut effectivement le faille Spectre chez Intel, ou du protocole WEP/WPA en Wifi, avec les mêmes contraintes pour l'exploiter. Ce qui remet au gout du jour le principe de Vauban où toute citadelle est prenable, ce n'est qu'une question de temps et de ressources...

EDIT: correction de "mutli-processeurs" par "multi-coeurs", comme indiqué dans les messages suivants.

Ce message a été modifié par Benzebut - 24 Mar 2024, 20:10.

[Paul Emploi]

Rien de tout cela!

• Optimiser l'usage des "multi-processeurs"? Non. Ça optimise les performances du cœur.
• Prédiction de processus? Non.
• Prédiction de la répartition du code exécuté? Non.
• Raccourcir les temps d'allocation? Non. Pas d'allocation là-dedans.
• Problème étant que le code "reste" en cache? Non. Le code reste en cache L1 des deux cotés et on s'en fout d'aillleurs.
• La fréquence d'actualisation est connue? Non. De quelle fréquence parles-tu, puisque le code reste en cache L1.
• Il devient alors parfaitement possible de l'identifier et donc de le lire [le code]? Non. Le code n'est pas lu.
• Il serait possible de changer les allocations mémoire et fréquences? Non. Pas d'allocation.
• Il serait possible [...] de les chiffrer [les allocations memoire et fréquences]? Non. Aucun rapport.
• Atténuant l'intérêt du multiprocesseur? Non. Aucun rapport.

il s'agit d'une attaque de side-channel sur le cache L2 partagé dans chaque cluster de cœurs, au travers du DMP des cœurs de type Performance qui précharge des données dans ce cache lorsqu'un registre utilisé comme pointeur semble pointer sur dse pointeurs, et d'une validation de chargement ou non via les timing d'accès permettant d'en déduire les traitements effectués ou non, timing précis lus grâce à la mémoire partagée avec le 3ème process pour bypasser tout jitter extérieur (des protections au niveau de macOS).
Voir sur GoFetch.fail.

[apocrypha]

Tout de suite, quand vous expliquez c'est tout de suite plus simple

[Benzebut]

Rien de tout cela!

Tout cela, mais avec le mauvais terme. Il s'agit bien sur de "multi-cœurs" et non pas de "multi-processeurs" dans le précédent message. Je vais apporter la motion pour clarifier, car bien évidemment, la fonction Data Memory-dependent Prefetcher (ou DMP) ne peut que concerner les cœurs des processeurs.

il s'agit d'une attaque de side-channel sur le cache L2 partagé dans chaque cluster de cœurs, au travers du DMP des cœurs de type Performance qui précharge des données dans ce cache lorsqu'un registre utilisé comme pointeur semble pointer sur dse pointeurs, et d'une validation de chargement ou non via les timing d'accès permettant d'en déduire les traitements effectués ou non, timing précis lus grâce à la mémoire partagée avec le 3ème process pour bypasser tout jitter extérieur (des protections au niveau de macOS).
Voir sur GoFetch.fail.

Ce qui fut le cas de Meltdown et Spectre sur Intel, s'appuyant sur les technologies de prédiction pour identifier des données confidentielles et qui entraînaient la fuite de « l'adresse ». Encore une fois, pas évident qu'il s'agisse d'une "faille", mais plus des limites de l'architecture des microprocesseurs actuels avec trop de cœurs à gérer...

[Paul Emploi]

il s'agit d'une attaque de side-channel sur le cache L2 partagé dans chaque cluster de cœurs, au travers du DMP des cœurs de type Performance qui précharge des données dans ce cache lorsqu'un registre utilisé comme pointeur semble pointer sur dse pointeurs, et d'une validation de chargement ou non via les timing d'accès permettant d'en déduire les traitements effectués ou non, timing précis lus grâce à la mémoire partagée avec le 3ème process pour bypasser tout jitter extérieur (des protections au niveau de macOS).
Voir sur GoFetch.fail.

Ce qui fut le cas de Meltdown et Spectre sur Intel, s'appuyant sur les technologies de prédiction pour identifier des données confidentielles et qui entraînaient la fuite de « l'adresse ». Encore une fois, pas évident qu'il s'agisse d'une "faille", mais plus des limites de l'architecture des microprocesseurs actuels avec trop de cœurs à gérer...

Rien à voir avec les microprocesseurs actuels car les attaques de side-channel sur les caches sont des dérivés des attaques sur les fautes de page des années 60 et suivantes. Le principe est le même, on a la trace d'un accès mémoire fait ou pas qui modifie l'état interne et dont on peut mesurer l'effet.

Et ça n'est pas lié au nombre de cœurs, cette attaque fonctionnerait parfaitement en mono-cœur si macOS n'introduisait pas un jitter important sur les mesures de temps, une protection servant à rendre ce type d'attaque très difficile car extrêmement lent. Enfin, encore plus lent.
D'où le troisième processus qui sert de base de temps au travers d'adresses mémoires partagées et en fait via le cache L2 puisque sur le même cluster.

Le DMP n'a définitivement aucun rapport avec le fait qu'une CPU soit multicœur, il ne sert qu'à ramener des données au plus près en anticipant leur potentiel accès.

[Benzebut]

Rien à voir avec les microprocesseurs actuels car les attaques de side-channel sur les caches sont des dérivés des attaques sur les fautes de page des années 60 et suivantes. Le principe est le même, on a la trace d'un accès mémoire fait ou pas qui modifie l'état interne et dont on peut mesurer l'effet.

Et ça n'est pas lié au nombre de cœurs, cette attaque fonctionnerait parfaitement en mono-cœur si macOS n'introduisait pas un jitter important sur les mesures de temps, une protection servant à rendre ce type d'attaque très difficile car extrêmement lent. Enfin, encore plus lent.
D'où le troisième processus qui sert de base de temps au travers d'adresses mémoires partagées et en fait via le cache L2 puisque sur le même cluster.

Le DMP n'a définitivement aucun rapport avec le fait qu'une CPU soit multicœur, il ne sert qu'à ramener des données au plus près en anticipant leur potentiel accès.

L'architecture des processeurs actuels amplifie les risques d'attaques sur les caches, simplement par le nombre actif et les accès faits. Idem pour le DMP, l'usage du multi-cœur demande de ramener et anticiper au plus près, pour optimiser les accès et éviter les goulots d'étranglement avec les composants. D'où le non de l'exploit : "Go fetch" ou "Va chercher"...

Ainsi, du moment que la donnée peut être localisée et en parallèle identifier quand elle sera utilisée, il y a un risque de corruption. Toute forme d'architecture retenue. Toute génération de microprocesseurs connue.

Bref, l'exploit identifie les limites de l'architecture des microprocesseurs actuels, même si cela reste un bel exploit qui devrait permettre de faire de nouvelles optimisation des architectures. Jusqu'à la prochaine limite à aller chercher...

[Paul Emploi]

L'architecture des processeurs actuels amplifie les risques d'attaques sur les caches, simplement par le nombre actif et les accès faits.

Toujours faux.

Les caches en lecture ont toujours un side-channel temporel, que ça soit un cache-disque, le cache d'un navigateur, ou les niveaux de cache dans une CPU ou un sous-système mémoire. Même ma bibliothèque a ce problème, puisque le livre que je lis actuellement est posé sur mon bureau pour que j'y accède plus rapidement...
Pas besoin de grands mots sur les "multiprocesseurs" ou "multi-cœurs" qui n'ont rien à voir, de parler de "parallélisme" qui n'a aucun sens pour GoFetch, ni même de "corruption".

Un cache en lecture génère forcément des différences de temps d'accès, c'est même son but premier, permettre d'accéder plus rapidement aux données dont on a besoin, et dans ce cas d'accéder plus vite aux données dont on pourrait avoir besoin (prefetching). Le side-channel est inévitable, il correspond au but des caches.
Comme poser des jeux vidéos ou des jeux traditionnels sur sa table de salon avant de recevoir des amis ou de la famille pour une soirée, du prefetching, pour gagner du temps.
Ou une bouteille ou deux.

Si on connait mes amis et ma famille, quelqu'un passant chez moi saurait qui je vais probablement recevoir à cause de ce prefetching, cette anticipation.
Pas besoin de vocabulaire technique non-maîtrisé, de grands mots, ni d'accuser "l'architecture des processeurs actuels", factuellement ce type d'attaque informatique existe depuis qu'on utilise des caches, et même avant puisqu'elles ne sont pas liées à l'informatique, c'est juste essayer d'anticiper qui est mesurable, et qui doit l'être...

Cette attaque est de toute façon très théorique et ne pose aucun problème en pratique, le code attaqué étant spécifiquement conçu pour permettre ce type d'attaque, qui reste un bel exploit, mais ne correspondant à rien de réel. Comme toujours, utilisez CryptoKit!

[Benzebut]

Si on connait mes amis et ma famille, quelqu'un passant chez moi saurait qui je vais probablement recevoir à cause de ce prefetching, cette anticipation.
Pas besoin de vocabulaire technique non-maîtrisé, de grands mots, ni d'accuser "l'architecture des processeurs actuels", factuellement ce type d'attaque informatique existe depuis qu'on utilise des caches, et même avant puisqu'elles ne sont pas liées à l'informatique, c'est juste essayer d'anticiper qui est mesurable, et qui doit l'être...

Et rebelote, même si cette discussion s'éloigne de plus en plus de la raison initiale sur cette "faille"...

Pour reprendre l'exemple cité sans grands mots, si votre bibliothèque n'avait qu'un seul livre dans ses étagères, il serait aisé d'y accéder pour retrouver le chapitre commencé. Si plusieurs volumes sont disponibles et que vous ayez rangé les livres commencés dans ces mêmes étagères, il faudrait plus de repères pour les trouver. La quantité de données amplifie donc la démarche de recherche par multiplication des repères (ce qui est une Lapalissade).
Ensuite, si vous avez des ouvrages prédisposés devant votre bibliothèque, cela indique à un tiers vos lectures du moment. Avec le même phénomène, un seul ouvrage permet d'identifier une histoire en cours de lecture. Plusieurs ouvrages le genre, l'auteur, la série, le héro et consorts. La multiplicité de la sélection permet de prédire finement la lecture choisie (ce qui est un profilage).

Bref, comme indiqué précédemment, cet exploit identifie les limites de l'architecture des microprocesseurs actuels, comme cela fut le cas avec plein de contraintes en informatique avant, voire des techniques d'une manière générale. Ce qui remet bien au gout du jour le principe de Vauban où toute citadelle est prenable, ce n'est qu'une question de temps et de ressources (avec ou sans CryptoKit) ...