- tachy0n es un caso de publicación de un exploit de jailbreak 0day para iOS 13.0~13.5
- Este bug es una condición de carrera del syscall
lio_listio llamada Lightspeed, y se aprovecha como una vulnerabilidad de LPE (elevación de privilegios) en el kernel
- Varios proyectos de jailbreak como Spice y unc0ver usaron esta vulnerabilidad en la práctica, y aquí se explican la técnica de explotación y los métodos de hacking relacionados con problemas de gestión de memoria
- Después de que este exploit se hiciera público, Apple aplicó un parche e introdujo pruebas de regresión, además de reforzar en gran medida un aislamiento más sólido de objetos del kernel (Zone, kheap, etc.) y las funciones de protección de punteros
- Desde iOS 14 en adelante, el entorno de jailbreak y de exploits de kernel cambió de forma fundamental, y ya no existen exploits de kernel públicos
0. Introducción
- tachy0n es un exploit antiguo que funciona en iOS 13.0 a 13.5
- Se publicó como 0day el 23 de mayo de 2020 en unc0ver v5.0.0, y Apple lo parchó de emergencia apenas una semana después
- Esta vulnerabilidad ya había sido usada antes como 1day, por lo que se considera un caso significativo desde el punto de vista de las técnicas de explotación
- Es un texto que explica en detalle el origen de la vulnerabilidad y cómo fue descubierta
1. Lightspeed
- La vulnerabilidad en cuestión es el bug Lightspeed (CVE-2020-9859, etc.) presentado por Synacktiv, en el que ocurre una condición de carrera al liberar la memoria del contexto de I/O asíncrono del syscall
lio_listio
- Ajustando el timing de las operaciones de I/O para crear una condición de double free de memoria, es posible aprovechar dos liberaciones de objetos para superponer varios objetos en la misma región de memoria
- Se aprovecha en el exploit la estructura de asignación dinámica de memoria de la zona
kalloc.16 del kernel
- En esencia, es un método que aumenta la probabilidad de éxito repitiendo la carrera múltiples veces
2. Spice
- Este exploit fue usado en el pasado por el jailbreak Spice creado por team Jake Blair
- En racoon y en la app se implementaron distintas variantes del exploit, y el objetivo principal era la falsificación de puertos mach
- En iOS 11.x era fácil eludir PAN (Protection Against Null dereference), y se intentaron diversas técnicas de hacking combinándolo con un infoleak del kernel y un sandbox escape
- En el caso de racoon, debido a las restricciones de acceso a IOKit, se usó OSUnserializeXML para crear el objeto objetivo del spray en esa zona del kernel
- También se describen diferencias de detalle y avances técnicos posteriores sobre sysctl_procargsx, fugas de memoria no inicializada del kernel, políticas de sandbox y más
3. unc0ver
- Cuando se aplicó en unc0ver, la estructura del exploit fue diseñada para funcionar en una amplia gama de SoC, incluyendo A8~A13
- Se rastrea la superposición y el overlap de objetos OSData, y en el momento adecuado se liberan/asignan los objetos deseados para controlar la región de memoria
- Usando objetos del kernel como IOMemoryDescriptor, se expone la dirección del búfer de datos controlado por el usuario y se implementa lectura/escritura directa en el kernel
- Se aprovechan adecuadamente debilidades de las políticas del asignador de memoria del kernel en iOS 13, como el bypass de zone_require
- La implementación detallada de toda la estructura del exploit puede verse en el repositorio público de GitHub (tachy0n)
4. Impacto posterior
- La publicación de un exploit 0day causó un gran impacto en la comunidad de seguridad y en Apple
- Apenas 4 horas después de publicarse el exploit real, Project Zero y Synacktiv ya habían realizado análisis detallados y tomado medidas de respuesta
- Tras el parche, Apple añadió pruebas de regresión formales para esta vulnerabilidad en XNU, entre otras acciones, cambiando hacia una estrategia de seguridad reforzada de raíz
- Desde iOS 14 se introdujeron cambios masivos que elevaron mucho la dificultad de desarrollar exploits, como la separación de áreas de allocation, object secure guard, PAC (Pointer Authentication Code) y la estructura kheap
- Ahora la estrategia del exploit en sí misma es más importante, y la brecha entre la información pública y la investigación privada se ha ampliado, al punto de que no existen exploits de kernel públicos para iOS 17~18
5. Conclusión
- Es un caso que muestra claramente cómo el campo de la seguridad y el jailbreak en iOS cambió de forma dramática en 5 años
- Ofrece una perspectiva sobre cómo cambiaron la comunidad de jailbreak/exploits, los investigadores y la dirección técnica de Apple
- La época en que se compartía IL y se asumían desafíos ya quedó en el pasado, y desde iOS 14 en adelante el intercambio de información sobre exploits se ha reducido notablemente
Referencias y contacto
- El código fuente relacionado y la información detallada pueden consultarse en el sitio web personal de Siguza y en el repositorio público de GitHub
2 comentarios
Aunque el hardware de Apple es excelente, su software está lleno de restricciones pensadas para atar al usuario.
Incluso si solo quieres que una app que tú mismo hiciste y compilaste funcione únicamente en tu propio dispositivo, necesitas una suscripción de 100 dólares.
Si eres desarrollador y usas apps open source pequeñas o medianas que compilas por tu cuenta para usarlas,
en vez de tener que hacer jailbreak con vulnerabilidades y hacer sideload en un dispositivo de Apple, es más fácil simplemente usar Android.
Comentarios de Hacker News
Menciona que SockPuppet ya se había usado antes para un jailbreak en la época de iOS 12, y que incluso después de que Ned Williamson de Project Zero lo reportó a Apple y se corrigió en iOS 12.3, volvió a aparecer en iOS 12.4
Probablemente Apple hizo un fork de XNU en una rama aparte y dejó fuera ese parche, y el problema de fondo fue que no había ninguna prueba de regresión para este tipo de vulnerabilidades nuevas o ya conocidas
Yo mismo automatizé con pruebas de regresión algunas vulnerabilidades 1-day conocidas y al ejecutarlas encontré vulnerabilidades de inmediato
Me pregunto si en otros proyectos de código abierto como Linux, FreeBSD, OpenWRT u OpenSSH también ejecutan pruebas de regresión de vulnerabilidades antiguas sobre nuevas versiones
Si cada vulnerabilidad se escribiera en forma automatizada y hubiera condiciones para asignar recursos en CI para ejecutarlas, creo que el beneficio sería bastante grande
Comparte que hace 20 años, cuando estaba en la universidad, hizo voluntariado en QA para Mozilla y había cientos de casos de pruebas de regresión
La mayoría eran bugs de rendering/layout y del motor de JS, y al crear casos de prueba minimizados se podían agregar de inmediato al pipeline de CI
Los bugs son inevitables, pero lo peor es desperdiciar tiempo y dinero cuando reaparecen bugs que ya se habían corregido, y cree que las organizaciones que se preocupan por la calidad necesariamente invierten mucho en pruebas de regresión
Por desgracia, también hay muchas organizaciones que ignoran QA o intentan resolverlo solo mediante subcontratación, sin prestarle verdadera atención
No entiende cómo Apple no tenía pruebas de regresión para temas de jailbreak
Desde antes, en Mozilla y otros lugares, se construyeron excelentes entornos de QA y CI/CD con herramientas como Tinderbox y Bugzilla, y pensaba que este enfoque era común desde antes de que se popularizara el concepto de DevOps, pero se dio cuenta bastante tarde de que en realidad no era así
Había miles de casos de prueba y cree que era Sqlite
Añade que, si no se hace backport del parche, es muy probable que tampoco se haga backport de esa prueba
Al final, la ley de Conway también se aplica tal cual entre seguridad y desarrollo de funciones
Por eso, incluso en organizaciones con buenas pruebas de regresión en sus procesos de build/release, es muy probable que los temas de seguridad se queden fuera por la estructura organizacional interna
expresa la opinión de que agencias de inteligencia (G10, Rusia, China, Corea del Norte, etc.) y muchos grupos privados sin duda lo hacen de esta manera
lo compara con estar hablando con un amigo en un idioma extranjero y al momento siguiente pasar a un tema altamente especializado como neurocirugía o física nuclear, quedándote totalmente en blanco
Le recordó cuando antes intentó interpretar una conversación sobre reparaciones en una acería
Le da pena que el jailbreak haya desaparecido; aunque no es que sacara demasiado provecho práctico a su iPad con jailbreak, disfrutaba mucho el simple hecho de tenerlo
Ahora le gustaría instalar una app de tethering, UTM o una solución de JIT
SideStore le parece prometedor y quiere probarlo, pero su cuenta de Apple fue en el pasado una cuenta de desarrollador de pago y aún tiene 10 app IDs sin expirar, así que eso le impone restricciones para instalar apps de ese tipo
Solo podría hacerlo creando una cuenta nueva o pagando otra vez
Sin jailbreak no había ninguna razón para usar un iPhone como teléfono principal, y al final se pasó a Android
Fue por la época en que Android ya había alcanzado bastante en cuanto a funciones básicas
Pregunta si habría que pasar por un intermediario, si existe un correo o canal oficial, y si no existe el riesgo de que simplemente quede enterrado en el soporte de primer nivel
Como se menciona en el texto, las vulnerabilidades siguen existiendo en comunidades privadas y Apple sigue parchándolas
Lo único que disminuyó fueron los jailbreaks que se hacen públicos