CVE-2019-2215 (Bad Binder) — Analyse des Exploits

Dieses Repository ist ein kleines Testprojekt zur Untersuchung der Schwachstelle
CVE-2019-2215 (Bad Binder) und zum Schreiben eines funktionierenden Exploit-Prototyps für Android mit einer einfachen grafischen Oberfläche in Kotlin/Jetpack Compose.

In der README:

1. Beschreibe ich die Einrichtung der Umgebung und den Start des Exploit-Prototyps.
2. Analysiere ich die Hauptschritte der Ausnutzung von CVE-2019-2215 und ordne sie den spezifischen Funktionen im C-Code zu.
3. Liste ich separat die Schwierigkeiten auf, auf die ich unterwegs gestoßen bin, und wie ich sie gelöst habe.

---

Fertiges APK (GitHub Actions)

Im Repository ist ein GitHub Actions Workflow eingerichtet, der bei jedem Push/PR das Projekt mit dem Befehl ./gradlew assembleDebug erstellt und das fertige badbinder-debug.apk als Artefakt veröffentlicht.

Herunterladen kann man es so:

1. Öffnen Sie den Reiter Actions im Repository.
2. Wählen Sie den gewünschten Workflow-Lauf aus.
3. Finden Sie unten auf der Seite den Abschnitt Artifacts und holen Sie das Archiv badbinder-debug-apk mit dem erstellten APK.

Dies wurde für den Komfort gemacht, falls man die App einfach testen möchte, ohne eine lokale Umgebung aufzusetzen.

---

Kurz zur Schwachstelle

CVE-2019-2215 ist ein Use-After-Free (UAF) in der Binder-IPC-Subsystem des Android-Kernels.

Vereinfacht:

• im Kernel existiert eine Struktur struct binder_thread, die einen Thread beschreibt, der Binder-Aufrufe ausführt;
• diese Struktur kann freigegeben (free) werden, bleibt aber bei einer bestimmten Aufruffolge weiterhin in den Wartelisten (waitqueue);
• später versucht der Kernel, mit dem bereits freigegebenen Speicher in remove_wait_queue zu arbeiten, was ein klassisches UAF-Szenario eröffnet;
• wenn man die Umgebung und die folgenden Allokationen sorgfältig auswählt, kann man den Kernel dazu bringen, an beliebigen Adressen zu lesen/schreiben, und dann Kernel-Berechtigungen und anschließend Root im Userspace zu erlangen.

Eine detailliertere theoretische Analyse habe ich anhand folgender Materialien durchgeführt:

1. https://cloudfuzz.github.io/android-kernel-exploitation/
2. https://dayzerosec.com/blog/2019/11/07/analyzing-androids-cve-2019-2215-dev-binder-uaf.html
3. https://hernan.de/blog/tailoring-cve-2019-2215-to-achieve-root/

---

1. Einrichtung der Umgebung und Start des Exploit-Prototyps

1.1. Auswahl und Vorbereitung des virtuellen Geräts

Laut Aufgabenstellung wird empfohlen, ein AVD mit Android 10.0 (Q) x86_64-Image zu verwenden.
Ich habe Folgendes gemacht:

1. In Android Studio ein AVD erstellt (Pixel-Gerät, Android 10 (Q), x86_64).
2. Sichergestellt, dass im Image Binder aktiviert ist und das Gerät /dev/binder vorhanden ist.
3. USB/ADB-Debugging aktiviert und den Zugriff auf das Gerät überprüft:

   adb shell
   ls -l /dev/binder
   

An diesem Punkt bin ich auf eine unangenehme Tatsache gestoßen:
die aktuellen AVD-Images werden bereits mit einem gepatchten Kernel ausgeliefert, in dem CVE-2019-2215 geschlossen ist. Das heißt, man kann auf dem aktuellen offiziellen Emulator tatsächlich kein Root erlangen – der Exploit scheitert in späteren Phasen oder gewährt einfach keine Rechteerhöhung.

Letztendlich verwende ich das AVD als Trainingsumgebung zur Nachbildung der Exploit-Logik:

• Ich erhalte dieselben Sequenzen von Systemaufrufen,
• beobachte die UAF-Versuche, Adressleckage und den Versuch, addr_limit zu überschreiben,
• aber die finale „Root-Erlangung“ auf dem aktuellen, gepatchten Kernel funktioniert natürlich nicht (und das ist zu erwarten).

Dies ist ein wichtiger Hinweis: Der gesamte Code und der Bericht unten sind zu Lehrzwecken, nicht „kampferprobt“.

---

1.2. Erstellung der Android-App mit nativen Exploit

Ich habe eine kleine Android-App erstellt:

• UI in Kotlin + Jetpack Compose,
• Native-Teil in C über JNI – der eigentliche Exploit-Code,
• Kommunikation zwischen ihnen über einen JNI-Callback, sodass Strings aus dem C-Code direkt in die UI gelangen.

Die wichtigsten Schritte:

1. Ein normales Projekt in Android Studio erstellt (Kotlin, minimale Unterstützung für Android 10).

2. NDK und CMake eingebunden.

3. Eine native Datei mit dem Exploit hinzugefügt (die Datei cve-2019-2215.c mit den Funktionen leak_task_struct, overwrite_addr_limit usw.).

4. In CMakeLists.txt die Erstellung von libcve-2019-2215.so hinzugefügt.

5. In MainActivity:

   init {
       System.loadLibrary("cve-2019-2215")
   }
   
   external fun runNativeExploit(): String
   external fun setNativeLogger(logger: NativeLogger)
   

6. Auf der Kotlin-Seite ein ExploitViewModel erstellt, das das Interface NativeLogger implementiert und alle Nachrichten in einem StateFlow<List<String>> sammelt. Das UI abonniert diesen Flow und zeigt das Log in einem „Terminal“ an.

Beim Start der Activity rufe ich setNativeLogger(viewModel) auf, damit der native Code ein Objekt erhält, an das er Strings senden kann.

---

1.3. Start und Nutzungsszenario

1. Ich erstelle und installiere die App:

   ./gradlew installDebug
   

2. Starte das AVD und die App.

3. Auf dem Bildschirm sehe ich ein „Terminal“ und einen Button RUN EXPLOIT.

4. Beim Drücken:

   • Kotlin ruft runNativeExploit() im Hintergrundthread auf.
   • Der C-Code beginnt, alle Exploit-Phasen auszuführen und die Schritte zu protokollieren.
   • Über den JNI-Callback gelangt das Log in das ViewModel und wird im Compose-UI angezeigt.

Auf einem echten verwundbaren Kernel würde ich am Ende etwas erwarten wie:

[+] Selinux changed: Permissive now.
[+] Root escalation successful!
uid=0(root)...

Auf dem aktuellen Android 10-Emulator passiert das natürlich nicht, aber der Rest – die Leckage von task_struct, der Versuch, addr_limit zu überschreiben, das Berechnen von cred und kernel_base – funktioniert als „Szenario“, was für die Aufgabe ausreicht.

---

2. Analyse der Hauptschritte des Exploits und Zuordnung zum Code

Unten ist das logische Schema des Exploits mit Verweis auf die spezifischen C-Funktionen.

2.1. Allgemeines Exploit-Szenario

Der grobe Plan ist:

1. Ein UAF auf dem Objekt struct binder_thread erzeugen und nutzen, um die Adresse der task_struct des eigenen Prozesses zu leaken (leak_task_struct).
2. Mit einem zweiten UAF-Zyklus und sorgfältig ausgewählten Strukturen das Feld addr_limit in der task_struct überschreiben (overwrite_addr_limit) – dies hebt die Einschränkung zwischen User-Space- und Kernel-Space-Adressen für spätere copy_to_user / copy_from_user auf.
3. Mit Pipes beliebiges Lesen/Schreiben von Kernel-Speicher implementieren (arb_read / arb_write).
4. Damit die cred des aktuellen Prozesses und die Kernel-Basis finden (verifying), dann:
   • SELinux deaktivieren (selinux_enforcing = 0),
   • die cred-Felder überschreiben, um Root zu werden und volle Capabilities zu erhalten (runNativeExploit).

Parallel dazu habe ich einen JNI-Logger integriert, damit all diese Phasen direkt im UI sichtbar sind.

---

2.2. Phase 1 – Leckage der task_struct-Adresse (leak_task_struct)

Die Schlüsselfunktion:

void leak_task_struct() {
    android_log("[*] Starting leak_task_struct...");

    cpu_set_t cpu_set;
    CPU_ZERO(&cpu_set);
    CPU_SET(0, &cpu_set);
    ret = sched_setaffinity(0, sizeof(cpu_set), &cpu_set);
    assert(ret >= 0);
    ...
}

Was die Funktion macht:

1. Fixiert den Thread auf CPU 0 (sched_setaffinity), um das Verhalten des Kernel-Allokators vorhersagbarer zu machen. Dies verbessert die Stabilität der UAF-Ausnutzung.
2. Öffnet /dev/binder, erstellt einen epoll-Deskriptor:

   fd = open("/dev/binder", O_RDONLY);
   epfd = epoll_create(1000);
   

   Der Binder-Deskriptor wird beim epoll registriert: