La aplicación de integridad de memoria de Apple (Memory Integrity Enforcement)

• Apple introdujo Memory Integrity Enforcement (MIE), completando un innovador sistema de seguridad de memoria que combina hardware Apple Silicon propio con seguridad avanzada del sistema operativo
• MIE protege superficies de ataque críticas siempre activado, y se aplica a todos los dispositivos iPhone 17 e iPhone Air sin degradación del rendimiento
• Al combinar Enhanced Memory Tagging Extension (EMTE), un asignador de memoria seguro y una política de confidencialidad de etiquetas, aumenta notablemente la resistencia frente a ataques maliciosos
• Gracias a la verificación sincrónica de etiquetas y a la sofisticada integración entre sistema operativo y hardware, se maximiza el bloqueo de desbordamientos de búfer y vulnerabilidades de use-after-free
• Tras años de investigación agresiva y evaluaciones internas, restringe la libertad de acción de los atacantes y alcanza la seguridad de memoria más sólida hasta la fecha

---

Introducción

• Memory Integrity Enforcement (MIE) de Apple es una tecnología de protección de seguridad de memoria siempre activa que integra hardware Apple Silicon con seguridad avanzada del sistema operativo
• Fue desarrollada con el objetivo de ofrecer un marco amplio de seguridad de memoria pionero en la industria en diversos dispositivos Apple, sin impacto adicional en el rendimiento
• Apple la considera una de las funciones más importantes en la historia de la seguridad de memoria de los sistemas operativos para consumidores

Contexto de amenazas de seguridad y evolución de la seguridad de memoria

• La razón por la que el iPhone no tiene casos exitosos de ataques masivos de malware es que, en la práctica, las únicas amenazas observadas son complejas cadenas de ataque centradas en mercenary spyware
• Estos ataques sofisticados, dirigidos a pocos objetivos y con costos de millones de dólares, explotan de forma recurrente vulnerabilidades de seguridad de memoria
• Apple ha mejorado de forma continua la seguridad de memoria mediante el desarrollo de lenguajes seguros como Swift, la introducción de asignadores de memoria seguros y mitigaciones masivas en todo el sistema
• Introdujo por primera vez en la industria Pointer Authentication Code (PAC) en el A12 Bionic, consolidando la seguridad combinada de hardware y software como tendencia dominante

Tecnología de etiquetado de memoria basada en hardware (MTE/EMTE) y superación de limitaciones

• Memory Tagging Extension (MTE), propuesta por Arm, asigna una etiqueta secreta a cada asignación de memoria y solo permite el acceso con la etiqueta correcta
• Apple identificó debilidades en el diseño original de MTE, como su funcionamiento asíncrono, y colaboró con Arm para mejorarlo como Enhanced Memory Tagging Extension (EMTE)
• La clave es que fue diseñado para que la verificación de etiquetas funcione de manera siempre sincrónica, ofreciendo protección continua

Estructura por capas de MIE y principales mecanismos de protección

• MIE se compone de tres elementos: asignadores seguros con reconocimiento de tipo como kalloc_type, xzone malloc y libpas de WebKit; EMTE; y la política de Tag Confidentiality Enforcement (protección de confidencialidad de etiquetas)
• Los asignadores ofrecen protección a nivel de página de memoria entre tipos distintos, y EMTE cubre incluso vulnerabilidades en pequeñas asignaciones de memoria dentro de buckets del mismo tipo
• Frente a ataques comunes de corrupción de memoria, como desbordamientos de búfer y use-after-free, el hardware y el sistema operativo detectan y bloquean de inmediato mediante etiquetado y reetiquetado

Confidencialidad de etiquetas y estrategia ante ataques de canal lateral

• Para impedir que los atacantes apunten al almacenamiento del asignador y a la exposición de etiquetas, se introdujeron protecciones robustas como Secure Page Table Monitor
• Para enfrentar ataques de canal lateral que abusan de la ejecución especulativa, Apple Silicon fue diseñado para bloquear desde el origen cualquier efecto de la información de etiquetas sobre la ejecución especulativa
• También bloquea de forma eficiente la vulnerabilidad Spectre V1, logrando en la mayoría de los casos cortar los eslabones prácticos del ataque

Respuesta integrada de software y hardware y aplicación generalizada

• En el diseño de los nuevos chips A19/A19 Pro, se incorporaron importantes recursos adicionales de hardware para almacenar y verificar etiquetas
• MIE utiliza primero asignadores seguros para proteger por software las áreas posibles, mientras que EMTE se aplica de manera precisa a las zonas que no pueden defenderse por software
• También se refinó la estrategia de despliegue para que los iPhone más antiguos reciban la mayor cantidad posible de mejoras de seguridad de memoria

Evaluación de seguridad en escenarios reales y análisis de efectividad

• El equipo de investigación ofensiva de Apple diseñó diversos escenarios de ataque desde el plan de MIE entre 2020 y 2025, repitiendo intentos reales de intrusión incluso sobre prototipos de hardware
• Tanto en cadenas de exploits nuevas como antiguas, se confirmó que, con MIE aplicado, la mayoría de las etapas del ataque quedan bloqueadas de raíz
• Incluso las pocas vulnerabilidades que sobrevivieron no permiten ataques estables, por lo que la posibilidad de daño real se reduce drásticamente

Conclusión

• La seguridad de primer nivel del iPhone limita para la gran mayoría de los usuarios la propia exposición a ataques a nivel de sistema
• MIE neutraliza las estrategias de ataque más complejas y costosas del mercenary spyware real, al tiempo que protege siempre más de 70 procesos clave en espacio de usuario, incluido el kernel
• Según la evaluación, eleva de forma drástica el costo y la dificultad de explotar vulnerabilidades de corrupción de memoria, bloqueando con solidez las principales técnicas de ataque de los últimos 25 años
• MIE se posiciona como el mayor cambio en la historia de la seguridad de memoria de los sistemas operativos para consumidores en iOS y los dispositivos Apple

[GN⁺]

Opinión de Hacker News

• Ambos enfoques llegaron a la misma conclusión. Memory Integrity Enforcement (MIE) bloquea de raíz la mayoría de las estrategias de exploit que podrían usar los atacantes. Los bugs de corrupción de memoria normalmente son intercambiables entre sí, pero MIE bloqueó demasiadas rutas de exploit desde las etapas básicas, así que ni siquiera reemplazándolas por bugs nuevos se podía reconstruir la cadena. Por más que lo intentaron, no pudieron rearmar una cadena que la eludiera. Los pocos efectos que quedan tampoco son confiables, así que no bastan para que un atacante los explote con éxito. Esto es una muy buena noticia y, aunque puede parecer un detalle menor a primera vista, es un punto importante. Parte de la economía del spyware mercenario depende de cadenas intercambiables, así que una defensa que apunte directamente a esa propiedad resulta especialmente interesante
  • Me da curiosidad si la estrategia de Apple es un paso hacia una seguridad de memoria completamente basada en capabilities, como CHERI (ver: Capability Hardware Enhanced RISC Instructions), o si más bien debe interpretarse como una señal de que Apple considera suficiente no contar con un sistema así
  • También quisiera mencionar el enfoque de Google sobre seguridad de memoria como contraparte del caso de Apple. Google se tomó muy en serio la seguridad de memoria desde los primeros días de Chrome/Android, y también lideró la adopción de ASAN, syzkaller y Hardware MTE. Yo fui responsable de dirigir equipos así, por lo que viví de primera mano varias ventajas y desventajas. Lo que Google quería lograr era poder activar y desactivar validaciones al nivel de ASAN según hiciera falta. Mantenerlo siempre encendido como mitigación de seguridad tiene varios problemas además del overhead de memoria. Por ejemplo, termina provocando muchos crashes visibles para el usuario de manera inconsistente entre dispositivos. Desde la perspectiva de los desarrolladores, era inevitable que hubiera quejas si las pruebas reales solo podían hacerse correctamente en dispositivos con soporte para MTE, que eran alrededor de un millón. MTE detecta algunos exploits de seguridad, pero también detecta muchos bugs inofensivos. Aun así, no está claro si siempre sea la mejor opción como mitigación en runtime. Google Security, Project Zero y otros han invertido muchísimo esfuerzo en responder a los CSVs, pero siento que la sede central fue deficiente al convertir MTE en un producto (enlace)
  • Puede que no sea una buena noticia para Vigilant Labs, pero no está claro si de verdad se vieron muy afectados
• Creo que la afirmación de Apple de que “las protecciones de seguridad de memoria deben estar siempre activadas, de manera sincrónica, por defecto y funcionando de forma continua” proviene más de la experiencia que del purismo ideológico. Esto fue distinto de las primeras protecciones del kernel. Kernel Patch Protection (KPP), introducido en iOS 9 en 2015, verificaba de forma asíncrona cada pocos minutos, cuando el dispositivo estaba inactivo, si el kernel había sido modificado. Ese enfoque no era muy confiable desde el punto de vista de seguridad, y tenía fallas de diseño: se publicaron hacks que lo eludían por completo. KPP no impedía de raíz los parches al kernel, sino que solo provocaba un panic cuando los detectaba. Es decir, si el atacante terminaba su trabajo lo bastante rápido y luego revertía los cambios, KPP no tenía cómo detectarlo (ver writeup)
  • Con base en información interna, KPP fue una solución improvisada para igualar deliberadamente un nivel de seguridad equivalente en los SoCs A11 cuando se introdujo KTRR en el A11. Se implementó de la mejor manera posible dentro de un cronograma corto como ese, y después no repitieron ese enfoque
  • Más que haberlo preparado desde el principio por principios, parece que llegaron a esta conclusión en la etapa inicial del diseño para introducir MTE. El nivel de seguridad de Apple ha ido mejorando de forma constante, y mucho de eso proviene de aprendizajes forzados por el jailbreak y similares
  • Coincido en que es difícil implementar perfectamente este tipo de sistema desde el principio
• Apple dijo que “no ha habido ataques de malware exitosos y generalizados contra el iPhone”, pero creo que bastaría modificar un poco el código de spyware existente para usarlo enseguida en ataques a gran escala. En la práctica, esa distinción no es tan clara
  • La realidad es que ni Apple ni Google pueden conocer perfectamente la escala real de los ataques. Según materiales filtrados que publicó GrapheneOS, los desarrolladores de exploits son más capaces de lo que la gente cree para atacar dispositivos y adaptarse a las actualizaciones. Además hay material no publicado; solo comparten una parte para no exponer la vía de filtración a menos que pueda verificarse con múltiples fuentes independientes. Estas herramientas de exploit están ampliamente disponibles, y ni siquiera es fácil distinguir si se trata de extracción cotidiana de datos o de explotación remota. En la práctica rara vez se detectan los exploits, y la mayoría puede usarse a gran escala sin ser detectada, así que incluso una sola cadena conserva valor durante mucho tiempo. Cuerpos policiales de todo el mundo ya usan herramientas como Cellebrite Premium contra muchas personas en fronteras, protestas y otros contextos. Eso ya cuenta como uso a gran escala. En el caso de los exploits remotos, aunque se usen ampliamente, ni siquiera hace falta desplegarlos ampliamente
  • XcodeGhost es un caso representativo de un ataque de malware a gran escala contra iPhone. En ese momento se infectaron apps como WeChat. Material de referencia: Wikipedia de XcodeGhost
  • No está claro si realmente habría podido usarse en un ataque a gran escala, pero si hubiera tenido una exposición como la de Windows, habría habido muchos casos
  • Es posible que esa frase apunte sobre todo a resaltar las ventajas del modelo de control propio frente a Android
  • Aunque suena a lenguaje de abogado, es positivo para todos que Apple haya publicado material muy detallado y un mensaje confiado sobre tecnologías nuevas como este MIE
• Este sistema ciertamente es impresionante. Aun así, puede no ser suficiente cuando el atacante puede reintentar muchas veces. Por ejemplo, si es posible acceder fuera de límites incluso hacia objetos no adyacentes, o si después de manipular muchas asignaciones de memoria el tag termina coincidiendo por casualidad, podría eludirse. La probabilidad de acertar el tag es 1/16. Pero como el texto principal no da una explicación detallada, no estoy seguro de que mi predicción sea correcta. Si realmente se aplica con éxito, los exploits restantes tendrían que depender de bugs lógicos, lo que lo volvería mucho más difícil para el atacante
  • En Android MTE también era posible de forma similar un ataque probabilístico basado en reintentos múltiples aprovechando el pequeño tamaño del tag. Sin embargo, la diferencia importante aquí es que la enforcement sincrónica y consistente es la clave. Es decir, el trap ocurre inmediatamente con cada manipulación de escritura en memoria, no al momento del cambio de contexto
  • Además del 1/16 de probabilidad de acierto, los otros 15/16 intentos provocan un crash. Un bug tan inestable es fácil de exponer ante el usuario o ante sistemas de diagnóstico, y si además hay que encadenar varias etapas exitosas, en términos probabilísticos la explotación real se vuelve casi imposible
  • Puede que estas defensas no apliquen frente a ataques de nivel estatal que se infiltran durante largos periodos, como los ataques a la cadena de suministro
• El modelo de Apple/ARM seguramente es mucho más sofisticado, pero me recuerda a la arquitectura de memory tagging de los Burroughs large systems (referencia)
• Cuando dicen que “el atacante no debe poder predecir el valor del tag que elige el sistema. Para eso, se vuelve a sembrar frecuentemente el PRNG para generar tags nuevos”, el problema de fondo es la baja entropía del tag (solo 4 bits). Si el atacante acierta al azar, su probabilidad de éxito es 1/16, y volver a sembrar el PRNG no cambia esa probabilidad. Parece que hace falta más explicación
  • El atacante solo tiene una oportunidad de adivinar. Si falla, el proceso termina o el kernel entra en panic. Cuando lo intente de nuevo, tendrá que adivinar otra vez porque el tag ya será nuevo, así que no se pueden hacer intentos consecutivos
  • Con 4 bits, la cantidad de posibilidades es demasiado pequeña. Las asignaciones de memoria ocurren millones de veces por segundo, y aunque el reseed sea frecuente, la probabilidad de colisiones aumenta muy rápido
• La mayor fortaleza de esta serie de dispositivos es justamente esta nueva función
• Si se implementan políticas como el chat control de la UE, el Estado podrá acceder a todo lo que quiera en mi dispositivo, y si Google impone WEI, podría bloquearse toda la web. Con secure boot y MIE, podría volverse difícil para los usuarios recuperar las libertades que tenían antes
  • Es decir, para proteger esas libertades quizá haya que separar un poco más los sistemas y servicios, es decir, fragmentarlos
  • Me pregunto si aquí la crítica al endurecimiento de MIE incluye la queja de que limita la libertad del usuario, como con el jailbreak
  • Me pregunto qué es WEI
• Que Google haya ofrecido MTE como opt-in el año pasado fue un buen primer paso, pero no es lo mismo que el MIE basado en EMTE que destaca Apple, porque faltó integración total. Impresiona que con el lanzamiento del iPhone 17 y Air, Apple introduzca el primer sistema integral de seguridad de memoria siempre activa de la industria. Aunque es una lástima que no se haya reconocido debidamente el esfuerzo pionero de GrapheneOS (ejemplo de lanzamiento, concientización), espero que el intento serio de Apple se extienda pronto a Google, Pixel OS y varios sistemas operativos enfocados en seguridad. Esto vuelve a confirmar que GrapheneOS es un líder en sistemas que defienden incluso contra amenazas desconocidas
  • Apple lleva mucho tiempo preparándose en esta área. No empezó desde el momento en que GrapheneOS lo activó
• Existe la frase “en 2018, con el chip A12 Bionic, aplicamos por primera vez en la industria Pointer Authentication Codes (PAC) para proteger la integridad del flujo de código”, pero incluso después de introducir PAC hubo varios casos de ataques full-chain. PAC no fue una medida significativa de disuasión de ataques. Los atacantes siguen encontrando formas de eludir PAC. Esto debe tenerse en cuenta al evaluar la efectividad real de MIE
  • En realidad, Apple no dijo que PAC fuera una medida de disuasión de ataques, sino que el logro era “aumentar la complejidad del exploit”. La frase en sí es algo ambigua, pero como yo la interpreto, es un reconocimiento de que PAC por sí solo no basta y se necesita un enfoque combinado de software y hardware. PAC también es una función de hardware que requiere cambios de software, pero EMTE es una tecnología que exige un alcance y una coordinación mucho mayores
  • No es que PAC no sirva para nada; al contrario, funciona como un incentivo para obligar al atacante a encontrar sí o sí una vía para eludirlo. Y las vías de bypass de PAC no son infinitas
  • Que PAC haya sido eludido varias veces no significa que sea inútil; al contrario, eso demuestra que está funcionando con eficacia