Fonctionnalités de sécurité de l’iOS moderne : analyse approfondie de SPTM, TXM et Exclaves
(arxiv.org)- Le noyau XNU des systèmes d’exploitation d’Apple fournissait jusqu’ici, dans les faits, un domaine de confiance unique
- Récemment, la séparation de l’architecture du noyau et sa micro-noyautisation ont amorcé une évolution visant à réduire l’impact des vulnérabilités de sécurité
- Avec l’introduction en 2023 du Secure Page Table Monitor (SPTM), des fonctions critiques ont été isolées et une nouvelle structure de domaines de confiance a émergé
- Des mécanismes de sécurité récents comme Exclaves et le Trusted Execution Monitor (TXM) sont implémentés sur la base du SPTM
- Ces améliorations structurelles font qu’une compromission du noyau n’entraîne plus immédiatement une perte de confiance à l’échelle de tout le système
Vue d’ensemble
Le noyau XNU, cœur des systèmes d’exploitation d’Apple, est souvent présenté comme un noyau hybride, mais il fonctionne en réalité sous une forme proche d’une structure monolithique où l’ensemble des fonctions système est concentré dans une seule zone de confiance privilégiée. En conséquence, lorsqu’un noyau est compromis, l’ensemble du système est immédiatement exposé à une menace grave. Récemment, Apple a fait évoluer son noyau vers une plus grande segmentation et une conception plus proche d’un microkernel, en déplaçant par exemple hors de l’espace noyau certaines fonctions critiques liées à la manipulation des tables de pages ou à la cryptographie.
Motivations principales et orientation de la recherche
- La nécessité d’améliorer la structure du noyau pour renforcer la sécurité devient plus évidente
- L’objectif est de minimiser l’impact global sur le système en cas d’exploitation d’une vulnérabilité du noyau
- Il manque des travaux antérieurs analysant de manière scientifique la conception et le fonctionnement réels de nouveaux mécanismes comme le SPTM
- Cet article étudie systématiquement ces nouvelles fonctions non documentées et récapitule les interactions ainsi que les effets de tous les dispositifs de sécurité actuels
Mécanisme central du SPTM (Secure Page Table Monitor)
- Le SPTM est le composant le plus privilégié du système, opérant au niveau Guarded Level 2 (niveau de privilège suprême) avec la Guarded Execution Feature (GXF)
- La GXF ajoute des niveaux de protection horizontaux à la structure classique des niveaux d’exception d’AArch64, isolant les activités sensibles du système de l’accès direct depuis XNU
- Le SPTM fournit des domaines de confiance (
domain of trust) fondés sur des règles de retypage des frames et de mappage mémoire, afin de séparer les zones selon les fonctions - Parmi les exemples représentatifs de ces domaines de confiance figurent le TXM (chargé de la signature de code et de la vérification des autorisations) et Exclaves (fonction récente de séparation sécurisée des zones)
Exclaves et mécanismes de communication
- Exclaves est un environnement d’exécution fonctionnant dans une zone de confiance indépendante et reposant sur un système de protection et de contrôle mémoire basé sur le SPTM
- La communication entre Exclaves et le système est implémentée de diverses manières, notamment via xnuproxy (gestionnaire des requêtes de sécurité) et le framework IPC Tightbeam
- Tightbeam possède une structure IPC complexe avec création d’endpoints, buffers de messages et connexions client-serveur
- Parmi les cas d’usage concrets d’Exclaves analysés figure aussi la gestion des indicateurs de confidentialité (comme les témoins d’enregistrement ou d’utilisation audio)
Renforcement de la sécurité et perspectives
- À mesure que des fonctions système essentielles sont séparées de l’accès direct de XNU, des garde-fous supplémentaires permettent de préserver le niveau de confiance global du système même si le noyau est compromis
- Une analyse fine des interactions entre SPTM, Exclaves et TXM montre la mise en place d’un système de protection par paliers bien plus robuste qu’auparavant
- La conclusion de l’article présente brièvement l’état actuel depuis l’introduction du SPTM, les possibilités futures de renforcement de la sécurité, les limites persistantes et les orientations de recherche à venir
Structure et guide du contenu détaillé
Chapitre 1 : motivation, objectifs et structure
- Contexte historique de la segmentation du noyau Apple et nécessité de cette recherche
- Mise en avant des contributions de l’étude
Chapitre 2 : contexte et bases
- Présentation des niveaux d’exception de l’architecture AArch64, des modes d’accès mémoire et des techniques de protection spécifiques aux puces Apple (Fast Permission Restrictions, Page Protection Layer, Guarded Execution Feature, Shadow Permission Remap Register)
- Synthèse des recherches de sécurité existantes et de leurs limites
Chapitre 3 : environnement d’analyse
- Description du matériel, du firmware, des outils, des symboles et des registres spécifiques à Apple utilisés pour l’analyse
Chapitre 4 : vue d’ensemble de l’architecture
- Visualisation de la structure système complète englobant les EL (niveaux d’exception) et les GL (niveaux de protection horizontaux)
Chapitre 5 : structure approfondie du SPTM
- Explication détaillée de la composition de base du SPTM, de son initialisation, de ses modes d’appel (noyau, TXM, Secure Kernel) ainsi que des headers et tables de dispatch
- Traitement interne des événements par le SPTM, GENTER, et flux de traitement des SVC/HVC (appels superviseur/hyperviseur)
- Logique de retypage des frames : appels et validations, contrôles de validité par type et domaine, mise à jour du SPRR (Permission Remapping), finalisation des appels, etc.
- Processus de mappage des pages et mécanismes de sécurité associés
Chapitre 6 : rôle du Secure Kernel
- Appels du Secure Kernel au SPTM, traitement des SVC et bases du fonctionnement sécurisé
Chapitre 7 : système Exclaves
- Principaux composants, notamment Exclaves, Exclavecore et ExclaveKit
- Gestion de la mémoire et des ressources d’Exclave, regroupement par domaine, machine à états des conclaves (sous-zones) et interactions avec l’espace utilisateur
- Création et ordonnancement des endpoints, ports Mach, IPC de style seL4, xnuproxy, Tightbeam et autres modes de communication, avec exemples d’usage réels (par exemple les indicateurs de confidentialité)
Chapitre 8 : TXM (Trusted Execution Monitor)
- Mode d’intégration du TXM avec le SPTM, structure de dispatch, de retypage et d’exploitation des zones protégées
- Explication des responsabilités de sécurité du TXM et de son traitement des appels
Chapitres 9 à 10 : discussion générale et conclusion
- Enjeux de sécurité liés à l’introduction de SPTM et Exclaves, limites actuelles et orientations futures
- Clôture de l’étude, avec annexe de références et glossaire des termes
Explication des principaux termes
- XNU : noyau central des systèmes d’exploitation d’Apple, sigle de « X is Not Unix »
- SPTM : module clé attribuant des domaines de confiance via la protection et la segmentation de la mémoire
- TXM : superviseur de sécurité chargé de tâches sensibles telles que la vérification des signatures de code
- Exclaves : environnement de sécurité de confiance exécuté de manière isolée dans des zones physiques et logiques distinctes
- Tightbeam IPC : framework assurant une communication sécurisée entre Exclaves et le système
- GXF/GL : niveaux d’exception de protection selon AArch64, complétés par un contrôle horizontal des zones de confiance fondé sur les Guarded Levels
Conclusion
L’architecture de sécurité de l’iOS moderne évolue autour de la séparation de la confiance et du partage des rôles maximisés via SPTM, TXM et Exclaves. Ce système de protection en couches réduit de manière décisive le risque de compromission des couches basses du noyau et fournit une base technique solide pour répondre aux futures menaces de sécurité.
1 commentaires
Avis Hacker News
J’ai vraiment l’impression que l’équipe SEAR et Apple font un travail remarquable sur la sécurité d’iOS, et je veux leur adresser de grands éloges
L’effort consistant à intégrer des mécanismes de sécurité à toute la pile, depuis le niveau matériel, est impressionnant, et ils continuent aussi d’étudier les exploits observés dans la nature (ITW) pour trouver comment les bloquer
Par exemple, ils ont introduit des fonctionnalités comme PPL, mais s’ils concluent que ce n’est pas parfait, ils les abandonnent sans hésiter pour chercher de nouvelles techniques
Apple bénéficie de son intégration verticale, ce qui rend ce type de travail bien plus simple que sur Android. Sur Android, il faut demander la collaboration des fabricants de matériel (QC, Mediatek), puis passer par plusieurs étapes comme le noyau Linux, AOSP, LLVM upstream, etc.
Pointer Authentication Codes (PAC) est aussi un bon exemple. Apple l’a adopté avec une approche du type « faisons-le nous-mêmes », en maintenant sa propre branche LLVM, et a effectivement corrigé le problème en renforçant les attaques basées sur des cas ITW
Si j’achète des produits Apple, ce n’est pas seulement parce que la sécurité et la confidentialité y sont excellentes, mais aussi parce qu’Apple mène ce travail avec passion et sincérité alors même que ce n’est pas quelque chose qu’elle est obligée de faire pour gagner de l’argent
Au-delà du marketing, l’entreprise recrute dans son équipe sécurité les meilleurs hackers de la communauté du jailbreaking, et apporte des innovations comme Private Relay, le mail privé, trusted compute ou multi-party inference
Bien sûr, il y a aussi de vrais problèmes dans l’attitude hypocrite d’Apple. Par exemple, l’autorisation des VPN (avec une exception pour le trafic allant vers les serveurs Apple), ou les paramètres par défaut de protection de la vie privée (à l’exception du Wi‑Fi Calling ou de « journaling suggestions ») sont décevants
En pratique, cela s’accompagne de la condition que l’on n’est pas protégé contre Apple et certains partenaires télécoms, mais malgré cela, Google donne plutôt l’impression d’être « sûr contre tout le monde sauf Google ou les acheteurs de publicité Google », donc Apple me semble très loin devant
Même après un effort d’ingénierie immense, il reste encore dans iMessage des chemins permettant à du code douteux de s’exécuter dans le noyau, ce qui explique pourquoi des exploits 0-click continuent d’exister
Un autre avantage de ces efforts, c’est que dès qu’un chemin de code s’exécute ne serait-ce qu’une fois sur un nouveau processeur où Apple a renforcé la sécurité, la sécurité de toutes les plateformes s’en trouve naturellement améliorée
En théorie, cela permet aussi de repérer plus facilement des problèmes difficiles à détecter par la seule analyse statique, et d’obtenir des informations plus profondes qu’un simple crash
Google aurait aussi pu ajouter MTE il y a déjà quelques années, mais ne voulait pas l’imposer aux OEM dans le cadre de la certification Android
C’est en quelque sorte la même histoire qui se répète qu’avec les mises à jour de l’OS
Si Apple accorde autant d’attention à la sécurité aujourd’hui, ce n’est pas seulement pour protéger les utilisateurs
Fondamentalement, c’est aussi pour empêcher les utilisateurs d’exécuter eux-mêmes des logiciels non approuvés ou de pratiquer le jailbreak, afin de préserver le monopole de l’App Store
Au final, j’estime que l’entreprise fait passer ses propres intérêts avant ceux des utilisateurs
Chaque fois que je lis quelque chose sur la sécurité d’iOS, je suis toujours frappé par sa complexité
Il y a énormément de couches : niveau matériel, niveau noyau, diverses techniques de sandboxing, etc.
Je me demande si cette structure est une « rustine ajoutée à une conception héritée qui supposait la confiance »
Si l’on repartait de zéro, pourrait-on faire quelque chose de plus simple, et existe-t-il réellement des systèmes d’exploitation conçus ainsi ?
Les vulnérabilités sont inévitables dès lors qu’une plateforme prend en charge des cas d’usage variés
La manière d’y répondre, c’est précisément la défense en profondeur (defence-in-depth)
iOS repose sur macOS, macOS repose sur NeXT, et à la racine il y a Unix
Le système a été conçu dès le départ en tenant compte d’un faible niveau de confiance envers l’utilisateur
Le degré de confiance accordé aux utilisateurs a varié selon les époques, et dernièrement la complexité a encore augmenté avec les fonctions réseau toujours connectées et de nouvelles menaces comme celles apparues après Spectre
Pour répondre à la question de savoir s’il s’agit de rustines liées à des choix de conception historiques, je dirais que oui
C’est le résultat d’efforts destinés à compenser les limites du modèle de sécurité Unix et de la programmation système en C
Si l’on repartait entièrement de zéro, on pourrait réduire la complexité en appliquant, par exemple, une capability architecture, mais en pratique cela reste surtout cantonné au monde académique ou aux projets de passionnés à cause des problèmes de compatibilité POSIX
Passer à un modèle complètement nouveau obligerait à abandonner immédiatement la plupart des programmes Unix existants, ce qui rend l’adoption réelle extrêmement difficile
seL4 est une architecture de microkernel rapide, très sûre et formellement vérifiée
Elle offre un contrôle d’accès de haut niveau, la prise en charge des machines virtuelles, et d’autres qualités remarquables
Article explicatif sur l’architecture du microkernel seL4
Mais il lui manque tout le « reste », donc cela me paraît plus proche de la recherche que d’un véritable système d’exploitation
Je pense qu’on pourrait essayer les deux
Même la « sécurité matérielle » repose sur ses propres hypothèses de confiance ; au fond, ce n’est jamais qu’un logiciel codé en dur, et plus la complexité augmente, plus la probabilité de bugs augmente aussi
Lors de la keynote d’Ivan Krstić à la Hexacon cette fois-ci, Apple a annoncé un renforcement de son programme de bug bounty
Billet de blog officiel lié
Je me demande si le problème des connexions en clair (non chiffrées) lors des mises à jour régulières ou de l’exécution d’apps a enfin été résolu
Référence associée