- Le système d’autorisations TCC de macOS pouvait, à cause d’une faille, afficher à l’utilisateur des pop-ups de demande d’autorisation trompeurs
- Cette vulnérabilité, enregistrée sous la référence CVE-2025-31250, faisait que le consentement de l’utilisateur s’appliquait à une autre application
- Il existait une possibilité d’attaque par usurpation dans laquelle une application malveillante affichait la fenêtre de demande d’autorisation sous le nom d’une application de confiance afin d’obtenir le consentement de l’utilisateur
- Le problème a été corrigé dans macOS Sequoia 15.5 d’Apple, mais il reste non corrigé sur d’autres versions
- En plus de la difficulté à vérifier et révoquer l’historique des autorisations accordées, des vulnérabilités similaires pourraient encore apparaître à l’avenir
Correctif important
- Cette vulnérabilité a été corrigée dans macOS Sequoia 15.5, mais elle n’est toujours pas corrigée dans macOS Ventura 13.7.6 ni macOS Sonoma 14.7.6
- Il est confirmé que l’auteur du signalement n’est pas mentionné dans les notes de publication de sécurité d’Apple
- Des tests directs sur une machine virtuelle exécutant macOS Sonoma 14.7.6 ont permis de vérifier que la vulnérabilité reste exploitable
- On estime que Ventura 13.7.6 est dans le même état
- Une réponse officielle d’Apple est en attente
Introduction
- La vulnérabilité CVE-2025-31250 permettait à une application d’afficher de faux pop-ups de demande d’autorisation sur macOS
- Si « Application A » affichait le pop-up, celui-ci pouvait indiquer « Application B », tandis que le consentement de l’utilisateur était en réalité appliqué à « Application C »
- En temps normal, ces trois applications sont identiques, mais cette faille permettait de désigner des applications différentes
- Cela pose un problème majeur pour la fiabilité des fenêtres de demande d’autorisation
- Des méthodes d’« usurpation » similaires avaient déjà été présentées, notamment par HackTricks, mais cette vulnérabilité utilisait une approche plus simple
TCC
- TCC est le système central de gestion des autorisations intégré aux OS d’Apple
- Les autorisations sont gérées en envoyant des messages au démon
tccd, tandis que l’API publique appelle des fonctions du framework TCC privé
- Le démon communique via l’API XPC d’Apple
- Avant la correction de cette vulnérabilité, il était possible, en envoyant des messages arbitraires, de dissocier l’application affichée dans le pop-up de demande d’autorisation de celle qui recevait réellement l’autorisation
- Pour comprendre l’origine de cette faille, il faut se pencher sur Apple Events
Apple Events
Que sont les Apple Events ?
- Les Apple Events sont le mécanisme de communication interprocessus entre applications sur macOS
- Il s’agit d’un protocole hérité de l’époque d’ouvrages de référence publiés dès 1993
- Après l’introduction de macOS X, il a été repensé pour s’adapter à la nouvelle architecture et est resté en usage
- Aujourd’hui, il sert surtout à l’automatisation (Automation), avec des scripts en AppleScript et en JavaScript
- Il est comparable à Script Host sous Windows et a aussi déjà été utilisé comme vecteur de malware
Apple Events et TCC
- Depuis macOS Mojave 10.14, l’envoi d’Apple Events nécessite le consentement de l’utilisateur
- La base de données des autorisations de TCC (
TCC.db) enregistre l’application demandeuse, le service et la réponse de consentement
- Comme les Apple Events doivent être gérés séparément pour chaque application destinataire, la colonne indirect object de
TCC.db est utilisée
- La fonction TCCAccessRequestIndirect du démon TCC traite les messages exploitant cette colonne
- Une erreur logique dans cette fonction permettait d’indiquer une application à l’utilisateur et d’en autoriser une autre en réalité
Preuve de concept (Proof-of-Concept)
- L’exemple de code Swift manipule le message de demande d’autorisation comme suit
- Il expose dans le pop-up de consentement le nom de l’application située au chemin « spoofedBundle »
- Il désigne l’identifiant de bundle de « actualBundle » comme véritable bénéficiaire de l’autorisation
- En conséquence, l’utilisateur croit qu’une application de confiance demande l’autorisation, mais l’autorisation réelle est accordée à l’application malveillante
- Même en laissant la valeur de
indirect_object vide, il était possible de viser plusieurs services TCC
- Cela entraînait un effondrement de la fiabilité du consentement utilisateur pour les autorisations
- Un attaquant pouvait tromper l’utilisateur et obtenir des autorisations pour une application arbitraire
Exploitation de la vulnérabilité
Limites et particularités
- Seuls certains services TCC sont vulnérables à l’attaque, mais des services majeurs comme Microphone et Camera sont concernés
- Pour les autorisations de fichiers/dossiers, l’impact est plus limité en raison de protections supplémentaires
- Une application malveillante peut s’en servir avec des techniques d’ingénierie sociale pour amener l’utilisateur à consentir à la place d’une autre application qui aurait normalement besoin de l’autorisation
L’importance du timing
- Le moment où le pop-up apparaît est crucial
- Une application malveillante peut détecter les applications en cours d’exécution ainsi que celle qui est au premier plan, puis afficher le pop-up au moment opportun pour semer la confusion
- Par exemple, si FaceTime est lancé, afficher un pop-up d’autorisation pour la caméra peut amener l’utilisateur à le prendre pour une demande légitime
- Un scénario similaire est possible en usurpant une demande d’autorisation du microphone lors du lancement de Voice Memos
- En ciblant un timing cohérent avec le contexte, le taux de réussite augmente
Retour sur d’anciennes vulnérabilités
- D’autres vulnérabilités exploitaient le fait que le chemin de
TCC.db est déterminé en fonction du dossier personnel de l’utilisateur
- Jusqu’en 2020, il suffisait de modifier la variable d’environnement
HOME pour utiliser une fausse base TCC.db ($HOMERun)
- Même après le correctif, bien que les droits root et le consentement utilisateur soient nécessaires, il reste possible de contourner les autorisations en combinant cela avec une usurpation par ingénierie sociale
- Une application malveillante peut, après avoir obtenu le consentement de l’utilisateur, modifier le dossier personnel et ajouter une base de données enregistrée afin de contourner le système via une fausse
TCC.db
- Des tests réels ont confirmé que cette méthode pouvait effectivement influencer le fonctionnement de TCC
Chronologie
1.
- 2024-05-02 : signalement initial à Apple Product Security, puis envoi de messages complémentaires
2.
- 2024-05-03 : demande d’explications supplémentaires par Apple Product Security, puis réponse envoyée
- Le même jour, découverte d’une possibilité de contournement complet de TCC et nouveau signalement à Apple
3.
- 2024-05-04 : poursuite des tests du PoC et envoi d’informations complémentaires
4.
- 2024-05-06 : remerciements d’Apple Product Security pour les informations fournies
5.
- Par la suite, l’état du correctif a été demandé régulièrement et son suivi vérifié ; de 2024-06 à 2025-02, des échanges continus ont eu lieu avec Apple, mais le problème est resté non corrigé pendant longtemps
6.
- 2025-05-12 : publication du correctif pour ce bug
Conclusion
Autres points
- TCC apparaît dans la rubrique Privacy & Security de l’application System Settings (anciennement Security & Privacy), ainsi que dans la section Automation correspondante
- Cependant, l’historique des consentements liés à Apple Events n’est pas visible dans l’interface graphique, ce qui rend leur révocation difficile pour l’utilisateur
- Il est possible de les révoquer via l’outil CLI
tccutil, mais celui-ci est très peu connu
- Apple a récemment ajouté au framework Endpoint Security une fonction de surveillance des modifications de la base de données TCC
- Si elle fonctionne comme prévu, elle pourrait aider à prévenir les abus en informant l’utilisateur de l’application qui a réellement reçu l’autorisation
Le correctif d’Apple
- Le contenu exact du correctif est complexe, mais en pratique
tccd a été modifié pour ignorer silencieusement les messages externes dont l’indirect object est arbitrairement défini
- Les vérifications de fonctionnement ont confirmé qu’il n’est désormais plus possible d’effectuer cette usurpation
- Si le correctif s’avère incomplet, des mesures supplémentaires pourraient être nécessaires dans une future mise à jour
Dernières réflexions
- Cette vulnérabilité a été baptisée « TCC, Who? »
- Du point de vue d’un chercheur en sécurité, elle rappelle l’importance cruciale de la fiabilité des systèmes d’autorisation
- Elle laisse entendre que des failles similaires pourraient encore être découvertes à l’avenir
- Elle suggère que les utilisateurs ne devraient pas accorder une confiance aveugle aux pop-ups d’autorisation de macOS
1 commentaires
Avis Hacker News
En pariant sur la faible probabilité que quelqu’un chez Apple lise cet article, je répète ce que j’ai toujours envie de demander : j’aimerais qu’Apple arrête d’afficher au hasard, à n’importe quel moment, des boîtes de dialogue disant « saisissez maintenant le mot de passe de l’admin local », simplement parce que l’ordinateur a soudain envie de faire une mise à jour ou d’installer quelque chose. Avec un minimum de compétences techniques, il est très facile de fabriquer sur le web une fausse fenêtre quasiment identique, et à part peut-être les 20 % d’utilisateurs les plus techniques, la plupart ne penseront même pas à vérifier si c’est authentique ou juste un faux généré dans le navigateur. Pour éviter ce problème à la racine, il faudrait habituer les utilisateurs au fait qu’un logiciel normal ne fait pas surgir soudainement une boîte de mot de passe sans aucun avertissement en plein milieu d’une tâche ; or l’interface de sécurité actuelle de macOS fait exactement l’inverse. Il faudrait la remplacer par quelque chose comme une icône colorée et très visible dans la barre de menus, ou un écran de sécurité furtif comme sous Windows. Le design actuel de l’interface est vraiment problématique
Ce que je déteste le plus avec ces fenêtres, c’est qu’on ne sait jamais pourquoi on nous demande ça, ce qui se passera si on refuse, ni ce qu’il faudra faire plus tard si on veut modifier ce réglage. Quand une app dit « ouvrez le panneau Réglages et accordez l’autorisation XXX », on voit clairement l’app concernée, la permission et l’interrupteur à activer ; la popup de mot de passe n’offre rien de cette UX. C’est pour ça que je n’aime pas beaucoup le concept de « capabilities » : l’UX est trop mauvaise et c’est presque inévitable. On finirait avec des trucs du genre « pour utiliser pleinement l’application, autorisez <root my computer> », parce que dès qu’on laisse le fournisseur écrire le message, ça finit toujours comme ça. UX totalement inutile
Si macOS affichait encore les fenêtres modales attachées aux fenêtres elles-mêmes, ce serait peut-être un peu moins grave. Ce ne serait pas une solution complète, mais ce serait mieux. Quand la modale recouvre simplement la barre d’outils comme aujourd’hui, cela donne immédiatement l’impression qu’elle fait « partie de l’app ». Steve Jobs insistait déjà, lors de la démo d’Aqua, sur le fait que ces modales flottantes dégradaient l’utilisabilité, et j’ai l’impression qu’on en est là à cause de l’obsession étrange d’Apple à vouloir mettre une UI mobile sur tous les écrans
Les membres de ma famille qui ne sont pas techniques ne font même pas la différence entre le mot de passe local de la machine et le mot de passe iCloud/Apple ID ; au final ils essaient tout jusqu’à ce que quelque chose marche (et c’est bien parce que l’UI est floue et incohérente). Apple se moquait autrefois de l’UAC de Vista, mais aujourd’hui ils ont eux aussi accumulé les notifications soudaines et les interfaces bâclées
Je suis passé récemment de Linux à Mac, et ces popups aléatoires de mot de passe root m’ont vraiment dérouté. Il n’y avait aucune explication sur l’app ou la commande qui demandait les privilèges root, ni sur la raison. J’en ai autorisé quelques-unes, puis j’ai fini par tout refuser. Depuis, les popups ont cessé. Mais je ne sais toujours absolument pas à quoi elles servaient, ni pourquoi elles ne s’affichent plus
J’aimerais recommander une nouvelle fois ce grand classique : The Line of Death https://textslashplain.com/2017/01/14/the-line-of-death/
Les popups de passkey sont une erreur de sécurité particulièrement grave, car on ne peut absolument pas les distinguer des popups JavaScript
Dans ce genre de situation, le lecteur d’empreintes intégré est vraiment appréciable. En temps normal, j’utilise le portable fermé avec un moniteur externe, mais quand une authentification système est requise, je l’ouvre exprès pour valider avec mon empreinte
Twist : en fait, cette boîte de dialogue n’a jamais existé ! Vous vous êtes déjà fait avoir
Je voudrais profiter du commentaire actuellement le plus populaire pour signaler une information : cet article a une mise à jour importante : https://news.ycombinator.com/item?id=43969087
Je me demande quel est exactement le modèle de menace quand on clique sur une fausse popup. Si ce n’est pas vraiment le système, est-ce que ce n’est pas juste une manipulation sans effet ?
Quand on se connecte à iCloud, une popup demande le mot de passe local de l’ordinateur, et si on le saisit, ce mot de passe est envoyé vers les serveurs iCloud
J’ai récemment découvert qu’il fallait installer les apps Mac dans le dossier Applications de mon répertoire personnel (~/Applications) plutôt que dans le dossier Applications système, évidemment seulement si l’ordinateur n’est utilisé que par une seule personne. Si je me mets moi-même en utilisateur non administrateur et que j’installe les apps dans ~/Applications, je n’ai plus ces demandes agaçantes de droits pour les mises à jour. La plupart des apps se mettent à jour toutes seules sans droits admin. Les exceptions sont les apps comme Tailscale qui nécessitent une intégration avec l’OS. C’est une approche recommandée par une app nommée Pareto Security
Malheureusement, la quasi-totalité des développeurs d’apps ne connaissent pas cette méthode, et beaucoup d’apps exigent carrément d’être installées dans /Applications, au point de ne pas fonctionner ailleurs
Installer les apps dans ~/Applications permet les mises à jour automatiques sans root, mais en contrepartie du code douteux peut aussi être remplacé facilement sans privilèges root
J’utilise macOS 15.4.1 et le dossier ~/Applications n’existe même pas
Je trouve ça fascinant ! J’ai besoin d’un compte admin au quotidien, donc cette méthode me conviendrait mal, mais pour les personnes concernées c’est une très bonne astuce
Il faut apporter une correction importante au contenu de cet article. Il était indiqué auparavant que le CVE avait été corrigé dans macOS Sequoia 15.5, mais en réalité le correctif n’a pas été appliqué à macOS Ventura 13.7.6 ni à macOS Sonoma 14.7.6, publiés le même jour. J’ai écrit cela en supposant qu’Apple avait évidemment intégré le patch dans toutes les versions, puis j’ai vérifié les notes de publication de sécurité et constaté que mon nom n’apparaissait pas dans les deux autres versions ; j’ai donc contacté Apple directement. Je n’ai pas encore reçu de réponse. Pour vérifier moi-même, j’ai lancé une VM, appliqué le patch à macOS Sonoma 14.7.6 et exécuté mon PoC : la vulnérabilité fonctionne toujours. Je pense que Ventura 13.7.6 est probablement dans le même cas. Je ne comprends pas pourquoi Apple n’a pas inclus le correctif. Je mettrai l’article à jour s’il y a davantage d’informations
Le système TCC de macOS a la réputation d’être un mécanisme solide de protection de la vie privée, mais c’est assez amer de se rappeler qu’en pratique il peut être contourné très facilement avec une simple entrée en base de données. Les popups de consentement utilisateur ne pèsent pas lourd face à une simple manipulation de base, surtout dans un environnement de développement où SIP est désactivé. Au fond, c’est une question de confiance. On peut se demander si le consentement au niveau de l’UX constitue encore une vraie frontière de sécurité. On dépend de plus en plus des popups de permissions au niveau de l’OS, mais si cette frontière n’est en réalité qu’une illusion — ou une simple mise en scène — il faut peut-être repenser la manière de maintenir concrètement cette confiance plutôt que de seulement la « montrer »
Je me souviens qu’à l’époque des pubs « I'm a Mac and I'm a PC », ce genre de choses sous Vista était tourné en dérision. Et pourtant aujourd’hui, mon Mac est pire que Vista. C’est vraiment agaçant
Le compromis entre sécurité et extensibilité semble être une fatalité. Cela dit, le niveau de base a aussi évolué. Au moins, macOS n’est pas envahi de processus malveillants comme l’était l’ancien Windows. Ou alors j’ai simplement eu de la chance et j’ai été prudent
C’est juste par curiosité : qu’est-ce qui vous a particulièrement agacé au point de le vivre comme ça ?
Le système TCC a été bancal dès le départ. Il ne fait qu’ennuyer les développeurs légitimes et bombarder les utilisateurs de popups de permissions, tandis que les apps malveillantes contournent sans cesse cette « sécurité (de façade) » par divers moyens, comme les chercheurs le montrent régulièrement. Je ne suis pas chercheur en sécurité, mais en tant que développeur Mac, j’ai moi aussi trouvé plusieurs méthodes de contournement. J’en viens même à me demander si les ingénieurs Apple comprennent vraiment les technologies qu’ils utilisent. Je me demande combien il reste encore de développeurs Mac « historiques »
J’utilise un Mac d’entreprise et j’ai régulièrement une alerte disant « Slack tente d’installer un nouvel outil auxiliaire ». Je n’ai aucune idée de ce que c’est ni de pourquoi ça apparaît. J’ai demandé à l’équipe IT, et ils ne savaient pas comment le vérifier. Je me dis souvent que ça pourrait être exploité abusivement, parce que cela continue à demander le mot de passe, et même si j’appuie toujours sur Annuler, ça revient sans cesse
Cette boîte de dialogue vient du framework System Management. C’est le processus par lequel Slack installe un helper tool avec privilèges élevés afin de pouvoir se mettre à jour tout seul, quel que soit son emplacement d’installation et quel que soit l’utilisateur qui l’a installé
Chaque fois qu’une popup de ce type apparaît, je n’ai aucun moyen de savoir quelles informations regarder pour décider si je dois autoriser ou refuser, donc je finis toujours par annuler
J’utilise Slack comme web app (mais dans une fenêtre dédiée, pas dans le navigateur) https://support.apple.com/en-us/104996 Discord peut aussi être utilisé de cette façon. À l’usage, c’est nettement plus agréable qu’une app Electron. Pour la plupart des apps Electron, cette approche est préférable
Je n’ai jamais vu moi-même la popup « helper tool », mais je ne comprends pas pourquoi une simple app de messagerie comme Slack aurait besoin de ce type de privilèges. Ce serait peut-être utile de demander au support Slack (et d’espérer obtenir une vraie réponse correcte)
Comme pour les apps qui exigent un mot de passe — par exemple des binaires sous Linux qui ne s’exécutent qu’en root — il y a clairement un potentiel d’abus. Au final, tout repose sur la confiance que vous accordez au développeur et sur l’authenticité de l’app. Le jour où Apple empêchera totalement les apps tierces d’obtenir des droits root, le Mac deviendra complètement fermé, et cet endroit (HN) débordera de commentaires indignés. En conclusion, il est important de garder une « bonne méfiance » et de ne pas accorder les droits root à des apps comme Slack quand leur nécessité n’est pas évidente
Le popup vole de force le focus de saisie, si bien que le texte qu’on était en train d’écrire dans un message se met soudain à partir dans le champ de mot de passe. C’est une expérience extrêmement pénible
Les popups s’accumulent avec le temps. Quand j’allume l’ordinateur après le week-end, elles se répètent sans arrêt, et je finis simplement par quitter Slack. Ça dure depuis un an. Je ne sais pas comment retirer cette permission à Slack, et ça donne une impression un peu malveillante
Ce genre d’outils de blocage « de sécurité » est vraiment idiot. En fait, cela entraîne les gens à devenir plus stupides. Ce qui est authentique aujourd’hui ne le sera peut-être pas demain. Ma banque m’appelle régulièrement pour me demander des informations personnelles au nom de la « protection d’identité », et tous ces dispositifs finissent par former les gens à donner leurs données privées à des inconnus
Je ne suis pas développeur macOS, mais je me suis demandé si n’importe quelle app — y compris malveillante — pouvait imiter le style des fenêtres popup système pour voler le mot de passe utilisateur
VSCode affiche la même popup sur le Mac fourni par mon entreprise. Ça fait des années que je l’ignore simplement
Avec toutes les apps basées sur Electron, ce popup apparaît dès qu’on utilise plusieurs comptes utilisateur OS
nordVPN a exactement le même comportement
Il a fallu une année entière à Apple pour publier un correctif. Ça paraît extrêmement long. <i>2024-05-04 plusieurs messages de mise à jour ont été publiés, les tests du PoC se poursuivent</i> <i>2025-05-12 le correctif a été publié</i>
Adobe Creative Cloud continue d’exécuter plusieurs processus en arrière-plan même quand l’exécution en arrière-plan a été explicitement désactivée dans les réglages du système d’exploitation
J’aime beaucoup les recherches de cette personne, et je trouve ses présentations excellentes