iLeakage : attaque de spéculation sans temporisateur, basée sur le navigateur, contre les appareils Apple

 (ileakage.com)
1 points par GN⁺ 2023-10-26 | 1 commentaires | Partager sur WhatsApp
  • Bien que les atténuations de Spectre se poursuivent depuis près de 6 ans, iLeakage montre que des canaux auxiliaires de spéculation peuvent encore être exploités dans Safari sur Mac, iPad et iPhone
  • Un attaquant peut inciter un utilisateur à visiter une page web malveillante puis à cliquer, avant d’utiliser JavaScript et WebAssembly pour amener Safari à rendre une page web arbitraire et récupérer des informations sensibles
  • La démonstration inclut la récupération des titres de messages récents de Gmail, des identifiants remplis automatiquement d’Instagram, de l’historique de visionnage YouTube, ainsi que du mot de passe Facebook et du jeton SMS 2FA sur un MacBook Pro basé sur Apple M3
  • Le périmètre affecté couvre les appareils macOS et iOS utilisant des CPU Apple A-series et M-series, et une atténuation a été intégrée à iOS 17.2 et macOS 14.2 avec Safari 17.2
  • Il est aussi possible de s’en protéger avec le Lockdown Mode ou en désactivant JavaScript, mais avec des limitations fonctionnelles ; l’attaque s’exécute dans Safari et ne laisse pas de traces dans les journaux système, ce qui la rend très difficile à détecter

Le risque Spectre réapparaît sur les appareils Apple

  • iLeakage est une attaque par canal auxiliaire de spéculation visant le navigateur web Safari
  • Elle cible les appareils macOS et iOS utilisant des CPU Apple A-series ou M-series
    • Cela inclut les iPhone et iPad récents
    • Ainsi que les ordinateurs portables et de bureau Apple depuis 2020
  • En principe, le code d’un onglet de navigateur ne devrait pas pouvoir inférer le contenu d’un autre onglet, mais iLeakage peut lire le contenu d’une page web cible pour un utilisateur ayant visité la page de l’attaquant et cliqué dessus
  • Les informations récupérables peuvent inclure des données personnelles, des mots de passe et des informations de carte bancaire
  • Les chercheurs ont divulgué leurs résultats à Apple le 12 septembre 2022, soit 408 jours avant la publication

Données sensibles réellement récupérées

  • Les chercheurs ont démontré des cas de récupération d’informations à forte valeur sur des services grand public

  • Identifiants Instagram

    • Sur Safari pour macOS, ils ont utilisé un scénario où l’utilisateur se connecte à Instagram avec le gestionnaire d’identifiants à remplissage automatique LastPass

  • Boîte de réception Gmail

    • Sur Safari pour iOS, ils supposent que l’utilisateur est connecté à Google et récupèrent les titres des messages récents d’un compte Gmail sur iPad

  • Historique YouTube

    • Ils récupèrent l’historique de visionnage YouTube dans Chrome pour iOS
    • Chrome sur iOS fonctionne comme une surcouche du moteur de navigation Safari en raison des règles de l’App Store d’Apple

  • Mot de passe Facebook et jeton 2FA

    • Ils récupèrent d’abord le mot de passe Facebook sur un MacBook Pro équipé d’une puce Apple M3, sous macOS 14.1.1 et Safari 17.1
    • Ils récupèrent ensuite le jeton SMS 2FA envoyé à un téléphone Android via Google Messages

Fonctionnement de Spectre et des canaux auxiliaires

  • La plupart des CPU modernes utilisent l’exécution spéculative : lorsque le résultat d’un branchement n’est pas immédiatement disponible, ils prédisent le chemin d’exécution et traitent d’abord les instructions correspondantes
  • Si la prédiction est erronée, le CPU annule les changements d’état, mais des traces peuvent subsister dans l’état microarchitectural, par exemple dans le cache
  • Spectre est une vulnérabilité matérielle qui exploite ces traces pour lire des données normalement inaccessibles selon la sémantique du programme
  • Un canal auxiliaire peut exploiter des caractéristiques d’implémentation du système même lorsqu’un programme exécute un algorithme sûr
    • Exemples : le son, les émissions électromagnétiques, le throttling thermique et le partage des ressources microarchitecturales du CPU
  • Si l’attaquant et la cible s’exécutent sur le même CPU, ils partagent des ressources comme les cœurs, les caches et les buffers internes ; cette contention peut être mesurée indirectement via des variables comme le temps d’exécution ou la consommation électrique

Une attaque sans temporisateur qui contourne les défenses de Safari

  • Depuis Spectre, les éditeurs de navigateurs ont renforcé leurs défenses contre les attaques par exécution spéculative et exécution transitoire
  • Les protections de Safari incluent le 35-bit addressing, le value poisoning, l’isolation par processus pour chaque onglet et des temporisateurs à faible résolution
  • iLeakage constitue la première démonstration d’une attaque par spéculation contre Safari et les CPU Apple Silicon
  • L’attaque commence par une reconstruction empirique de la configuration du cache non documentée des CPU Apple
    • Les chercheurs construisent ensuite un gadget basé sur la spéculation capable de distinguer les cache hits des cache misses en n’utilisant qu’un temporisateur basse résolution
    • Ils démontrent aussi une variante exploitant une condition de concurrence sans temporisateur
  • Ce gadget est utilisé à la fois pour les tests de création d’eviction sets et pour le canal caché
  • Après adaptation à Safari, ils amènent Safari, pendant l’exécution spéculative du CPU, à exécuter sur un objet de type incorrect créé par l’attaquant du code prévu pour un type de données spécifique
  • Au final, cela permet un out-of-bounds read n’importe où dans l’espace d’adressage du processus de rendu Safari
  • Combinée à une nouvelle méthode de fusion de sites web de domaines différents dans le même espace d’adressage, l’attaque mène à une confusion de types spéculative permettant l’exfiltration d’informations sensibles

Atténuation, difficulté de détection et impact selon les navigateurs

  • iLeakage a été atténuée dans Safari 17.2, inclus dans iOS 17.2 et macOS 14.2
    • La réponse recommandée consiste à mettre à jour les appareils Apple vers la dernière version de l’OS
  • Le Lockdown Mode atténue iLeakage en désactivant la compilation JIT de Safari
    • La compilation JIT est la fonctionnalité de performance utilisée par iLeakage pour construire ses primitives d’attaque
    • Le Lockdown Mode peut modifier le fonctionnement de l’appareil, notamment en bloquant certaines pièces jointes de messages et les appels FaceTime inconnus
    • La liste complète figure dans la documentation Apple sur le Lockdown Mode
  • Désactiver JavaScript bloque aussi iLeakage, mais Safari peut alors rendre certains sites de manière incorrecte ou incomplète, et des fonctions web avancées comme le paiement en ligne peuvent cesser de fonctionner
  • iLeakage s’exécute dans Safari et ne laisse pas de traces dans les fichiers journaux système, ce qui la rend très difficile à détecter
    • En revanche, la visite de la page malveillante peut laisser des traces dans le cache du navigateur concernant les pages récemment visitées
  • Aucune preuve d’exploitation réelle n’a été observée
    • La chaîne d’attaque de bout en bout est très difficile à mettre en œuvre et exige une connaissance avancée des attaques par canal auxiliaire basées sur le navigateur et de l’implémentation de Safari
  • Il reste recommandé de continuer à utiliser les gestionnaires d’identifiants
    • iLeakage peut récupérer des identifiants remplis automatiquement sur une page web
    • De nombreuses plateformes exigent néanmoins une interaction utilisateur pour déclencher le remplissage automatique
  • Chrome, Firefox et Microsoft Edge sur macOS utilisent d’autres moteurs JavaScript, donc iLeakage, qui exploite une spécificité du moteur JavaScript de Safari, n’y fonctionne pas
  • Sur iOS, à cause des politiques d’Apple sur l’App Store et le sandboxing, les autres navigateurs utilisent aussi le moteur JavaScript de Safari
    • Chrome, Firefox et Edge sur iOS sont des wrappers autour de Safari offrant des fonctions annexes comme la synchronisation des favoris et des paramètres
    • Presque toutes les applications de navigateur sur l’App Store sont vulnérables à iLeakage
  • L’article académique est disponible ici : iLeakage paper, et a été publié à l’ACM Conference on Computer and Communications Security 2023

À lire aussi

1 commentaires

 
GN⁺ 2023-10-26
Avis sur Hacker News

  • Il semble manquer quelque chose dans cette FAQ : on se demande s’il s’agit d’une vulnérabilité WebKit ou d’une vulnérabilité Safari, si Lockdown Mode atténue le problème alors que ce réglage développeur n’existe pas sur Safari mobile, et à quel moment cela a été signalé à Apple
    La page a ensuite été mise à jour et la dernière question a obtenu une réponse : les chercheurs ont communiqué leurs résultats à Apple le 12 septembre 2022, soit 408 jours avant la publication officielle

    • Techniquement, on peut y voir le Hacker News Favorite Processor, autrement dit une vulnérabilité M1/M2, mais comme tous les CPU concernés sur le marché partagent actuellement la même faiblesse, cela devient pratiquement une propriété avec laquelle les logiciels doivent être conçus pour composer
      Il est irréaliste d’éliminer tous les gadgets Spectre possibles dans WebKit ; les navigateurs doivent donc s’appuyer sur les mesures d’atténuation Spectre du système d’exploitation, par exemple en isolant différents sites web dans différents processus
      La FAQ dit : « en fin de compte, cela permet d’obtenir une lecture hors limites n’importe où dans l’espace d’adressage du processus de rendu Safari », donc personnellement j’y vois une vulnérabilité due à une mauvaise implémentation de l’isolation des sites dans Safari
    • La dernière question a sa réponse dans la FAQ : les chercheurs ont communiqué leurs résultats à Apple le 12 septembre 2022, soit 408 jours avant la publication officielle
    • Cela ressemble à une vulnérabilité architecturale permettant d’exploiter un canal auxiliaire de spéculation similaire à Spectre dans Safari ou d’autres navigateurs
      Les environnements dans lesquels elle est exploitable dépendent des détails d’implémentation des gadgets JavaScript servant à déclencher et mesurer ce canal auxiliaire, ce qui figure peut-être dans l’article que je n’ai pas encore lu
    • Une réponse a maintenant été ajoutée à la FAQ : c’est une vulnérabilité Safari, et il est indiqué que « iLeakage exploite des caractéristiques du moteur JavaScript de Safari »
      Lockdown Mode atténue le problème, car il désactive la compilation JIT dans Safari et bloque les fonctionnalités de performance dont iLeakage se sert pour construire ses primitives d’attaque

  • À la question « est-ce risqué d’utiliser un gestionnaire d’identifiants ? », la plupart répondent que non, mais s’il y a effectivement une fuite mémoire, on pourrait penser que cela devrait affecter toute la mémoire de l’espace du processus Safari
    Je ne connais pas assez bien ce domaine pour comprendre pourquoi l’utilisation d’un gestionnaire d’identifiants constituerait une condition particulière

    • En gros, cela semble vouloir dire : cela n’apporte pas de sécurité supplémentaire contre cette attaque précise, mais utiliser un gestionnaire de mots de passe reste généralement plus sûr, et ne vous rend pas plus vulnérable à cette attaque
      Ils cherchent sans doute à éviter que les gens reviennent à des pratiques du type « newpassword2 » ; désactiver l’autoremplissage et remplir via un raccourci clavier ou une autre interaction utilisateur serait plus sûr
    • L’une des démos consistait à récupérer une paire identifiant/mot de passe d’un site tiers comme Instagram, parce que le gestionnaire de mots de passe avait rempli automatiquement le champ et que ces données se retrouvaient donc en mémoire
      On pourrait en déduire que si l’on n’utilise pas de gestionnaire de mots de passe, qu’on n’enregistre rien dans le navigateur et qu’on saisit tout manuellement à chaque fois, on est immunisé ; mais c’est un contre-argument discutable pour plusieurs raisons
      Les gestionnaires de mots de passe sont bénéfiques pour bien d’autres raisons, et même si un mot de passe est volé, au moins un seul site web est compromis
      Cette technique peut probablement aussi voler des jetons de session ; ce n’est peut-être pas aussi grave qu’un vol de mot de passe, mais cela reste problématique
      Configurer le gestionnaire de mots de passe pour qu’il ne remplisse qu’après un clic permettrait aussi de bloquer cette attaque
    • Cela semble vouloir dire qu’utiliser un gestionnaire de mots de passe ne vous rend pas plus vulnérable
      Un mot de passe rempli automatiquement sur une page peut être récupéré comme un mot de passe saisi manuellement, mais cela ne permet pas de lire directement tous les mots de passe stockés dans le gestionnaire
    • Je comprends que cette vulnérabilité n’autorise l’accès qu’à la mémoire des processus Safari/WebKit concernés, en particulier aux sites ouverts via des appels à window.open
      Les mots de passe stockés dans une application distincte de gestion de mots de passe restent inaccessibles, sauf si cette application les remplit automatiquement dans une fenêtre ou un processus Safari compromis
    • Je pensais que Safari n’était généralement pas vulnérable aux attaques par spéculation, car il place normalement différentes origines et extensions dans des espaces d’adressage distincts
      Cette attaque a trouvé un moyen de faire partager le même espace d’adressage à deux origines différentes, et elle ne semble pas s’appliquer aux extensions
      L’article dit : « Nous montrons une nouvelle technique qui abuse de la politique d’isolation des sites de Safari, si bien qu’une page attaquante n’a qu’à ouvrir une page victime arbitraire via l’API JavaScript window.open pour partager le même espace d’adressage. »

  • Je ne sais pas si le cadrage “WebKit uniquement” est vraiment juste. L’exploitation du cache elle-même semble générale, et la citation indique aussi une précision presque parfaite sur Safari, Firefox et Tor
    Je me demande également si l’attaque via window.open() est vraiment spécifique à WebKit, ou si l’étude s’est simplement davantage concentrée sur WebKit
    window.open() implique un contexte partagé où la fenêtre appelante reçoit une référence vers la nouvelle fenêtre, et la nouvelle fenêtre possède une référence inverse via window.opener ; je me demande donc si les autres moteurs de navigateur parviennent réellement à une isolation complète

    • Chromium et Firefox ont implémenté l’isolation des sites dans leurs navigateurs de bureau, de sorte que des pages de sites différents ne devraient pas être chargées dans le même processus
      Sur les navigateurs mobiles, l’isolation des sites de Chromium est limitée, et Firefox n’a pas encore terminé son implémentation
      https://www.chromium.org/Home/chromium-security/site-isolati...

  • C’est déroutant. Ça ressemble à un problème de haute gravité, mais le correctif est caché derrière le menu Debug. Je ne comprends pas pourquoi cela a été rendu public avant d’être correctement déployé partout
    Cela montre aussi que les mitigations de canal auxiliaire sont en pratique inutiles et qu’il ne faut pas prétendre que ce type d’attaque est corrigé
    Si c’est un hôte qui exécute plusieurs applications sur un CPU moderne, exécuter du code non fiable n’est pas sûr, même avec du sandboxing

    • Apple semble avoir eu plus de 400 jours pour corriger cela, ce qui est déjà plus long que le délai que j’aurais accordé
      Il vaut largement mieux informer les utilisateurs Apple du risque que de les laisser encore plus d’un an dans l’ignorance
      Je suis favorable au fait de laisser aux entreprises le temps de corriger les bugs, mais à partir d’un certain point, ne pas prévenir les personnes concernées devient encore plus irresponsable
    • L’état des mitigations me paraît flou aussi, mais l’article est plus clair que le site web
      L’article explique qu’une sortie spéculative du sandbox JavaScript reste possible, mais que l’attaquant est limité à son propre espace d’adressage et à la lecture de ses propres données
      Il indique qu’au moment de la rédaction, le patch Apple était public et implémenté dans Safari Technology Preview 173 ou ultérieur, et [57] correspond à https://github.com/WebKit/WebKit/pull/10169
      Juste en dessous, l’ingénieur continue de lier des patchs de renforcement supplémentaires sur window.open() et l’isolation des processus
    • Sur Safari 17.0 standard sous Ventura, je croyais que Swap Processes on Cross-Site Window Open était déjà activé et marqué Stable
      Comme je ne l’avais pas activé moi-même, je pensais qu’Apple l’avait déjà activé et que la description était peut-être obsolète, mais j’ai fini par voir que je regardais Swap Processes on Cross-Site Navigation, au nom similaire, et cela ne semble pas activé par défaut pour le moment
    • C’est parce qu’Apple, « dernier rempart de la vie privée et de la sécurité », a gardé ça plus de 400 jours sans le corriger
      Il faut blâmer Apple, qui est resté les bras croisés si longtemps, plutôt que les chercheurs qui l’ont publié avant le déploiement du correctif
    • Ce correctif a probablement été caché derrière le modèle de processus de WebKit parce qu’il fallait le modifier et qu’il est encore en test avant un déploiement général
      Toutes les attaques par canal auxiliaire ne sont pas corrigées, mais dire que les mitigations de canal auxiliaire sont inutiles est inapproprié
      De la même façon qu’une ceinture de sécurité n’est pas inutile même si des gens meurent dans des accidents de voiture, les mitigations augmentent fortement la difficulté d’exploitation

  • Il est indiqué que « les chercheurs ont signalé leurs résultats à Apple le 12 septembre 2022 », et je me demande vraiment pourquoi Apple a laissé cela presque sans suite pendant plus d’un an

    • Parce qu’ils le peuvent
      Apple fait partie des seigneurs des CVE et peut refuser l’émission de CVE pour ses propres produits ; avec un tel pouvoir, ils peuvent avancer aussi lentement qu’ils le souhaitent

  • J’avais cru voir sur le site iLeakage un texte à propos d’un correctif, puis il a disparu. Je pensais m’être trompé, mais le site était effectivement en train de changer au cours de la dernière heure
    Il y avait une phrase disant « Apple vient de publier iOS 17.1, iPadOS 17.1, macOS Sonoma 14.1, mettez donc vos appareils à jour », et maintenant cela a été retiré
    https://github.com/ileakage-authors/ileakage-authors.github....

    • On dirait que l’un des auteurs de l’article lit ce fil
      Après que j’ai signalé qu’il n’y avait pas de calendrier de divulgation sur le site, une courte section a été ajoutée à la FAQ, et comme la situation sur le déploiement du correctif est confuse, les chercheurs semblent eux aussi désorientés
    • Étrange. Après mise à jour vers iOS 17.1, j’ai Swap Processes on Cross-Site Navigation dans Settings -> Safari -> Advanced -> Feature Flags, et c’est activé par défaut
      Je me demande si c’est différent de Swap Processes on Cross-Site Window Open sur macOS

  • La phrase « iLeakage est une attaque assez difficile à mener jusqu’au bout et nécessite une connaissance avancée des attaques de canal auxiliaire basées sur le navigateur et de l’implémentation de Safari » est peut-être la raison pour laquelle Apple ne s’en préoccupe pas beaucoup

    • Cela donne l’impression que c’est tellement difficile à exécuter que c’est irréaliste en pratique, et que le risque réel est en fait proche de 0 %
      Le fait de lui avoir donné encore un surnom effrayant et même un nom de domaine ne paraît ni professionnel ni très crédible

  • Si cela concerne les appareils macOS ou iOS équipés de CPU Apple série A ou M, c’est-à-dire les iPhone/iPad récents et les portables ou desktops Apple depuis 2020, alors en tant qu’utilisateur d’un rare Intel Mac, j’ai l’impression de ne pas être concerné

    • Vous êtes probablement concerné aussi
      Seule la hiérarchie de cache diffère un peu, et il faudrait seulement quelques modifications mineures à la preuve de concept
    • Sur macOS, il suffit de ne pas utiliser Safari
      Sur iOS, il faut utiliser le Lockdown Mode, et c’est la seule manière d’utiliser un iPhone en sécurité
      Sans Lockdown Mode, un benchmark revient à peu près au même que lancer un benchmark CPU avec mitigations=off

  • Encore une bonne raison de permettre d’autres moteurs de navigateur sur les appareils iOS

    • La régulation de l’UE pourrait finir par y contraindre Apple

  • Si vous obtenez une erreur en exécutant la commande ci-dessous, donnez à Terminal l’autorisation Full Disk Access puis réessayez
    defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 1