Les pop-ups d’autorisation de macOS sont-ils vraiment fiables ?

• CVE-2025-31250 est une vulnérabilité qui rendait difficile de faire confiance aux pop-ups de consentement TCC de macOS, car elle permettait d’afficher une application à l’écran différente de celle qui recevait réellement l’autorisation
• Le problème se situait dans le traitement de TCCAccessRequestIndirect par tccd : target_path servait au nom de l’application affiché dans le pop-up, tandis que target_identifier servait à l’identifiant de l’application qui obtenait effectivement l’autorisation
• Contrairement aux contournements précédents, il n’était pas nécessaire d’utiliser une fausse application, un raccourci Dock ou d’inciter l’utilisateur à cliquer ; si l’utilisateur cliquait sur Allow dans un pop-up usurpé, l’attaque pouvait réussir
• Apple a corrigé le problème dans macOS Sequoia 15.5, mais a confirmé que Ventura 13.7.6 et Sonoma 14.7.6, publiés le même jour, n’étaient pas corrigés et qu’aucun correctif n’était prévu pour les versions antérieures
• Un attaquant peut tenter une usurpation de pop-up d’autorisation au moment où des applications comme FaceTime, Voice Memos ou System Settings s’ouvrent, ce qui crée un risque que l’utilisateur se trompe sur l’application qui reçoit réellement l’autorisation

---

Fonctionnement clé de CVE-2025-31250

• CVE-2025-31250 est une vulnérabilité qui permettait de faire diverger l’application affichée dans le pop-up d’autorisation TCC de macOS et celle qui recevait réellement l’autorisation
• Avant le correctif, la configuration suivante était possible
  • Application A demandait à macOS d’afficher un pop-up de consentement
  • Le pop-up semblait provenir de l’application B
  • Le résultat du consentement de l’utilisateur était appliqué à l’application C
• Les trois applications pouvaient être différentes, même si dans un usage normal il est probable qu’il s’agisse de la même application
• Le problème central était l’absence de vérification suffisante entre l’application affichée dans le pop-up et celle qui recevait effectivement l’autorisation

Portée du correctif et rectificatifs

• Contrairement à l’explication initiale, le correctif s’applique uniquement à macOS Sequoia 15.5
• macOS Ventura 13.7.6 et macOS Sonoma 14.7.6, publiés le même jour, ne sont pas corrigés
• Lors de la compilation et de l’exécution du PoC dans une machine virtuelle Sonoma 14.7.6, la vulnérabilité fonctionnait toujours
• Apple Product Security a modifié l’état du signalement en “We’ve addressed the issue in all planned releases.”, puis a confirmé qu’aucun correctif n’était prévu pour cette vulnérabilité sur Ventura et Sonoma
• En conséquence, Ventura et Sonoma restent vulnérables à ce problème

Là où TCC rencontre Apple Events

• TCC est le système central d’autorisations des systèmes Apple, qui fonctionne en interne via le démon tccd et le framework privé TCC
• Les développeurs n’appellent pas directement cette API privée, mais les API publiques invoquent en interne les fonctions TCC lorsque nécessaire
• tccd reçoit les messages via l’API XPC d’Apple
• Avant le correctif, une application capable d’envoyer des messages XPC à tccd pouvait envoyer un message manipulé afin de dissocier l’application affichée dans le pop-up de celle qui recevait réellement l’autorisation

Apple Events et le modèle de données TCC

• Apple Events est le mécanisme de communication interprocessus de macOS, aujourd’hui utilisé principalement pour l’automatisation
• L’automatisation via Apple Events peut être scriptée à l’aide de l’Open Scripting Architecture d’Apple
  • Le langage le plus représentatif est AppleScript
  • JavaScript peut aussi être utilisé
• Depuis macOS Mojave 10.14, une application doit obtenir le consentement de l’utilisateur via TCC pour envoyer des Apple Events
• Les décisions de consentement TCC sont stockées dans la base SQLite Application Support/com.apple.TCC/TCC.db sous le dossier personnel de l’utilisateur
• Une entrée TCC classique contient l’application qui demande, le service demandé et le résultat du consentement de l’utilisateur
• Apple Events doit restreindre les autorisations par application destinataire, d’où l’usage de la colonne indirect object
  • Cette colonne contient l’identifiant de l’application qui recevra les Apple Events
  • En dehors d’Apple Events, le service FileProviderDomain utilise aussi cette colonne

Structure du message XPC vulnérable

• Le problème venait d’un bug logique dans la fonction TCCAccessRequestIndirect
• Cette fonction traite les demandes d’accès qui doivent utiliser la colonne indirect object de TCC.db
• Le cœur du PoC consiste à séparer deux champs lorsque target_prompt vaut 2
  • target_path : utilisé pour obtenir le nom de l’application à afficher dans le pop-up d’autorisation graphique
  • target_identifier : utilisé comme bundle ID de l’application qui est réellement inscrite dans la base de données et reçoit l’autorisation
• Bien que TCCAccessRequestIndirect soit une fonction prévue pour les indirect objects, elle pouvait aussi être utilisée pour plusieurs services TCC n’utilisant pas cette colonne en passant une chaîne vide comme indirect object
• Ce bug n’existait pas dans les autres fonctions de demande d’accès

Conditions et limites d’exploitation

• L’exploitation de la vulnérabilité ne réussit que si l’utilisateur clique sur Allow dans le pop-up d’autorisation
• Les services TCC utilisables étaient limités, mais incluaient des services importants comme le microphone et la caméra
• Il était aussi possible d’usurper des pop-ups d’autorisation d’accès à certains répertoires, mais leur intérêt était plus faible en raison des couches de sécurité supplémentaires autour des fichiers
• Une application malveillante pouvait aussi faire appliquer l’autorisation non pas à elle-même, mais à une autre application
  • C’est une piste exploitable si l’attaquant peut contrôler une autre application qui, elle aussi, a besoin d’autorisations TCC

Tromperie fondée sur le timing du pop-up

• Si un pop-up d’autorisation apparaît au hasard, l’utilisateur est plus susceptible de se méfier et de cliquer sur Don’t Allow
• Les applications macOS peuvent consulter la liste des applications en cours d’exécution ainsi que l’application actuellement au premier plan
  • Vérifier les applications en cours : NSWorkspace runningApplications
  • Vérifier l’application au premier plan : NSWorkspace frontmostApplication
• Une application malveillante peut attendre qu’une application précise soit lancée ou passe au premier plan, puis afficher un pop-up d’autorisation usurpé en utilisant son nom
• Par exemple, il est possible d’usurper un pop-up d’autorisation pour la caméra au lancement de FaceTime, ou pour le microphone au lancement de Voice Memos
• L’utilisateur peut alors prendre le pop-up apparu juste après l’ouverture ou le changement d’application pour une demande d’autorisation légitime de cette application

Lien avec les anciens contournements de TCC

• Par le passé, il était possible de contourner TCC parce que tccd déterminait le dossier personnel de l’utilisateur à partir de la variable d’environnement HOME, ce qui permettait d’utiliser un faux dossier personnel et une fausse base TCC.db
• Ce problème a été corrigé dans une mise à jour de mi-juillet 2020, après quoi tccd a commencé à récupérer le dossier personnel depuis le répertoire d’informations utilisateur du système d’exploitation
• Par la suite, d’autres contournements exploitant la modification du dossier personnel de l’utilisateur ont encore été observés
  • Wojciech Reguła a publié CVE-2020-27937, qui exploitait le système de plugins de l’éditeur d’informations utilisateur GUI de macOS
  • L’équipe Microsoft Threat Intelligence a publié le contournement powerdir utilisant des commandes d’import/export
• Modifier le dossier personnel de l’utilisateur nécessite généralement deux éléments
  • les privilèges root
  • le consentement de l’utilisateur pour certains services TCC
• CVE-2025-31250 ne contourne pas l’exigence des privilèges root, mais peut pousser l’utilisateur à accorder le consentement TCC requis via un pop-up usurpé
• Si une application malveillante trompe l’utilisateur pour obtenir son consentement puis parvient à élever ses privilèges jusqu’à root, elle peut alors modifier le répertoire d’informations utilisateur et y placer une fausse base TCC.db
• REG.db suit les bases TCC.db valides, mais TCC comporte une fonction permettant à une application d’ajouter des entrées à REG.db, ce qui permet d’ajouter le chemin d’une base TCC.db implantée

Les limites de la gestion des autorisations visible par l’utilisateur

• TCC est le système qui fonctionne derrière le panneau Privacy & Security de System Settings
• Les décisions de consentement liées à Apple Events apparaissent dans la section Automation
• Dans le panneau Privacy & Security, l’utilisateur peut consulter les autorisations qu’il a accordées et, dans de nombreux cas, en révoquer certaines
• Cependant, lorsqu’un attaquant amenait l’utilisateur à autoriser des droits Apple Events par tromperie, cette décision n’apparaissait pas dans System Settings
• L’utilisateur peut révoquer les autorisations via l’outil CLI tccutil, mais cet outil est peu documenté et la plupart des utilisateurs le connaissent mal
  • La documentation Apple disponible se limite notamment à une ancienne Technical Q&A et à une page de formation IT

Endpoint Security et possibilités de détection

• Le framework Endpoint Security d’Apple a récemment commencé à prendre en charge la surveillance des modifications de la base TCC
• L’article d’Objective-See qui traite ce changement : Endpoint Security TCC database monitoring
• Si cette fonctionnalité se comporte comme prévu, les applications qui utilisent ce framework peuvent avertir l’utilisateur a posteriori de l’application à laquelle une autorisation a réellement été accordée
• Cela dit, cette possibilité de détection n’avait une portée directe que pendant la courte période comprise entre l’ajout de l’événement Endpoint Security par Apple et la publication du correctif de la vulnérabilité

La méthode de correction d’Apple

• L’analyse du binaire tccd de macOS Sequoia 15.5 montre que le correctif final est plus complexe que les premières estimations
• Après correctif, il n’est plus possible d’usurper les pop-ups TCC de la même manière
• Il semble aussi que l’usage de TCCAccessRequestIndirect pour d’autres services TCC, en y passant une chaîne vide comme indirect object, soit désormais restreint
• Les messages de forme vulnérable semblent maintenant être silencieusement ignorés par tccd, sans produire d’effet observable
• Les vérifications simples donnent l’impression d’un bon correctif, mais une analyse supplémentaire est nécessaire pour comprendre entièrement le comportement

Déroulé du signalement jusqu’au correctif

• Cette vulnérabilité était le deuxième bug signalé à Apple par l’auteur, et le cas corrigé ayant mis le plus de temps à être patché parmi ses signalements
• Le processus de signalement a inclus le rapport initial, une demande d’explications supplémentaires par Apple Product Security, le partage d’une chaîne potentielle de contournement complet de TCC, des mises à jour des tests du PoC, la confirmation de la reproductibilité et plusieurs demandes d’avancement
• Le correctif simple proposé consistait à vérifier que les deux champs pointaient vers la même application
• Apple a répondu à plusieurs reprises qu’une enquête était en cours, puis a demandé le nom à faire apparaître dans les crédits avant de publier le correctif
• Le nom donné à la vulnérabilité est “TCC, Who?”