Memory Integrity Enforcement d’Apple

• Apple a introduit Memory Integrity Enforcement (MIE), un système innovant de sécurité mémoire qui combine son matériel Apple Silicon et des protections avancées du système d’exploitation
• MIE protège les surfaces d’attaque critiques en étant toujours activé, et s’applique à tous les iPhone 17 et iPhone Air sans impact sur les performances
• En combinant l’Enhanced Memory Tagging Extension (EMTE), un allocateur mémoire sécurisé et une politique de confidentialité des tags, Apple renforce nettement la résistance aux attaques malveillantes
• Grâce à une vérification synchrone des tags et à une intégration fine entre système d’exploitation et matériel, le blocage des buffer overflows et vulnérabilités de type use-after-free est maximisé
• Après plusieurs années de recherche offensive et d’évaluations internes, Apple affirme avoir réduit la liberté d’action des attaquants et atteint son plus haut niveau de sécurité mémoire à ce jour

---

Introduction

• Memory Integrity Enforcement (MIE) d’Apple est une technologie de protection de la sécurité mémoire toujours active, qui intègre le matériel Apple Silicon et des protections avancées du système d’exploitation
• Elle a été développée avec pour objectif d’offrir, sur différents appareils Apple, le premier cadre de sécurité mémoire à grande échelle du secteur, sans dégradation supplémentaire des performances
• Apple la présente comme l’évolution la plus importante de l’histoire de la sécurité mémoire dans les systèmes d’exploitation grand public

Contexte des menaces et évolution de la sécurité mémoire

• Si l’iPhone n’a pas connu de cas avérés de campagnes massives de malware réussies, c’est parce que les menaces observées en pratique reposent surtout sur des chaînes d’attaque complexes centrées sur les mercenary spyware
• Ces attaques sophistiquées, coûteuses et ciblant un petit nombre de victimes, exploitent généralement des vulnérabilités de sécurité mémoire
• Apple a continuellement renforcé la sécurité mémoire via le développement de langages sûrs comme Swift, l’introduction d’allocateurs mémoire sécurisés et de larges mesures d’atténuation à l’échelle du système
• Avec l’introduction pionnière du Pointer Authentication Code (PAC) dans l’A12 Bionic, Apple a établi la sécurité couplée matériel-logiciel comme un standard du secteur

Technologie de marquage mémoire matérielle (MTE/EMTE) et dépassement des limites

• La Memory Tagging Extension (MTE) proposée par Arm attribue un tag secret à chaque allocation mémoire et n’autorise l’accès qu’avec le tag correct
• Apple a identifié des limites dans la conception d’origine de MTE, notamment son fonctionnement asynchrone, puis l’a améliorée avec Arm en Enhanced Memory Tagging Extension (EMTE)
• Le point central est une conception où la vérification des tags fonctionne de manière toujours synchrone, afin d’assurer une protection continue

Architecture en couches de MIE et principaux mécanismes de protection

• MIE repose sur trois composants : des allocateurs sécurisés sensibles aux types comme kalloc_type, xzone malloc et libpas de WebKit, EMTE, et une politique de Tag Confidentiality Enforcement
• Les allocateurs fournissent une protection au niveau des pages mémoire entre différents types, tandis qu’EMTE couvre aussi les vulnérabilités touchant de petites allocations mémoire au sein d’un même bucket de type
• Face aux attaques classiques de corruption mémoire, comme les buffer overflows et les use-after-free, le matériel et le système d’exploitation détectent et bloquent immédiatement les abus via le tagging et le retagging

Confidentialité des tags et stratégie face aux attaques par canal auxiliaire

• Pour empêcher les attaquants de viser le stockage des allocateurs et l’exposition des tags, Apple a introduit de solides mécanismes de protection, dont le Secure Page Table Monitor
• Pour contrer les attaques par canal auxiliaire exploitant l’exécution spéculative, Apple Silicon a été conçu pour bloquer à la source tout effet des informations de tag sur l’exécution spéculative
• La vulnérabilité Spectre V1 est également bloquée de manière efficace, ce qui coupe dans la plupart des cas toute chaîne d’exploitation concrète

Réponse intégrée logiciel-matériel et déploiement général

• Lors de la conception des nouvelles puces A19/A19 Pro, d’importantes ressources matérielles supplémentaires ont été mobilisées pour le stockage et la vérification des tags
• MIE s’appuie d’abord sur des allocateurs sécurisés pour couvrir par logiciel ce qui peut l’être, tandis qu’EMTE est appliqué de façon ciblée aux zones impossibles à protéger par logiciel
• La stratégie de déploiement a aussi été affinée afin que les anciens iPhone puissent bénéficier d’un maximum d’améliorations de sécurité mémoire

Évaluation de sécurité en conditions réelles et analyse de l’efficacité

• L’équipe de recherche offensive d’Apple a élaboré divers scénarios d’attaque à partir du projet MIE entre 2020 et 2025, et a mené des tentatives d’intrusion répétées jusque sur des prototypes matériels
• Sur des chaînes d’exploit anciennes comme récentes, Apple a confirmé qu’avec MIE, la plupart des étapes de l’attaque sont fondamentalement neutralisées
• Même les rares vulnérabilités restantes ne permettent pas d’attaque fiable, réduisant fortement le risque de dommage réel

Conclusion

• La sécurité de très haut niveau de l’iPhone limite, pour la grande majorité des utilisateurs, l’exposition même aux attaques de niveau système
• MIE neutralise les stratégies d’attaque les plus complexes et les plus coûteuses des mercenary spyware, tout en protégeant en permanence plus de 70 processus clés en espace utilisateur, noyau compris
• Selon l’évaluation, MIE augmente fortement le coût et la difficulté d’exploitation des vulnérabilités de corruption mémoire, bloquant efficacement la principale famille d’attaques des 25 dernières années
• MIE s’impose ainsi comme la plus grande évolution de l’histoire de la sécurité mémoire des systèmes d’exploitation grand public sur iOS et les appareils Apple

[GN⁺]

Avis Hacker News

• Les deux approches sont arrivées à la même conclusion. Memory Integrity Enforcement (MIE) bloque fondamentalement la plupart des stratégies d’exploit à la disposition des attaquants. Les bugs de corruption mémoire sont normalement interchangeables, mais MIE coupe tellement de chemins d’exploitation au niveau le plus basique qu’il n’a pas été possible de reconstruire une chaîne même en les remplaçant par de nouveaux bugs. Malgré tous les efforts, il n’a pas été possible de reconstituer une chaîne de contournement. Les quelques effets restants ne sont pas fiables non plus, ce qui est insuffisant pour une exploitation réussie par un attaquant. C’est une très bonne nouvelle, et un point important qu’on pourrait facilement manquer au premier abord. Une partie de l’économie des spywares mercenaires repose sur des chaînes interchangeables, donc des défenses qui ciblent directement cette propriété sont particulièrement intéressantes
  • Je me demande si la stratégie d’Apple est une étape vers une sécurité mémoire entièrement fondée sur les capabilities, comme CHERI (voir : Capability Hardware Enhanced RISC Instructions), ou s’il faut y voir le signe qu’Apple estime qu’un tel système n’est pas nécessaire
  • Je voudrais aussi présenter l’approche de Google en matière de sécurité mémoire en parallèle du cas Apple. Google prenait la sécurité mémoire très au sérieux dès les débuts de Chrome/Android, et a aussi mené l’introduction d’ASAN, de syzkaller et du Hardware MTE. Comme j’étais responsable d’équipes de ce type, j’ai directement vu de nombreux avantages et inconvénients. Ce que Google essayait de faire, c’était de permettre d’activer ou désactiver un niveau de vérification comparable à ASAN selon les besoins. Le laisser toujours activé comme mesure de sécurité pose plusieurs problèmes au-delà du surcoût mémoire. Par exemple, cela entraîne un grand nombre de crashs visibles par les utilisateurs, de manière incohérente selon les appareils. Du point de vue des développeurs, il était inévitable qu’ils se plaignent puisqu’il fallait vraiment tester seulement sur les appareils compatibles MTE, soit environ un million d’unités. MTE bloque certains exploits de sécurité, mais détecte aussi de nombreux bugs inoffensifs. En revanche, il n’est pas certain que ce soit toujours le meilleur choix comme mitigation à l’exécution. Google Security, Project Zero et d’autres ont beaucoup travaillé sur les réponses aux CSV, mais j’ai le sentiment que le siège a été insuffisant sur la mise en production de MTE (lien)
  • Ce n’est peut-être pas une bonne nouvelle pour Vigilant Labs, mais il n’est pas certain qu’ils aient réellement été fortement affectés
• L’affirmation d’Apple selon laquelle « les protections de sécurité mémoire doivent impérativement être toujours activées de façon synchrone, par défaut et en continu » vient probablement de l’expérience plus que d’un positionnement de principe. C’était différent des premières protections du noyau. Kernel Patch Protection (KPP), introduit avec iOS 9 en 2015, vérifiait de manière asynchrone toutes les quelques minutes, quand l’appareil était inactif, si le noyau avait été modifié. Cette approche n’était pas très fiable du point de vue de la sécurité, et des hacks contournant totalement le mécanisme avaient été publiés à cause de défauts de conception. KPP n’empêche pas intrinsèquement les modifications du noyau : il ne fait que déclencher un panic lorsqu’elles sont détectées. Autrement dit, si l’attaquant terminait son travail assez vite puis rétablissait l’état initial, KPP ne pouvait pas le détecter (voir le writeup)
  • D’après des informations internes, KPP a été bricolé à la hâte à l’époque de l’introduction de KTRR sur l’A11 afin d’atteindre volontairement un niveau de sécurité équivalent sur les SoC antérieurs à l’A11. Cela a été implémenté de la meilleure façon possible dans ce calendrier très court, puis cette approche n’a plus été répétée par la suite
  • Plutôt qu’une préparation de principe dès le départ, il semble qu’Apple soit arrivé à cette conclusion lors de la conception initiale de l’introduction de MTE. Le niveau de sécurité d’Apple s’est amélioré de façon constante, en grande partie grâce aux leçons apprises sous contrainte via le jailbreak et d’autres expériences du même type
  • Je suis d’accord sur le fait qu’il est difficile d’implémenter parfaitement ce genre de système dès le départ
• Apple a affirmé qu’« il n’y a pas eu d’attaques malware réussies et largement diffusées contre l’iPhone », mais je pense qu’un code de spyware existant, légèrement modifié, pourrait immédiatement servir à des attaques à grande échelle. En pratique, cette distinction n’est pas si nette
  • En réalité, ni Apple ni Google ne peuvent avoir une vision parfaite de l’ampleur réelle des attaques. D’après des documents divulgués publiés par GrapheneOS, les développeurs d’exploits sont plus capables qu’on ne le pense généralement pour attaquer des appareils et s’adapter aux mises à jour. Il existe aussi d’autres documents non publiés, et une partie seulement est partagée pour éviter d’exposer les canaux de fuite tant qu’ils ne sont pas vérifiés par plusieurs sources indépendantes. Ces outils d’exploitation sont largement disponibles, et il n’est même pas facile de distinguer une extraction de données de routine d’une exploitation à distance. Les exploits sont rarement détectés en conditions réelles, et la plupart peuvent être utilisés à grande échelle sans détection, ce qui fait qu’une seule chaîne garde de la valeur pendant longtemps. Des forces de l’ordre partout dans le monde utilisent des outils comme Cellebrite Premium sur de nombreuses personnes aux frontières, lors de manifestations, etc. Cela relève déjà d’un usage à grande échelle. Dans le cas des exploits à distance, même un usage large n’exige pas forcément une large diffusion
  • XcodeGhost est un exemple représentatif d’attaque malware à grande échelle sur iPhone. WeChat et d’autres avaient été infectés à l’époque. Documentation : XcodeGhost Wikipedia
  • On ne sait pas avec certitude si cela aurait pu être utilisé pour de vraies attaques à grande échelle, mais si l’exposition avait été comparable à celle de Windows, il y aurait probablement eu bien plus de cas
  • Cette formulation vise peut-être surtout à mettre en avant les avantages de son modèle de contrôle maison par comparaison avec Android
  • C’est un langage un peu juridique, mais le fait qu’Apple ait publié cette fois des documents très détaillés et un message très confiant sur de nouvelles technologies comme MIE est positif pour nous tous
• Ce système est clairement impressionnant. En revanche, il pourrait ne pas être suffisant si un attaquant peut réessayer plusieurs fois. Par exemple, si un accès hors limites vers des objets non adjacents est possible, ou si après de nombreuses manipulations d’allocations mémoire le tag finit par correspondre par hasard, un contournement devient possible. La probabilité qu’un tag corresponde est de 1/16. Cela dit, comme le texte principal n’entre pas dans le détail, je ne suis pas certain que mon hypothèse soit correcte. Si cela fonctionne effectivement comme annoncé, les exploits restants devront s’appuyer sur des bugs logiques, ce qui les rendra bien plus difficiles pour les attaquants
  • De façon similaire avec Android MTE, des attaques probabilistes fondées sur plusieurs tentatives étaient possibles à cause de la petite taille des tags. Mais ici, la différence cruciale est que l’enforcement synchrone et cohérent est essentiel. Autrement dit, un trap se déclenche immédiatement à chaque manipulation d’écriture mémoire, et non au moment d’un changement de contexte
  • Les 15 tentatives sur 16 autres que la bonne provoquent toutes un crash. Des bugs aussi instables sont faciles à exposer aux utilisateurs ou aux systèmes de diagnostic, et s’il faut enchaîner plusieurs étapes avec succès, l’exploitation réelle devient, en termes probabilistes, presque impossible
  • Des attaques étatiques menées sur le long terme, comme des attaques de supply chain, pourraient ne pas être couvertes par ce type de défense
• Le modèle Apple/ARM est bien plus sophistiqué, mais il fait penser à l’architecture de memory tagging des Burroughs large systems (référence)
• Dans l’explication disant que « l’attaquant ne doit pas pouvoir prédire les valeurs de tag choisies par le système. Pour cela, le PRNG est reseed fréquemment pour générer de nouveaux tags », le problème fondamental est la faible entropie des tags, qui n’est que de 4 bits. Si l’attaquant tente au hasard, sa probabilité de succès est de 1/16, et le reseed du PRNG ne change pas cette probabilité. Il faudrait plus d’explications
  • L’attaquant n’a qu’une seule chance de deviner. En cas d’erreur, le processus est tué ou le noyau panique. À la tentative suivante, un nouveau tag est utilisé, il faut donc recommencer à deviner, ce qui empêche les essais continus
  • Avec 4 bits, le nombre de cas possibles est trop faible. Les allocations mémoire se produisent des millions de fois par seconde, et même avec des reseed fréquents, la probabilité de collisions augmente très rapidement
• La plus grande force de cette série d’appareils est précisément cette nouvelle fonctionnalité
• Si des politiques comme le chat control de l’UE sont mises en œuvre, l’État pourra accéder à tout ce qu’il veut sur mon appareil, et si Google impose WEI, c’est tout le web qui pourra être bloqué. Avec secure boot et MIE, il pourrait devenir difficile pour les utilisateurs de retrouver leurs libertés d’autrefois
  • Autrement dit, pour préserver ces libertés, il faudra sans doute davantage séparer les systèmes et les services, les balkaniser davantage
  • Je me demande si le renforcement de MIE inclut ici une critique du fait qu’il limite la liberté des utilisateurs, par exemple via le jailbreak
  • Je me demande ce que signifie WEI
• Le fait que Google ait proposé MTE en opt-in l’an dernier est un bon premier pas, mais faute d’intégration complète, cela reste différent du MIE basé sur EMTE mis en avant par Apple. Il est impressionnant de voir apparaître avec l’iPhone 17 et Air le premier système complet de sécurité mémoire toujours activé à l’échelle de l’industrie. Même s’il est regrettable que les efforts pionniers de GrapheneOS (exemple de release, sensibilisation) n’aient pas reçu toute l’attention qu’ils méritaient, j’espère que la démarche sérieuse d’Apple se diffusera rapidement à Google, Pixel OS et à divers OS orientés sécurité. Cela confirme une nouvelle fois que GrapheneOS est un pionnier des systèmes défendant même contre des menaces encore inconnues
  • Apple prépare cela depuis longtemps dans ce domaine. Cela n’a pas commencé au moment où GrapheneOS l’a activé
• Le texte dit : « en 2018, avec la puce A12 Bionic, nous avons été les premiers du secteur à déployer Pointer Authentication Codes (PAC) pour protéger l’intégrité du flux de code », mais même après l’introduction de PAC, il y a eu plusieurs cas d’attaques full-chain. PAC n’était pas une mesure de dissuasion significative contre les attaques. Les attaquants continuent de trouver des contournements à PAC. Il faut garder cela en tête lorsqu’on évalue l’efficacité réelle de MIE
  • En réalité, Apple n’a pas présenté PAC comme une mesure de dissuasion des attaques, mais a parlé d’une « augmentation de la complexité des exploits » comme résultat. La formulation elle-même est un peu ambiguë, mais à ma lecture, c’est une reconnaissance du fait que PAC seul ne suffit pas et qu’une approche combinant logiciel et matériel est nécessaire. PAC est déjà en soi une fonctionnalité matérielle qui exige des changements logiciels, mais EMTE est une technologie qui demande une surface bien plus large et davantage de coordination
  • Ce n’est pas que PAC soit sans intérêt ; au contraire, cela pousse les attaquants à devoir absolument trouver des contournements de PAC. Or, ces contournements ne sont pas en nombre illimité
  • Le fait que PAC ait été contourné plusieurs fois ne signifie pas qu’il soit invalide ; au contraire, cela montre qu’il fonctionne efficacement