iLeakage, la faille qui exploite Safari et les puces Apple pour faire fuiter des informations
Quand on a un peu de temps à tuer
Le 27 octobre 2023 à 14h27
6 min
Logiciel
Logiciel
Sur iOS et macOS, il est possible de forcer le navigateur Safari à révéler des informations sensibles, jusqu’aux mots de passe. Pour fonctionner, la méthode exploite également les puces Apple. Elle demande cependant quelques conditions, dont… du temps.
La faille a été nommée iLeakage par les chercheurs qui ont mis la main dessus. Il s’agit d’une attaque par canal auxiliaire, c’est-à-dire qu’elle peut prendre place grâce à des indices laissés dans les signaux électromagnétiques, les zones de caches et autres composantes du processeur. Dans le cas présent, les signaux récupérés sont liés à l’exécution spéculative.
Ce type d’exécution se retrouve dans tous les processeurs depuis un bon moment. Elle permet un traitement de plusieurs branches d’instructions, comme Apple l'explique :
« L’exécution spéculative accélère les performances en traitant plusieurs instructions simultanément, éventuellement dans un ordre différent de celui dans lequel elles ont été transmises au processeur. Afin d’améliorer les performances, le processeur prédit la destination d’un branchement susceptible d’être suivi, puis poursuit l’exécution des instructions de manière spéculative vers cette destination, avant même que le branchement ne soit totalement traité. Si la prédiction s’avère incorrecte, l’exécution spéculative est annulée de manière invisible pour le logiciel. »
Cette page avait été publiée par l’entreprise lorsque les failles Meltdown et Spectre avaient été révélées. L’exécution spéculative est en effet au cœur de nombreuses attaques par canal auxiliaire révélées ces dernières années. C’est une nouvelle fois le cas avec iLeakage.
Comment fonctionne la faille
Sur la page dédiée, les chercheurs indiquent avoir conçu un site (non public) pour exploiter la faille dans Safari. Le navigateur d’Apple est souvent utilisé par défaut sur les Mac et ne peut être évité sur iOS, puisque les navigateurs tiers ont l’obligation d’utiliser WebKit comme moteur de rendu.
Lors de la visite, le site passe par JavaScript pour ouvrir silencieusement un deuxième site, au choix de l’attaquant. C’est sur ce site que les opérations effectuées par l’utilisateur vont pouvoir être récupérées. De là, on peut récupérer le contenu de certains emails sur Gmail, l’historique des vidéos sur YouTube ou, bien pire, un mot de passe quand il est injecté dans le champ correspondant par le gestionnaire utilisé.
JavaScript est ici utilisé pour contourner des défenses présentes dans Safari. Le navigateur ouvre en effet chaque site dans une zone isolée de la mémoire (avec un adressage sur 35 bits). Ils ont pu alors créer une zone mémoire partagée entre deux sites, expliquent les chercheurs :
« Nous avons contourné l'adressage 35 bits de Safari et les contre-mesures d'empoisonnement des valeurs, en créant une primitive capable de lire et de faire fuir de manière spéculative n'importe quel pointeur 64 bits au sein du processus de rendu de Safari. En combinant cela avec une nouvelle méthode pour consolider les sites web de différents domaines dans le même espace d'adressage, nous sommes en mesure de monter une attaque spéculative de type confusion qui fait fuir des informations sensibles. »
Ils ajoutent que les puces A et M, utilisées respectivement dans les appareils mobiles et les Mac, comportent bien des défenses contre ce genre d’attaque, mais qu’ils y ont trouvé des faiblesses qui ont rendu possible leur attaque.
Il faut savoir prendre son temps
L’attaque est efficace, mais elle est lente. Selon les chercheurs, il faut environ 5 minutes pour établir le profil de la machine cible. Ensuite, la récupération des informations se fait à un rythme limité : 30 secondes pour 512 bits en moyenne, équivalant à une chaine de 64 caractères par exemple.
Cette lenteur provient en bonne partie de la manière même dont sont récupérées les informations. Dans le descriptif d’Apple, on apprenait ainsi qu’en cas de prédiction incorrecte, l’exécution était « annulée de manière invisible ». Ce n’est pas tout à fait vrai : on ne voit rien devant notre écran, mais dans certains cas, les données de la branche abandonnée peuvent se retrouver dans un cache ou un autre. On peut alors les récupérer, si l’on se montre patient.
Dans leur page d’explications, les chercheurs ont même publié un tableau résumant la vitesse de récupération que l’on peut attendre d’iLeakage en fonction de l’appareil utilisé, et donc de la puce présente :
Comme on peut le voir, la vitesse est comprise entre 24 et 34 bits par seconde. C’est lent, mais si l’objectif est de récupérer certaines informations très précises, c’est suffisant. La difficulté réside davantage dans les 5 minutes nécessaires à l’établissement de la connexion. Si l’idée est de voler un mot de passe spécifique, il faudra amener la personne à le faire, sans éveiller les soupçons.
Peu de solutions pour le moment
Dans leur exposé, les chercheurs indiquent qu’Apple a été prévenue le 12 septembre 2022, soit il y a plus d’un an. Aucun correctif n’a pour l’instant été émis, mais l’attaque n’est plus possible dans Safari Technology Preview depuis sa version 173, sortie le 28 juin dernier. Les chercheurs ont attendu plus de 400 jours avant de parler de leur découverte et affirment ne pas être au courant d’une exploitation de cette technique dans la nature.
Car si iLeakage est une attaque efficace ne réclamant que peu de ressources matérielles pour être mise en place, elle nécessite un haut niveau d’expertise technique, selon les chercheurs. Il faudrait ainsi des années d’expertise dans le domaine des attaques par canal auxiliaire, mais surtout une rétro-ingénierie complète des puces A et M d’Apple, nécessaire pour comprendre leur structure et le type de canaux auxiliaires qu’elles contiennent.
Actuellement, ils estiment que les chances de voir cette attaque se produire sont très faibles, voire nulles. Il est probable que le correctif sera distribué par Apple avant qu’iLeakage se retrouve dans la nature. Les chercheurs parlent d’un travail de plusieurs années et d’informations volontairement parcellaires dans leur compte-rendu.
En attendant, on peut toujours se méfier d’un site qui en ouvrirait immédiatement un autre, particulièrement s’il s’agit d’un service connu sur lequel on est déjà connecté.
iLeakage, la faille qui exploite Safari et les puces Apple pour faire fuiter des informations
-
Comment fonctionne la faille
-
Il faut savoir prendre son temps
-
Peu de solutions pour le moment
Commentaires (10)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 27/10/2023 à 14h40
Le nom donné à la faille
Le 27/10/2023 à 15h23
C’est typiquement le genre de compétences à la portée d’un État avancé. C’est donc quand même un problème à prendre au sérieux.
Le 27/10/2023 à 21h53
Avec toutes les applications de type jeux à la con ou application pour apprendre une autre langue, qui te harcèle pour que tu t’en serve tout le temps, facile de loger un truc comme cela.
Le 28/10/2023 à 01h08
Sur le noyau Linux, sur x86, il n’y a pas une mitigation qui flush le cache, forcé ou avec changement de contexte du processus ?
Le 28/10/2023 à 21h00
Du coup sur l’onglet parent est fermé, ça règle la question non ?
Le 29/10/2023 à 10h24
Il y a plein de mitigations maintenant: que seuls des threads de même process s’exécutent sur le même coeur, de flusher le cache, de garder des infos sur l’espace mémoire de la carte graphique…
Dans quelques temps, la nouveauté sera que le navigateur sera un hyperviseur et que chaque onglet sera une VM, t il faudra une carte graphique par onglet pour la sécurité…
Le 29/10/2023 à 11h33
Le problème à l’époque de Meltdown et de Spectre, c’était que la faille touchait le processeur physique, et permettait donc de sortir du cadre de la VM. A priori, le problème est similaire donc VM ou pas, cela ne changera pas grand chose.
La faille touchant MacOS me semble moins grave, pour une raison relativement simple : les puces d’Apple sont utilisées uniquement dans les produits Apple, et il n’y a quasiment pas de serveur Apple, contrairement à Meltdown et Spectre qui se trouvaient sur de très nombreux serveurs, rendant sensible tous les hébergements mutualisés et de type VPS.
L’exploitation de la faille sur une machine personnelle est beaucoup plus difficile et aléatoire. Mais reste très fourbe car totalement invisible…
Le 29/10/2023 à 11h47
Je vais acheter des actons Nvidia alors !
Le 29/10/2023 à 15h08
Tout à fait d’accord.
Je force le trait, mais ça montre la limite du modèle actuel. Toutes les ressources partagées sont plus ou moins attaquables.
Le 29/10/2023 à 18h50
Un GPU étant un nombre plus ou moins important d’unités de calcul (par ex. ma RTX 2070 dispose de 2304 unités), je pense plutôt qu’il y aura éventuellement la définition d’une affinité des unités par processus avant de multiplier les cartes graphiques ;)