Nous avons découvert un identifiant Firefox stable qui relie toutes les identités Tor privées d’un utilisateur

• Le seul ordre de retour de indexedDB.databases() permet de générer, dans les navigateurs basés sur Firefox, un identifiant stable qui persiste pendant toute la durée de vie du processus
• Cet identifiant est partagé au-delà du périmètre d’origine, si bien que des sites sans lien entre eux peuvent observer la même valeur dans un même runtime du navigateur et l’exploiter pour du suivi cross-origin
• Dans le mode de navigation privée de Firefox, l’identifiant persiste tant que le processus reste actif, même après la fermeture de toutes les fenêtres privées, et il continue aussi d’exister après New Identity dans Tor Browser
• La cause se trouve dans l’implémentation IndexedDB de Gecko, qui mappe les noms de bases de données privées vers des noms de fichiers fondés sur des UUID et expose ensuite le résultat sans tri
• Mozilla a déployé un correctif dans Firefox 150 et ESR 140.10.0 ; il est crucial, pour protéger la vie privée, que la conception n’expose pas vers l’extérieur l’ordre du stockage interne

---

Vue d’ensemble de la vulnérabilité

• Dans tous les navigateurs basés sur Firefox, il est possible d’extraire un identifiant persistant pendant la durée de vie du processus à partir de l’ordre des éléments renvoyés par indexedDB.databases()
  • En créant plusieurs bases IndexedDB puis en observant l’ordre de retour, un site web peut produire un identifiant unique et déterministe du processus de navigateur en cours d’exécution
  • Ce comportement apparaît à l’échelle du processus, et non de l’origine ; des sites sans rapport peuvent donc observer le même identifiant dans un même runtime du navigateur
• Dans le mode de navigation privée de Firefox, l’identifiant persiste tant que le processus Firefox continue de tourner, même après la fermeture de toutes les fenêtres privées
  • Dans Tor Browser, cet identifiant stable subsiste même après New Identity, qui est censé effacer les cookies et l’historique puis utiliser un nouveau circuit Tor
  • Cela entre en conflit avec l’attente selon laquelle l’activité ultérieure ne devrait pas pouvoir être reliée à l’activité précédente, et affaiblit la garantie de non-corrélation sur laquelle s’appuient les utilisateurs
• Une divulgation responsable a été menée auprès de Mozilla et du Tor Project
  • Mozilla a publié un correctif dans Firefox 150 et ESR 140.10.0
  • Le correctif est suivi dans Mozilla Bug 2024220 ; la cause se situe dans l’implémentation IndexedDB de Gecko et concerne donc aussi Tor Browser et d’autres navigateurs basés sur Firefox
• Le principe du correctif est simple
  • Le navigateur ne doit pas exposer à l’extérieur l’ordre du stockage interne à l’échelle du processus
  • Normaliser ou trier les résultats avant de les renvoyer permet de supprimer cette source d’entropie et d’empêcher son exploitation comme identifiant stable

Pourquoi c’est important

• Le mode de navigation privée et les navigateurs centrés sur la protection de la vie privée ont pour objectif de rendre plus difficile l’identification d’un utilisateur dans différents contextes
  • Attente générale 1 : en l’absence de stockage partagé ou de mécanisme d’identité explicite, des sites sans lien ne devraient pas pouvoir savoir s’ils interagissent avec la même instance du navigateur
  • Attente générale 2 : lorsqu’une session privée se termine, les informations qui lui sont associées devraient disparaître elles aussi
• Ce comportement brise ces deux attentes
  • Un site peut dériver un identifiant uniquement à partir du fonctionnement interne du stockage du navigateur, sans cookies, sans localStorage et sans canal cross-site explicite
  • L’ordre des noms de bases de données renvoyé par l’API fournit un signal d’identification à forte capacité
• Il y a aussi une leçon côté développement
  • Les vulnérabilités de confidentialité ne viennent pas uniquement d’un accès direct à des données identifiantes
  • Elles peuvent aussi résulter de la divulgation déterministe de détails d’implémentation internes
• Le point clé, côté sécurité produit
  • Même une API en apparence anodine peut devenir un vecteur de suivi intersites si elle fuit un état stable au niveau du processus

IndexedDB et indexedDB.databases()

• IndexedDB est une API navigateur de stockage structuré côté client
  • Les applications web l’utilisent pour le mode hors ligne, le cache, l’état de session et d’autres besoins de stockage local
  • Chaque origine peut créer une ou plusieurs bases de données nommées, avec des object stores et de grands volumes de données
• indexedDB.databases() renvoie les métadonnées des bases visibles pour l’origine courante
  • Les développeurs peuvent l’utiliser pour vérifier les bases existantes, déboguer l’usage du stockage ou gérer l’état d’une application
• Dans un modèle normal de protection de la vie privée, l’ordre de retour de cette API ne devrait pas, à lui seul, contenir d’information identifiante
  • Il faudrait une représentation neutre ou normalisée des métadonnées de base de données
  • Le vrai problème est que, dans les navigateurs basés sur Firefox, l’ordre de retour était loin d’être neutre

Comment indexedDB.databases() est devenu un identifiant stable

• En navigation privée sous Firefox, indexedDB.databases() renvoie les métadonnées dans un ordre dérivé de la structure de stockage interne, et non dans l’ordre de création des bases
  • L’implémentation concernée se trouve dans dom/indexedDB/ActorsParent.cpp
• En navigation privée, les noms de base ne sont pas utilisés directement comme identifiants disque
  • À la place, ils sont mappés vers une base de nom de fichier fondée sur un UUID via la table de hachage globale StorageDatabaseNameHashtable = nsTHashMap<nsString, nsString>
  • Ce mapping est réalisé dans GetDatabaseFilenameBase() à l’intérieur de OpenDatabaseOp::DoDatabaseWork()
• Quand aIsPrivate vaut true, le nom de base fourni par le site est remplacé par un UUID généré puis stocké dans la table globale StorageDatabaseNameHashtable
  • La clé utilise uniquement la chaîne du nom de base de données
  • Le mapping persiste pendant toute la durée de vie du QuotaClient d’IndexedDB
  • Il est partagé entre toutes les origines
  • Il n’est réinitialisé qu’au redémarrage complet de Firefox
• Lors d’un appel ultérieur à indexedDB.databases(), Firefox collecte les noms de fichiers des bases via QuotaClient::GetDatabaseFilenames(...) depuis GetDatabasesOp::DoDatabaseWork()
  • Les noms de base sont insérés dans un nsTHashSet
  • Aucun tri n’est effectué avant l’itération
• L’ordre final des résultats est déterminé par le parcours de la disposition interne des buckets du hash set
  • Comme le mapping UUID reste stable pendant toute la durée de vie du processus Firefox, l’ordre de retour reste lui aussi une fonction déterministe des UUID générés, du comportement de la fonction de hachage, de la capacité de la table et de l’historique d’insertion
  • Cet ordre persiste d’un onglet à l’autre et d’une fenêtre privée à l’autre, et n’est réinitialisé qu’au redémarrage complet du navigateur
  • Le mapping UUID comme le parcours du hash set relèvent du périmètre du processus, et non de celui de l’origine

Méthode de reproduction

• Un PoC simple suffit à démontrer le comportement
  • Deux origines différentes hébergent le même script
  • Chaque script crée un ensemble fixe de bases, appelle indexedDB.databases(), extrait l’ordre de retour et l’affiche
• Dans les builds affectés de Firefox en navigation privée et de Tor Browser, les deux origines observent la même permutation pendant toute la durée de vie du même processus navigateur
  • La permutation change au redémarrage du navigateur
• Exemple de sortie conceptuelle
  • Ordre de création : a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p
  • Ordre de retour : g,c,p,a,l,f,n,d,j,b,o,h,e,m,i,k
• Le point essentiel n’est pas la séquence exacte
  • Elle diffère de l’ordre de création initial
  • Le même ordre apparaît sur des origines sans lien entre elles
  • Il persiste après un rechargement, dans une nouvelle fenêtre privée, et même après fermeture de toutes les fenêtres privées
  • Un nouvel ordre n’est généré qu’après redémarrage complet du navigateur
  • Cela permet de vérifier directement une propriété indésirable du point de vue de la confidentialité

Impact sur la vie privée

• Cette vulnérabilité permet à la fois un suivi cross-origin et un suivi same-origin au sein d’un même runtime du navigateur

• Impact cross-origin

  • Des sites sans lien peuvent dériver indépendamment le même identifiant et en déduire qu’ils interagissent avec le même processus Firefox ou Tor Browser en cours d’exécution
  • Cela permet de corréler l’activité entre domaines sans cookies ni autre stockage partagé

• Impact same-origin

  • Dans la navigation privée de Firefox, l’identifiant persiste tant que le processus Firefox continue de tourner, même après la fermeture de toutes les fenêtres privées
  • Un site peut donc reconnaître une visite ultérieure qui semble pourtant appartenir à une nouvelle session privée
  • Dans Tor Browser, l’identifiant stable neutralise de fait l’isolation fournie par New Identity tant que le même processus navigateur reste actif
  • Il autorise un lien entre des sessions qui devraient être totalement séparées

• Pourquoi c’est particulièrement grave dans Tor Browser

  • Tor Browser est conçu pour réduire les possibilités de corrélation intersites et minimiser l’identification au niveau de l’instance du navigateur
  • Un identifiant stable qui persiste pendant la durée de vie du processus entre directement en contradiction avec cet objectif de conception
  • Même s’il ne survit pas à un redémarrage complet, cela suffit à affaiblir significativement la non-corrélation lors d’un usage actif

Entropie et capacité de fingerprinting

• Ce signal n’est pas seulement stable, il a aussi une forte capacité
  • Si un site contrôle N noms de base de données, le nombre de permutations observables est N!
  • L’entropie théorique est log2(N!)
• Avec 16 noms contrôlables, l’espace théorique atteint environ 44 bits
  • C’est suffisant pour distinguer les instances simultanées de navigateur dans des conditions réelles
• Le nombre réel de permutations atteignables peut être un peu plus faible en raison du fonctionnement interne de la table de hachage
  • Mais cela ne change pas le point essentiel du point de vue sécurité
  • L’ordre exposé fournit toujours assez d’entropie pour agir comme un identifiant fort

Comment corriger

• Le bon correctif consiste à cesser d’exposer l’entropie dérivée de la disposition interne du stockage
  • La mesure la plus propre est de renvoyer les résultats dans un ordre canonique, par exemple un tri lexicographique
  • Cela préserve l’utilité de l’API pour les développeurs tout en supprimant le signal de fingerprinting
• Une randomisation de la sortie à chaque appel pourrait aussi masquer un ordre stable
  • Mais le tri est une option plus simple, plus prévisible et plus facile à comprendre pour les développeurs
• Conditions d’un correctif idéal du point de vue de l’ingénierie sécurité
  • Faible complexité conceptuelle
  • Risque minimal de compatibilité
  • Suppression directe de la fuite de confidentialité

Divulgation responsable

• Une divulgation responsable a été menée auprès de Mozilla et du Tor Project
  • Mozilla a déployé un correctif dans Firefox 150 et ESR 140.10.0
  • Le patch est suivi dans Mozilla Bug 2024220
• L’origine du comportement se trouve dans l’implémentation IndexedDB de Gecko
  • Les navigateurs dérivés de Gecko, dont Tor Browser, sont donc concernés s’ils n’ont pas leur propre mesure d’atténuation

Conception orientée confidentialité

• Même de petits détails d’implémentation peuvent déboucher sur de vrais problèmes de confidentialité
  • Des sites sans lien peuvent corréler l’activité au-delà des origines pendant un même runtime du navigateur
  • L’identifiant persiste plus longtemps que ne l’attend l’utilisateur, ce qui affaiblit les frontières entre sessions privées
• Le point positif est que la correction est simple et efficace
  • Normaliser la sortie avant de la renvoyer permet d’éliminer cette source d’entropie
  • Les frontières de confidentialité attendues peuvent ainsi être restaurées
• Il s’agit d’un type de vulnérabilité facile à manquer, mais à fort impact, qui mérite une attention particulière lors de la conception de fonctionnalités sensibles à la vie privée