iLeakage, la faille qui exploite Safari et les puces Apple pour faire fuiter des informations

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é.