- El kernel XNU de los sistemas operativos de Apple ha ofrecido tradicionalmente un único dominio de confianza.
- Recientemente, Apple ha impulsado cambios para reducir el impacto de vulnerabilidades de seguridad mediante la separación de la arquitectura del kernel y su evolución hacia un microkernel.
- Con la introducción de Secure Page Table Monitor (SPTM) en 2023, se separaron funciones clave y se formó una nueva estructura de dominios de confianza.
- Los mecanismos de seguridad más recientes, como Exclaves y Trusted Execution Monitor (TXM), están implementados sobre la base de SPTM.
- Estas mejoras estructurales evitan que un compromiso del kernel degrade de inmediato la confianza de todo el sistema.
Resumen general
El kernel XNU, núcleo de los sistemas operativos de Apple, suele describirse como un kernel híbrido, pero en la práctica ha operado con una estructura de tipo monolítico donde todas las funciones del sistema se concentran en una única zona privilegiada de confianza. Por ello, cuando el kernel se ve comprometido, todo el sistema queda inmediatamente expuesto a amenazas graves. En los últimos años, Apple ha avanzado en una mayor segmentación del kernel y en un diseño más cercano al de un microkernel, trasladando fuera del área del kernel funciones críticas como la manipulación de tablas de páginas y ciertas tareas criptográficas.
Motivación principal de los cambios y dirección de la investigación
- Se ha vuelto evidente la necesidad de mejorar la estructura del kernel para reforzar la seguridad.
- El objetivo es minimizar el impacto negativo sobre todo el sistema cuando se explotan vulnerabilidades del kernel.
- Aún faltaban estudios previos que analizaran de forma rigurosa cómo están diseñados y cómo operan realmente mecanismos nuevos como SPTM.
- Este artículo investiga de manera sistemática estas funciones no documentadas públicamente y organiza la interacción y el efecto de los mecanismos de seguridad actuales.
Mecanismo central de SPTM (Secure Page Table Monitor)
- SPTM es el componente con mayor privilegio del sistema y opera en Guarded Level 2 (el nivel de privilegio más alto), junto con Guarded Execution Feature (GXF).
- GXF añade niveles horizontales de protección a la estructura tradicional de niveles de excepción de AArch64, aislando actividades sensibles del sistema del acceso directo por parte de XNU.
- SPTM proporciona dominios de confianza mediante reglas de retipado de frames y mapeo de memoria, separando áreas según la función.
- Entre los ejemplos representativos de estos dominios de confianza están TXM (encargado de firma de código y verificación de privilegios) y Exclaves (la función más reciente de separación segura de dominios).
Exclaves y mecanismos de comunicación
- Exclaves es un entorno de ejecución que opera en una zona de confianza independiente y depende del sistema de protección y control de memoria basado en SPTM.
- La comunicación entre Exclaves y el sistema se implementa de varias formas, entre ellas xnuproxy (manejador de solicitudes seguras) y el framework de IPC Tightbeam.
- Tightbeam tiene una estructura de IPC compleja con creación de endpoints, buffers de mensajes y conexiones cliente-servidor.
- Como caso real de uso de Exclaves, el análisis también incluye el control de indicadores de privacidad, como los que muestran grabación o uso de audio.
Refuerzo de seguridad y perspectivas futuras
- Al separarse funciones centrales del sistema del acceso directo de XNU, se añade una capa de seguridad que preserva el nivel de confianza global incluso si el kernel es comprometido.
- El análisis detallado de la interacción entre SPTM, Exclaves y TXM muestra la formación de un sistema de protección por capas mucho más sólido que antes.
- La conclusión del artículo resume el estado actual tras la introducción de SPTM, las posibilidades futuras de refuerzo de seguridad, las limitaciones que permanecen y las líneas de investigación posteriores.
Estructura y guía del contenido en profundidad
Capítulo 1: motivación, objetivos y estructura
- Contexto histórico del movimiento de Apple hacia la segmentación del kernel y necesidad de esta investigación.
- Énfasis en las contribuciones del estudio.
Capítulo 2: antecedentes y fundamentos
- Presentación de los niveles de excepción de la arquitectura AArch64, los métodos de acceso a memoria y las técnicas especiales de protección en chips de Apple (Fast Permission Restrictions, Page Protection Layer, Guarded Execution Feature, Shadow Permission Remap Register).
- Resumen de investigaciones de seguridad previas y sus limitaciones.
Capítulo 3: entorno de análisis
- Explicación del hardware, firmware, herramientas, símbolos y registros específicos de Apple utilizados como objetivo de análisis.
Capítulo 4: panorama general del diseño arquitectónico
- Visualización de la estructura completa del sistema, abarcando tanto EL (niveles de excepción) como GL (niveles horizontales de protección).
Capítulo 5: estructura interna de SPTM
- Explicación detallada de la configuración básica de SPTM, su inicialización, sus formas de invocación (kernel, TXM y Secure Kernel), y sus headers y tablas de despacho.
- Flujo de procesamiento de eventos internos de SPTM, GENTER y manejo de SVC/HVC (llamadas de supervisor/hipervisor).
- Lógica de retipado de frames: explicación paso a paso de llamadas y validaciones, verificación de validez por tipo y dominio, actualización de SPRR (Permission Remapping) y cierre de la llamada.
- Proceso de mapeo de páginas y sus mecanismos de seguridad.
Capítulo 6: rol de Secure Kernel
- Fundamentos de la operación segura, incluidas las llamadas entre Secure Kernel y SPTM y el procesamiento de SVC.
Capítulo 7: sistema Exclaves
- Componentes principales como Exclaves, Exclavecore y ExclaveKit.
- Gestión de memoria y recursos de Exclave, agrupación por dominio, máquina de estados de conclaves (subáreas) e interacción con espacio de usuario.
- Creación y planificación de endpoints, puertos Mach, IPC estilo seL4, xnuproxy, Tightbeam y otros métodos de comunicación, junto con ejemplos reales de uso (por ejemplo, indicadores de privacidad).
Capítulo 8: TXM (Trusted Execution Monitor)
- Forma en que TXM se integra con SPTM, así como su estructura operativa de despacho, retipado y manejo de áreas protegidas.
- Explicación de las responsabilidades de seguridad de TXM y su modo de procesar llamadas.
Capítulos 9~10: discusión general y conclusión
- Consideraciones de seguridad derivadas de la introducción de SPTM y Exclaves, limitaciones actuales y dirección futura.
- Cierre de la investigación y apéndices con material de referencia y explicación de términos.
Glosario de términos clave
- XNU: kernel central de los sistemas operativos de Apple; significa “X is Not Unix”.
- SPTM: módulo clave que otorga dominios de confianza mediante protección y segmentación de memoria.
- TXM: supervisor de seguridad encargado de tareas sensibles como la verificación de firma de código.
- Exclaves: entorno seguro de confianza que se ejecuta de forma aislada en áreas físicas y lógicas separadas.
- Tightbeam IPC: framework que permite la comunicación segura entre Exclaves y el sistema.
- GXF/GL: niveles de excepción de protección en AArch64 y mecanismo adicional de control de zonas horizontales de confianza basado en Guarded Level.
Conclusión
La arquitectura de seguridad del iOS moderno está evolucionando para maximizar la separación de confianza y la división de responsabilidades en torno a SPTM, TXM y Exclaves. Este sistema de protección por capas reduce de forma drástica el riesgo de compromisos en capas inferiores del kernel y proporciona una base técnica sólida para responder con robustez a futuras amenazas de seguridad.
1 comentarios
Opinión de Hacker News
Creo que el equipo de SEAR y Apple está haciendo un trabajo realmente excelente en la seguridad de iOS, y quiero reconocerlo mucho
Es admirable el esfuerzo por integrar funciones de seguridad desde el nivel de hardware hasta toda la pila completa, y además siguen estudiando exploits ITW (ataques en el mundo real) y cómo bloquearlos
Por ejemplo, introdujeron funciones como PPL, pero si llegan a la conclusión de que no es perfecta, la descartan sin problema y buscan nuevas técnicas
Apple, por su estructura de integración vertical, lo tiene mucho más fácil que Android para hacer esto. En Android hay que pedir colaboración a fabricantes de hardware (QC, Mediatek) y pasar por varias etapas como el kernel de Linux, AOSP, LLVM upstream, etc.
Pointer Authentication Codes (PAC) también es un buen ejemplo. Apple lo implementó con una actitud de “hagámoslo nosotros”, manteniendo su propio branch de LLVM, y de hecho corrigió el problema reforzando ataques basados en ITW
Yo compro productos de Apple no solo porque su seguridad y privacidad sean buenas, sino porque Apple impulsa estas funciones con pasión y sinceridad aunque no sea algo que tenga que hacer obligatoriamente para ganar dinero
En la práctica, va más allá del marketing: reclutan a los mejores hackers de la comunidad de jailbreaking para su equipo de seguridad y traen innovaciones como Private Relay, correo privado, trusted compute y multi-party inference
Claro que también hay problemas evidentes en la actitud hipócrita de Apple. Por ejemplo, permitir VPN (excepto para el tráfico que va a servidores de Apple), o los valores predeterminados de privacidad garantizada (excepto cosas como Wi‑Fi Calling o “journaling suggestions”) dejan bastante que desear
En la práctica hay una condición implícita de que no estás protegido frente a Apple y algunos socios de telecomunicaciones, pero aun así Google me da más la sensación de “es seguro para todos excepto para Google o los compradores de anuncios de Google”, así que creo que Apple va muy por delante
Incluso después de un esfuerzo de ingeniería enorme, en iMessage todavía quedan rutas por las que código sospechoso puede ejecutarse en el kernel, y por eso siguen existiendo exploits 0-click
Otra ventaja de este tipo de esfuerzo es que, si una ruta de código se ejecuta хотя бы una vez en un procesador nuevo donde Apple reforzó la seguridad, la seguridad de toda la plataforma mejora de forma natural
En teoría, incluso problemas difíciles de detectar solo con análisis estático pueden capturarse más fácilmente, y además se puede obtener un entendimiento más profundo que un simple crash
En realidad Google podría haber añadido MTE desde hace algunos años, pero no quiso forzar su aplicación a los OEM como parte de la certificación de Android
Es básicamente la misma historia que ya vimos con las actualizaciones del sistema operativo
La razón por la que Apple se preocupa por la seguridad hoy no es solo proteger a los usuarios
En esencia, es para dificultar que los usuarios ejecuten software no autorizado o hagan cosas como jailbreak, y así mantener el monopolio de la App Store
Al final, prioriza los intereses de la empresa por encima de los intereses de los usuarios
Cada vez que leo sobre la seguridad de iOS siempre me sorprende su complejidad
Hay muchas capas: nivel de hardware, nivel de kernel, varias técnicas de sandboxing, etc.
Me pregunto si esta estructura es una “solución provisional encima de un diseño que asumía confianza del pasado”
Si se rediseñara desde cero, me pregunto si podría hacerse más simple, y si existe algún sistema operativo que realmente haya sido diseñado así
Las vulnerabilidades son inevitables mientras una plataforma tenga que soportar diversos casos de uso
La forma de responder a eso es precisamente la defensa en profundidad (defence-in-depth)
iOS se basa en macOS, y macOS en NeXT, con raíces en Unix
Fue diseñado desde el principio teniendo en cuenta una baja confianza en el usuario
Con el tiempo también cambió el grado de confianza en el usuario, y últimamente se ha vuelto cada vez más complejo por funciones de red siempre conectadas y nuevas amenazas posteriores a Spectre
Sobre si esto es un parche sobre decisiones históricas de diseño: yo diría que sí
Es el resultado de esfuerzos por compensar las limitaciones del modelo de seguridad de Unix y de la programación de sistemas basada en C
Si se diseñara de nuevo desde cero, se podría reducir la complejidad aplicando cosas como capability architecture, pero en la práctica casi todo eso existe solo en ámbitos académicos o de hobby por el problema de compatibilidad con POSIX
Si te vas a un modelo completamente nuevo, tendrías que desechar de inmediato la mayoría de los programas Unix existentes, así que su adopción real es extremadamente difícil
seL4 es una estructura de microkernel rápida, muy segura y verificada formalmente
Destaca por su alto nivel de control de acceso, soporte para máquinas virtuales y más
Artículo explicativo sobre la arquitectura del microkernel seL4
Pero como le falta “todo lo demás”, creo que está más cerca de la investigación que de un sistema operativo real
Creo que quizá se podrían intentar ambas cosas
Incluso la “seguridad de hardware” tiene sus propios supuestos de confianza, y al final no deja de ser software cableado; mientras más aumenta la complejidad, más crece también la posibilidad de bugs
En la keynote de Ivan Krstić en la Hexacon de esta vez, Apple anunció que reforzará su programa de bug bounty
Blog oficial relacionado
Me pregunto si ya resolvieron el problema de conexiones en texto plano (sin cifrar) que todavía ocurrían durante actualizaciones regulares o al ejecutar apps
Material de referencia relacionado