LSPromise

Une chaîne d'exploitation complète qui permet une élévation de privilèges d'une application locale non fiable jusqu'à root/noyau. Elle n'implique ni corruption mémoire ni conditions de course, les attaquants n'ont donc pas besoin d'effectuer de complexes opérations de heap spraying ou de contourner les mitigations contre les vulnérabilités de corruption mémoire telles que KASLR, MTE ou CFI, ce qui rend cette chaîne d'exploitation efficace à 100 % sur les appareils vulnérables.

Testé sur Pixel 10 exécutant la version officielle initiale d'Android 17. Notez que cela ne fonctionne pas sur Pixel 6a et que ce problème peut également se produire sur d'autres appareils exécutant les arbres de noyau 6.1.xxx-android14 en raison d'un autre bug dans ces noyaux.

Utilisation : Installez l'application KernelSU, ouvrez cette application, cliquez sur « Run userspace exploit » puis « Run kernel exploit and load KernelSU ». Après une exploitation réussie, KernelSU sera activé et vous pourrez l'utiliser pour accorder un accès root à d'autres applications. Problème connu : si vous avez déjà exécuté l'exploit du noyau et souhaitez le réexécuter, vous devez redémarrer l'appareil.

Enregistrement d'écran : cliquez ici

Writeup

La chaîne est composée de deux vulnérabilités distinctes : l'une est un 0-day dans le service Telecom, tandis que l'autre est un 1-day du noyau divulgué il y a 3 mois. Mais les appareils AOSP et Pixel (à l'exception de ceux exécutant les versions bêta QPR) restent vulnérables au moment de la rédaction.

Accéder à system_server

La première vulnérabilité de la chaîne est un simple bug logique introduit dans Android 17. Il provient d'un changement fou, qui ajoute le code suivant à 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;
                }
            }
        }

La méthode serviceClassExists() pertinente est définie comme suit :

    /**
     * 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;
        }
    }

C'est la vulnérabilité la plus incroyable que j'aie jamais vue. Le code utilise Context.CONTEXT_INCLUDE_CODE | Context.CONTEXT_IGNORE_SECURITY pour charger du code depuis une application arbitraire ; bien qu'il semble exister certaines mesures destinées à empêcher l'exécution de code arbitraire, comme le passage de false à Class.forName() pour empêcher l'initialisation de la classe, l'application peut toujours déclarer un AppComponentFactory personnalisé qui est invoqué lorsque getClassLoader() est appelé.

D'autre part, le bug existe dans InCallController.java, qui fait partie du package com.android.server.telecom plutôt que de com.android.phone. Il convient de noter que le package déclare android:sharedUserId="android.uid.system" et android:process="system" dans AndroidManifest.xml, il s'exécute donc dans le processus system_server, l'un des processus userspace les plus privilégiés d'Android. Par conséquent, nous avons désormais la capacité d'exécuter du code Java arbitraire à l'intérieur de system_server.

C'est une surprise qu'un ingénieur Google puisse commettre une si grosse erreur à l'ère de l'IA. Nous l'avons trouvée et signalée à l'équipe de sécurité Android le 23 juillet 2026. Ils nous ont dit qu'il s'agissait d'un doublon. Google est passé à une publication trimestrielle du bulletin de sécurité mensuel, ce qui peut expliquer pourquoi la vulnérabilité n'a pas été corrigée 3 mois après la sortie d'Android 17.

La vulnérabilité a reçu le numéro CVE-2026-49881 et a été corrigée en septembre 2026 par Remove serviceClassExists logic to address security vulnerability.

Accéder à la pile réseau

Le premier bug nous permet d'élever les privilèges jusqu'à system, mais nous sommes encore loin de root. Un root complet nécessite au moins l'UID 0 et de ne pas être restreint par SELinux.