Des chercheurs viennent de présenter une faille qui touche les appareils Apple basés sur des puces Apple (iPhone, iPad, tous les Mac récents) et qui passe par Safari, le navigateur maison. Et si elle est sophistiquée, elle est aussi visiblement assez efficace.
Avant de parler du fonctionnement, parlons des risques. Premièrement, tous les appareils cités sont touchés et pour le moment, la seule solution pour éviter l'attaque est de passer par Safari Technology Preview sur Mac (au minimum en version 173) ou — évidemment — un autre navigateur qui ne se base pas sur WebKit. Sur les appareils IOS, cette possibilité disparaît : tous les navigateurs disponibles sur l'App Store passent par WebKit. Apple connaît la faille depuis plusieurs mois et les auteurs de l'étude indiquent avoir travaillé avec les équipes de sécurité d'Apple.
Que permet iLeakage ?
Les auteurs donnent quelques exemples d'attaque. Il est possible d'afficher le contenu d'une boîte de messagerie Gmail, récupérer les adresses IP de la cible, attaquer un gestionnaire de mot de passe (LastPass dans l'exemple) et récupérer des mots de passe entrés automatiquement ou — point lié — déconnecter un utilisateur pour ensuite tenter de le reconnecter en récupérant les données.
L'attaque a tout de même plusieurs défauts : le site attaqué doit être ouvert depuis celui de l'attaquant et — surtout — l'ensemble est assez lent. Il faut plusieurs minutes pour analyser correctement le contenu et les données sont récupérées à une cadence plutôt faible, de l'ordre d'une trentaine de bits par seconde. Ce point implique qu'une simple chaîne de caractères (par exemple 64 octets) nécessite plusieurs dizaines de secondes.
Vous trouverez quelques exemples d'attaque en vidéo sur le site dédié, mais nous vous mettons ici l'attaque sur Gmail.
Comment ça marche ?
Nous n'allons pas vous détailler l'ensemble, mais il faut comprendre un point : les CPU actuels ont des architectures qui peuvent amener des données à rester en mémoire (notamment dans les différents niveaux de mémoire cache) sans que ce soit attendu. Tous les processeurs modernes effectuent ce que l'on appelle de la spéculation et de l'exécution dans le désordre (OoO, pour Out of Order). L'idée est simple : devant un flux d'instructions, il est possible de tenter de deviner les prochaines instructions à exécuter pour utiliser les différentes unités du CPU au maximum plutôt que d'attendre qu'une instruction s'exécute avant de traiter la suivante.
Cette solution est généralement efficace mais dans certains cas, les CPU peuvent exécuter la mauvaise branche dans un choix qui laisse deux possibilités. Quand ça arrive (ce qui reste rare), le processeur retourne donc littéralement en arrière, mais certaines données de la mauvaise branche peuvent se trouver dans les différents niveaux de mémoire cache… et récupérées. Il existe des contre-mesures, mais ces failles existent dans les puces Intel, AMD ou Apple. Elles sont fondamentalement liées aux techniques qui améliorent les performances, qu'il semble irréaliste de ne pas employer.
Pour iLeakage, les chercheurs ont analysé la structure des puces Apple pour la mémoire cache, mesuré le niveau de spéculation (et les données récupérables) et trouvé des méthodes pour y accéder en outrepassant certaines limites dans les navigateurs.
Au niveau de Safari, ils ont su passer outre certaines protections d'Apple. Depuis très longtemps, Safari effectue le rendu de chaque page dans une zone mémoire isolée, par exemple : un onglet ouvert sur macg.co ne doit en théorie pas permettre de lire le contenu de la mémoire d'un onglet ouvert sur apple.com. Mais en utilisant certaines fonctions JavaScript, il est possible de partager une zone mémoire entre deux sites différents et diverses méthodes (trop compliquées pour être détaillées ici) permettent de casser les protections de WebKit sur l'accès à la mémoire.
Comment se protéger ? Est-ce grave ?
De l'aveu même des auteurs, c'est une attaque compliquée, ce qui n'enlève rien à sa dangerosité. Malgré tout, les risques restent faibles : il faut visiter un site « attaquant » qui va ouvrir des sites à attaquer et l'ensemble est assez long, ce qui reste peu probable (ils indiquent qu'il n'y a pas de preuve de l'utilisation publique de l'attaque). En attendant une correction dans Safari, il est donc possible de passer par Safari Technology Preview ou d'activer une option précise dans les fonctions de Safari. Ces deux méthodes ne fonctionnent que sous macOS, pas sous iOS.
Pour l'option, il faut d'abord activer le menu de debug de Safari avec la ligne suivante dans le Terminal (sous macOS Sonoma).
defaults write com.apple.Safari IncludeInternalDebugMenu 1
Ensuite, dans le menu Debug, il faut aller dans la section WebKit Internal Features et cocher Swap Processes on Cross-Site Window Open.
Et il faut bien évidemment se méfier des sites qui ouvrent une nouvelle fenêtre ou un nouvel onglet automatiquement.
