Esta semana apareció una investigación que me dejó pensando un rato largo: un investigador de Calif publicó OEMpocalypse, una estrategia genérica para pasar de una app Android común y corriente —sin ningún permiso especial— a root en teléfonos Samsung, Xiaomi, Oppo, OnePlus y Realme. Y no hablamos de prototipos frágiles: hay videos del exploit corriendo en un Galaxy S26 Ultra con bootloader bloqueado, verified boot en verde, firmware de fábrica. Eso, para quien trabaja en seguridad, es el equivalente a ver un truco de magia y darte cuenta de que no hay truco.
La idea es simple y por eso es buena
El investigador partió por algo que a simple vista parece obvio pero que casi nadie explota de forma sistemática: el código que escriben los fabricantes, no el kernel genérico de Linux ni los drivers del chipset. Cada OEM agrega sus propios servicios, daemons y drivers por sobre Android puro (One UI, HyperOS, ColorOS), y ese código es el mismo en toda la línea del fabricante, independiente de si el teléfono lleva Snapdragon, Exynos o Dimensity.
La receta tiene dos etapas. Primero, un error de lógica en algún endpoint IPC del fabricante —un componente exportado que no debía, un check faltante— permite escapar del sandbox untrusted_app hacia un proceso con más privilegios. Segundo, un page Use-After-Free en un driver del kernel del OEM entrega el acceso final a root. Y aquí está lo elegante: un UAF a nivel de página física se ríe de casi todo el hardening moderno. No necesita leak de KASLR, no secuestra flujo de control (adiós CFI), y las protecciones de slab como freelist hardening ni siquiera lo miran, porque el ataque opera por debajo, sobre el page allocator. El mismo código de explotación corrió sin cambios de kernel 5.15 a 6.12.
Lo que me parece más incómodo
El propio autor lo dice, y es la cita que me quedó grabada: ninguno de los bugs del kernel era sutil. Cada uno es un error de ciclo de vida de página que una revisión enfocada del driver habría detectado. O sea, no estamos hablando de vulnerabilidades dignas de un paper académico imposible; estamos hablando de código escrito sin pensar que alguien hostil lo iba a llamar.
Y la excusa típica del fabricante —»el driver está protegido por SELinux, solo un daemon confiable puede hablarle»— también cae, porque la superficie IPC de userspace del propio OEM es la puerta de entrada. Selinux bien configurado no sirve de nada si tu propia capa de servicios tiene un bug de lógica que permite cruzar el dominio.
Mi lectura, desde el lado defensor
Si administras infraestructura como yo, esto es un buen recordatorio de que el hardening genérico tiene un piso, y ese piso es la calidad del código propietario que va encima. Podemos blindar kernels, activar CFI, actualizar monthly patches, pero si el fabricante mete drivers que mapean páginas del kernel a userspace sin auditar el ciclo de vida, la superficie está igual. La recomendación del autor es directamente que los OEM auditen cualquier driver que haga ese tipo de mapeo, y no lo dudo.
Para el usuario final la lección es más aburrida pero igual de válida: instala las actualizaciones de seguridad apenas lleguen. Estas cadenas dependen de varios bugs independientes sin parchear al mismo tiempo; cada bulletin mensual mata partes de la cadena. Y mientras tanto, una app sin permisos declarados podría estar esperando en la tienda. Esa es la parte que no me deja dormir tan tranquilo con mi Galaxy.
Fuente de inspiración: OEMpocalypse Now: A Generic Exploitation Strategy from Android untrusted app to root
