Connexion
Abonnez-vous

FLOP et SLAP : les puces Apple vulnérables à deux nouvelles attaques

Les puces Apple... pour l'instant

FLOP et SLAP : les puces Apple vulnérables à deux nouvelles attaques

Des chercheurs ont découvert deux failles de sécurité dans les puces Apple. Exploitées, elles peuvent laisser échapper des informations transitant dans certains navigateurs, dont celles sur les cartes bancaires et autres données sensibles. Ces vulnérabilités peuvent permettre des attaques par canal auxiliaire et ne sont pas simples à corriger.

Le 29 janvier à 16h00

Les attaques par canal auxiliaire consistent à détourner un mécanisme spécifique pour accéder à des informations qui, sans cette méthode, seraient inaccessibles. C’est le cas avec les deux failles découvertes par des chercheurs, qui les ont nommées FLOP et SLAP.

Dans les deux cas, il s’agit d’un détournement de l’exécution spéculative. Comme nous l’indiquions en novembre dans un article consacré aux conséquences lointaines de la faille Spectre, l’exécution spéculative est au cœur de tous les processeurs depuis longtemps. Cette fonction permet, via une approche statistique, de définir à l’avance l’ordre des instructions et donc les calculs à faire au sein du CPU. Si la spéculation est juste, il y a un gain de temps notable. Si elle est erronée, la branche de calcul est abandonnée et l’opération doit recommencer.

Dans l’ensemble, l’exécution spéculative permet des gains significatifs de performances. Malheureusement, ce fonctionnement s’accompagne de multiples failles, dont FLOP et SLAP sont les dernières représentantes.

Prédictions malveillantes

FLOP est présentée comme la plus grave des deux failles. Signifiant « False Load Output Predictions », elle permet l’exploitation d’une forme d’exécution spéculative que l’on trouve dans le prédicteur de valeur de charge (LVP). Ce composant est chargé de prédire le contenu de la mémoire alors qu’il n’est pas encore disponible.

Or, un acteur malveillant peut inciter le LVP à transmettre des valeurs à partir de données spécifiquement malformées. Le pirate peut ainsi récupérer ces valeurs, alors qu’elles sont en temps normal hors d’atteinte. Si la faille est exploitée, elle peut permettre la récupération d’informations sensibles dans un navigateur, comme le contenu de la boite de réception de Proton Mail, l’historique de géolocalisation dans Google Maps ou encore les évènements dans le Calendrier d’Apple.

L’autre faille, SLAP, s’en prend à un autre mécanisme de prédiction. SLAP (Speculation Attacks via Load Adress Prediction) vise ainsi le prédicteur d’adresse de chargement (LAP). Ce composant sert à indiquer au processeur où les données d’instructions sont stockées en mémoire pour en permettre l’accès. Si la faille est exploitée, elle peut forcer le LAP à prédire des adresses erronées, en envoyant une adresse plus ancienne à une instruction plus jeune.

SLAP peut être exploitée dans Safari. Il faut pour cela que l’onglet du site dont on veut obtenir les données – comme Gmail – soit ouvert en même temps qu’un onglet ayant chargé un site malveillant. Ce dernier peut alors lire des chaines JavaScript sensibles, autorisant la récupération du contenu des e-mails par exemple.

Zoom sur FLOP

La faille FLOP a été découverte lors de travaux des chercheurs (trois du Georgia Institute of Technology, un de l’université de la Ruhr à Bochum) sur le LVP introduit par les puces A17 et M3. L’équipe s’est notamment attelée à une opération de rétro-ingénierie sur le mécanisme, pour mieux comprendre son fonctionnement.

Ils sont alors rendus compte d’un point spécifique. Pour la même instruction de chargement, le LVP renvoie ainsi la même valeur plusieurs fois. Une idée leur vient : peut-on prédire cette valeur à la prochaine exécution de l’instruction, « même si la mémoire à laquelle le chargement a accédé contient désormais une valeur complètement différente » ?

Ils découvrent non seulement que c’est bien le cas, mais également qu’il est possible d’abuser le LVP pour faire calculer au CPU des instructions sur la base de données erronées. Plus précisément, il devient possible de lancer le CPU sur des calculs arbitraires en provoquant une erreur dans le LVP. On peut alors contourner des mesures de protection, dont celles mises en place dans les navigateurs pour bloquer les échanges entre deux onglets non liés par un même domaine.

De 5 à 10 minutes nécessaires

Pour fonctionner, les chercheurs estiment qu’il faut en moyenne entre 5 et 10 minutes. Les deux failles ont en commun de nécessiter que le site visé soit ouvert dans un onglet en même temps qu’un autre, avec le site malveillant. La suite dépend du navigateur.

Sur Safari, le site malveillant émet du code JavaScript pour déterminer les calculs nécessaires. Ces derniers déduits, une attaque peut lancer du code normalement spécifique à une structure de données contre une autre, permettant alors la lecture d’adresses 64 bits déterminées. La faille permet de charger les deux sites dans le même espace mémoire. En s’appuyant sur certaines spécificités du moteur WebKit, les chercheurs sont arrivés à réduire suffisamment l’entropie pour deviner, par force brute, des espaces de recherche 16 bits et ainsi accéder aux données qui les intéressaient.

Sur Chrome, la méthode change complètement. FLOP est utilisée pour cibler les structures de données internes dont Chrome se sert pour appeler les fonctions WebAssembly. Normalement, ces structures vérifient la signature de chaque fonction. FLOP permet de court-circuiter ce mécanisme, les fonctions pouvant alors s’exécuter avec de faux arguments.

Qui est concerné ?

Si FLOP est présentée comme plus grave que SLAP, c’est notamment parce qu’elle permet de lire n’importe quelle adresse mémoire comprise dans l’espace adressé par un processus de navigation. En outre, FLOP peut être exploitée dans Chrome et Safari, augmentant largement le nombre de cibles potentielles.

En revanche, FLOP se trouve sur des versions assez récentes des puces Apple : à partir de l’A17 pour les iPhone et iPad, du M3 pour les Mac, ces générations ayant introduit le LVP. SLAP, de son côté, est présente à partir des puces A15 et M2, concernant donc un plus grand nombre d’appareils.

Si vous avez un portable Mac d’au moins 2022, un Mac fixe d’au moins 2023, ou encore un iPhone ou un iPad d’au moins septembre 2021, votre appareil est concerné par au moins l’une des deux failles.

Plusieurs points sont également à préciser. D’abord, Firefox ne figure pas dans la liste des navigateurs vulnérables, car les chercheurs n’ont pas eu le temps de lancer des tests. Dans l’absolu, rien n’empêche selon eux que le navigateur de Mozilla soit également concerné. D’ailleurs, si des tests ont été effectués sur Chrome, rien n’empêche a priori que l’ensemble des navigateurs basés sur Chromium soient eux aussi vulnérables.

Peut-être aussi dans d'autres processeurs

Ensuite, même si FLOP et SLAP ont été démontrées dans les puces Apple, les chercheurs indiquent que les techniques LVP et LAP peuvent être utilisées dans les processeurs d’autres entreprises. Si tel est le cas, en fonction de l’implémentation, ces puces pourraient elles aussi être vulnérables. Leurs travaux seront présentés à deux reprises dans le courant de l'année : SLAP au symposium de l'IEEE sur la sécurité et la vie privée en mai, FLOP à la conférence Usenix en août.

Enfin, les chercheurs ont précisé qu’Apple avait été prévenue de ces failles en mai 2024. Selon des responsables de l’entreprise en privé, un travail serait en cours pour publier des correctifs.

Apple, interrogée à ce sujet par Ars Technica, n'a pas confirmé l'échange privé avec les chercheurs ni le développement de correctifs. « Nous tenons à remercier les chercheurs pour leur collaboration, car cette démonstration de faisabilité nous permet de mieux comprendre ce type de menaces. Sur la base de notre analyse, nous ne pensons pas que ce problème pose un risque immédiat pour nos utilisateurs », a-t-elle ajouté.

Commentaires (10)

votre avatar
Est-ce que c'est spécifique aux puces Mx Apple ou cla aurait la potentialité de toucher toutes les autres puces ARM ?
votre avatar
uniquement celles qui font de l'exécution spéculative, en tout cas
votre avatar
L'exécution spéculative est nécessaire à cause des gros pipeline des processeurs depuis pas mal d'année avec l'exemple tragique du Pentium 4 qui comptait 50 étage si ma mémoire est bonne. Mais cela est en place depuis les années 90 vu qu'on en trouvait déjà dans les PowerPC.

Dans une boucle d'itération, le cas général est de revenir au point de bouclage et la sortie de boucle se fera une seule fois. Plutôt que de vider le pipeline par manque d'information sur la condition du saut, on prend le parti de prédire un saut en arrière et on commence à préparer l'exécution de la boucle suivante.
Quand la prédiction est fausse, on perd autant de cycles

Si on optimisait le code pour que le processeur sache quel saut sera fait, plusieurs instructions à l'avance, on pourrait dans certains cas éviter d'avoir recours à la prédiction. Le compilateur peut en effet savoir quelles lignes de code vont modifier la valeur des variables qui servent à déterminer les conditions de bouclage et déterminer cette condition avant la fin de boucle.
votre avatar
Ce que tu décris existe déjà si je m'abuse. De mémoire, depuis Sandy Bridge il y a une unité LSD (Loop Stream Detector) qui est en charge de ce que tu décris.

Pour aider le processeur, ça peut se faire déjà au niveau du code mais ça dépend des langages et surtout du niveau des devs. Et comme dans un monde où on favorise le pissage de code à l'efficacité (sauf niches mais c'est l'exception que la norme), ce genre de choses n'arrivent pas très souvent ou manière fortuite.
votre avatar
A force d'entendre parler de ces failles, je me demande pourquoi nous, en tant qu'utilisateurs, on ne pourrait pas simplement désactiver les processus d'exécution spéculative ?

Ça ralentirait à ce point la vitesse d'exécution de notre quotidien ?
votre avatar
De manière simple non. On peut désactiver les caches mais ça demande de bidouiller des registres processeurs en kernel mode.
Pour l'execution spéculative, il y a certainement des bits pour ça dans le microcode...

Mais oui, désactiver la spéculation se verrait sans soucis, en particulier si tu as des interfaces graphiques.
votre avatar
C'est le cas sous Linux, il y'a toute une rubrique dédiée à ça dans le paramétrage du noyau, c'est directement à la racine de menuconfig "Mitigations for CPU vulnerabilities"

Autre piste les paramètres de gcc (j'ai un peu la flemme de lire les 20000 lignes de manpage :p) :
un simple -march=i386 compile du code Intel 386, mais je ne suis pas sûr que ça suffise (le microcode est compilé par la partie frontend du CPU, et ça ne me surprendrait pas que la prédiction de branchement reste active au niveau du back avec un code "i386" en entrée).
-funroll-all-loops un peu violent mais déroule toutes les boucles à la compilation, tu coup y'a moins (aucune ?) prédiction de branchements possible.
... y'a des centaines (milliers ?) d'options disponible dans gcc...

A noté que GCC ne fera rien si le code source C inclus des optimisations en code assembleur.

Il faut bien avoir conscience qu'enlever ces optimisations, c'est revenir 30ans en arrière (le pentium pro qui a introduit la majorité des prédictions de branchement modernes date de 1995 !)
votre avatar
Les "Mitigations for CPU vulnerabilities" ne permettent pas de désactiver ou non l’exécution spéculative. Elles permettent de contrôler logiciellement l'activation de contre-mesures au sein du noyau pour réduire les failles comme Spectre & co. En n'aucun cas elles ne désactivent l’exécution spéculative.

@Nozalys parle de l’exécution spéculative au sein du microprocesseur, utiliser -march=i386 ne changera en rien la capacité du CPU à essayer de prédire le futur. C'est une fonctionnalité intrinsèque aux microprocesseur sur lequl on n'a, à l'heure actuelle pas de contrôle direct, seulement de l'indirect.

Le -funroll-all-loops ne sert pas au prédicat de branchement. Il y a déjà des unités dans le CPU pour ce genre de choses (cf mon post du dessus). Cette option sert surtout à dérouler des boucles pour pouvoir 1. permettre au compilateur d'optimiser via les unités vectorielles du code, 2. de saturer les unités calculs 3. cacher la latence et maximiser le throughput. Mais ce n'est pas aussi simple en réalité à utiliser surtout sans aller lire & comprendre l'assembleur pour s'assurer que le compilateur ne fait pas n'importe quoi.

De manière générale, la seule façon possible de désactiver totalement l’exécution spéculative serait via le microcode. Mais j'avoue que pour le fun, ça serait sympa de pouvoir essayer.


Quand à GCC ne fera rien si le code source C inclus des optimisations assembleur, tout dépend de comment ça a été inclus. Si c'est via le linker, il ne fera rien car ce n'est pas de sa "juridiction".Si c'est du GAS (inline assembleur), alors oui GCC peut y mettre son nez si celui-ci n'a pas l'attribut volatile.
votre avatar
Merci pour ces précisions, effectivement je me doutais que les optims sont côté microcode et donc inaccessible à l'utilisateur, je suis également assez curieux de la partie microcode, c'est documenté / bidouillable / flashable ?

a priori oui : https://misc0110.net/files/cpu_woot23.pdf
votre avatar
Le microcode est chargée très tôt au démarrage du kernel. Je ne sais pas si le BIOS/UEFI peut aussi s'en occuper.

Concernant sa modification, elle est uniquement de l'ordre du reverse-engineering et assez limité. Le papier que tu cites ne fonctionne que Goldmont (en gros les Atoms). Et personnellement modifié un micro-code c'est prendre le risque de transformer son processeur en cale-porte si ce n'est pas fait officiellement.

FLOP et SLAP : les puces Apple vulnérables à deux nouvelles attaques

  • Prédictions malveillantes

  • Zoom sur FLOP

  • De 5 à 10 minutes nécessaires

  • Qui est concerné ?

  • Peut-être aussi dans d'autres processeurs

Fermer