LSPromise

Una cadena de explotación completa que permite la escalada de privilegios desde una aplicación local no confiable hasta root/kernel. No implica corrupciones de memoria ni condiciones de carrera, por lo que los atacantes no necesitan realizar complejos heap spraying ni evadir mitigaciones contra vulnerabilidades de corrupción de memoria como KASLR, MTE o CFI, lo que hace que esta cadena de explotación tenga una tasa de éxito del 100% en dispositivos vulnerables.

Probado en Pixel 10 con la versión oficial inicial de Android 17. Ten en cuenta que no funciona en Pixel 6a y este problema también puede ocurrir en otros dispositivos que ejecutan árboles de kernel 6.1.xxx-android14 debido a otro bug en estos kernels.

Uso: Instala la app KernelSU, abre esta app, haz clic en "Run userspace exploit" y luego en "Run kernel exploit and load KernelSU". Después de una explotación exitosa, KernelSU se activará y podrás usarlo para otorgar acceso root a otras apps. Problema conocido: Si ya ejecutaste el exploit del kernel y quieres ejecutarlo de nuevo, necesitas reiniciar el dispositivo.

Grabación de pantalla: haz clic aquí

Writeup

La cadena está compuesta por dos vulnerabilidades distintas: una es un 0-day en el servicio Telecom, mientras que la otra es un 1-day del kernel que se divulgó hace 3 meses. Pero los dispositivos AOSP y Pixel (excepto aquellos que ejecutan versiones beta de QPR) siguen siendo vulnerables al momento de escribir esto.

Entrando en system_server

La primera vulnerabilidad de la cadena es un simple bug lógico introducido en Android 17. Se origina de un cambio descabellado, que añade el siguiente código a InCallController.java:

        PackageManager packageManager = mContext.getPackageManager();
        Context userContext = mContext.createContextAsUser(userHandle,
                0 /* flags */);
        PackageManager userPackageManager = userContext != null ?
                userContext.getPackageManager() : packageManager;

        List<ResolveInfo> entries;
        entries = userPackageManager.queryIntentServices(
                serviceIntent,
                PackageManager.GET_META_DATA | PackageManager.MATCH_DISABLED_COMPONENTS);
        for (ResolveInfo entry : entries) {
            ServiceInfo serviceInfo = entry.serviceInfo;

            if (serviceInfo != null) {
                boolean isMetaFlag = serviceInfo.metaData != null &&
                        serviceInfo.metaData.getBoolean(
                                "android.telecom.CLASS_EXISTENCE_CHECK", false);
                if (isMetaFlag && !serviceClassExists(serviceInfo, userHandle)) {
                    continue;
                }
            }
        }

El método serviceClassExists() relevante se define de la siguiente manera:

    /**
     * Verifies that the class for a given ServiceInfo exists within its package.
     * This prevents a system crash if a service is declared in the manifest but its
     * class was not included in the compiled code.
     * @param serviceInfo The ServiceInfo of the service to check.
     * @param userHandle The user under which to check for the service.
     * @return {@code true} if the class exists, {@code false} otherwise.
     */
    private boolean serviceClassExists(ServiceInfo serviceInfo, UserHandle userHandle) {
        Log.i(this, "serviceClassExists check");
        try {
            Context packageContext = mContext.createPackageContextAsUser(
                    serviceInfo.packageName,
                    Context.CONTEXT_INCLUDE_CODE | Context.CONTEXT_IGNORE_SECURITY, userHandle);
            ClassLoader classLoader = packageContext.getClassLoader();
            Class.forName(serviceInfo.name, false, classLoader);
            return true;
        } catch (NameNotFoundException | ClassNotFoundException e) {
            Log.w(this, "Skipping InCallService: class not found for " + serviceInfo.name);
            return false;
        } catch (Exception e) {
            Log.e(this, e, "Error checking for existence of " + serviceInfo.name);
            return false;
        }
    }

Esta es la vulnerabilidad más increíble que he visto jamás. El código usa Context.CONTEXT_INCLUDE_CODE | Context.CONTEXT_IGNORE_SECURITY para cargar código desde una app arbitraria; aunque parece haber algunas medidas destinadas a prevenir la ejecución arbitraria de código, como pasar false a Class.forName() para evitar la inicialización de clases, la app aún puede declarar un AppComponentFactory personalizado que se invoca cuando se llama a getClassLoader().

Por otro lado, el bug existe en InCallController.java, que es parte del paquete com.android.server.telecom en lugar de com.android.phone. Vale la pena señalar que el paquete declara android:sharedUserId="android.uid.system" y android:process="system" en AndroidManifest.xml, por lo que se ejecuta en el proceso system_server, uno de los procesos de userspace más privilegiados en Android. Por lo tanto, ahora tenemos la capacidad de ejecutar código Java arbitrario dentro de system_server.

Es una sorpresa que incluso un ingeniero de Google pueda cometer un error tan grande en la era de la IA. Lo encontramos y lo reportamos al Android Security Team el 23 de julio de 2026. Nos dijeron que era un duplicado. Google ha cambiado el boletín de seguridad mensual a una publicación trimestral, lo que puede explicar por qué la vulnerabilidad no se corrigió 3 meses después del lanzamiento de Android 17.

A la vulnerabilidad se le asignó CVE-2026-49881 y se corrigió en septiembre de 2026 mediante Remove serviceClassExists logic to address security vulnerability.

Entrando en la pila de red

El primer bug nos permite escalar privilegios a system, pero aún estamos lejos de root. Un root completo requiere al menos UID 0 y no estar restringido por SELinux.

Ahora es el momento de presentar el 1-day del kernel: las vulnerabilidades DirtyFrag. Los principios subyacentes no se explicarán aquí; consulta el writeup del reportero original. Hay 2 variantes: CVE-2026-43500 requiere RxRPC, que está deshabilitado para los Android Generic Kernels; CVE-2026-43284 requiere xfrm-ESP y es explotable en Android. Sin embargo, SELinux prohíbe que las apps no confiables usen esa característica:

# Privileged netlink socket interfaces.
neverallow { appdomain -network_stack }
    domain:{
        netlink_tcpdiag_socket
        netlink_nflog_socket
        netlink_xfrm_socket
        netlink_audit_socket
        netlink_dnrt_socket
    } *;

Los únicos dominios permitidos son system_server, network_stack y netd. Para explotar DirtyFrag, los atacantes primero deben comprometer uno de los procesos privilegiados en la lista blanca.

Combina los dos bugs. Mientras que el bug de userspace nos permite ejecutar código Java dentro de system_server, SELinux también prohíbe que system_server cargue bibliotecas nativas desde /data o mapee memoria ejecutable anónima. Esto hace imposible usar código nativo, aumentando la dificultad de la explotación. Por lo tanto, sería preferible ejecutar código dentro de com.android.networkstack, que puede cargar código nativo desde nuestro APK y tiene privilegios suficientes para explotar DirtyFrag.

Afortunadamente, system_server es el proceso donde se ejecuta ActivityManager. ActivityManager almacena los handles de IApplicationThread de cada proceso de app en un mapa de Java y, dado que nos ejecutamos como el mismo proceso de ActivityManager, podemos recuperarlos usando reflexión de Java. Con esto, podemos enviar comandos arbitrarios a com.android.networkstack para forzarlo a cargar nuestro código. Para más información sobre este truco, consulta mi exploit anterior para CVE-2026-0091.

Entrando en el kernel

DirtyFrag permite sobrescribir archivos de solo lectura. Este es un primitivo poderoso en el mundo Linux, porque podemos sobrescribir el binario su que tiene el bit SUID. Sin embargo, no tenemos su en el mundo Android. Nos referimos al exploit de polygraphene para DirtyPipe para convertir DirtyFrag en ejecución de código del kernel en Android:

1. Parcheamos libc.so, libc++.so y /vendor/lib64/libstagefright_aidl_bufferpool2.so a través de DirtyFrag. libstagefright_aidl_bufferpool2.so está etiquetado como dominio vendor_file, por lo que no se puede acceder desde el proceso de la pila de red. La solución es parchear primero /apex/com.android.runtime/bin/crash_dump64, ejecutarlo, y una vez que transicionemos al dominio crash_dump, podemos abrir libstagefright_aidl_bufferpool2.so.
2. Crea y destruye un proceso huérfano para desencadenar la ejecución de código en el proceso init. Debido a que libc++.so está parcheado, nuestro código se ejecuta como UID 0 con el dominio init. Luego ejecutamos /vendor/bin/modprobe para transicionar al dominio .