LSPromise

Eine vollständige Exploit-Kette, die eine Privilegieneskalation von einer lokalen, nicht vertrauenswürdigen App bis zu Root/Kernel ermöglicht. Sie beinhaltet keine Speicherkorruptionen oder Race Conditions, sodass Angreifer kein komplexes Heap-Spraying durchführen oder Mitigationen gegen Speicherkorruptions-Schwachstellen wie KASLR, MTE oder CFI umgehen müssen, was diese Exploit-Kette auf verwundbaren Geräten zu einer 100%igen Erfolgsrate macht.

Getestet auf Pixel 10 mit dem offiziellen Android-17-Erstrelease. Beachten Sie, dass es auf Pixel 6a nicht funktioniert und dieses Problem auch auf anderen Geräten auftreten kann, die 6.1.xxx-android14-Kernel-Bäume verwenden, aufgrund eines weiteren Bugs in diesen Kerneln.

Verwendung: Installieren Sie die KernelSU-App, öffnen Sie diese App, klicken Sie auf „Run userspace exploit“ und dann auf „Run kernel exploit and load KernelSU“. Nach einer erfolgreichen Ausnutzung wird KernelSU aktiviert und Sie können es verwenden, um anderen Apps Root-Zugriff zu gewähren. Bekanntes Problem: Wenn Sie den Kernel-Exploit bereits ausgeführt haben und ihn erneut ausführen möchten, müssen Sie das Gerät neu starten.

Bildschirmaufzeichnung: hier klicken

Writeup

Die Kette besteht aus zwei verschiedenen Schwachstellen: eine ist ein 0-Day im Telecom-Dienst, während die andere ein Kernel-1-Day ist, der vor 3 Monaten offengelegt wurde. Aber AOSP- und Pixel-Geräte (außer denen mit Beta-QPR-Versionen) bleiben zum Zeitpunkt des Schreibens verwundbar.

Zugang zu system_server erhalten

Die erste Schwachstelle der Kette ist ein einfacher Logikfehler, der in Android 17 eingeführt wurde. Er stammt aus einer verrückten Änderung, die den folgenden Code zu InCallController.java hinzufügt:

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

Die relevante serviceClassExists()-Methode ist wie folgt definiert:

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

Dies ist die unglaublichste Schwachstelle, die ich je gesehen habe. Der Code verwendet Context.CONTEXT_INCLUDE_CODE | Context.CONTEXT_IGNORE_SECURITY, um Code aus einer beliebigen App zu laden. Obwohl es einige Maßnahmen zu geben scheint, die beliebige Codeausführung verhindern sollen, wie z. B. die Übergabe von false an Class.forName(), um die Klasseninitialisierung zu verhindern, kann die App dennoch eine benutzerdefinierte AppComponentFactory deklarieren, die aufgerufen wird, wenn getClassLoader() aufgerufen wird.

Andererseits existiert der Bug in InCallController.java, das Teil des Pakets com.android.server.telecom und nicht von com.android.phone ist. Es ist erwähnenswert, dass das Paket android:sharedUserId="android.uid.system" und android:process="system" in AndroidManifest.xml deklariert, sodass es im system_server-Prozess läuft, einem der privilegiertesten Userspace-Prozesse in Android. Wir haben nun also die Fähigkeit, beliebigen Java-Code innerhalb von system_server auszuführen.

Es ist eine Überraschung, dass selbst ein Google-Ingenieur im KI-Zeitalter einen so großen Fehler machen kann. Wir haben ihn gefunden und am 23. Juli 2026 dem Android-Sicherheitsteam gemeldet. Sie sagten uns, es sei ein Duplikat. Google hat das monatliche Sicherheitsbulletin auf eine vierteljährliche Veröffentlichung umgestellt, was erklären könnte, warum die Schwachstelle 3 Monate nach der Veröffentlichung von Android 17 nicht behoben wurde.

Der Schwachstelle wurde CVE-2026-49881 zugewiesen und sie wurde im September 2026 durch Entfernen der serviceClassExists-Logik zur Behebung der Sicherheitslücke behoben.

Zugang zum Netzwerk-Stack erhalten

Der erste Bug erlaubt uns eine Privilegieneskalation zu system, ist aber noch weit von Root entfernt. Ein vollständiges Root erfordert mindestens UID 0 und darf nicht durch SELinux eingeschränkt sein.