CVE-2019-2215 (Bad Binder) — Analyse de l'exploit

Ce dépôt est un petit projet de test pour étudier la vulnérabilité
CVE-2019-2215 (Bad Binder) et écrire un prototype fonctionnel d'exploit pour Android avec une interface graphique simple en Kotlin/Jetpack Compose.

Dans ce README, je :

Décris la préparation de l'environnement et l'exécution du prototype d'exploit.
Analyse les étapes principales de l'exploitation de CVE-2019-2215 et les associe aux fonctions spécifiques dans le code C.
Énumère séparément les difficultés rencontrées en cours de route et comment je les ai résolues.

APK prêt à l'emploi (GitHub Actions)

Le dépôt contient un workflow GitHub Actions qui, à chaque push/PR, compile le projet avec la commande ./gradlew assembleDebug et publie le fichier badbinder-debug.apk comme artefact.

Vous pouvez le télécharger ainsi :

Ouvrez l'onglet Actions du dépôt.
Sélectionnez l'exécution du workflow souhaitée.
En bas de la page, trouvez la section Artifacts et récupérez l'archive badbinder-debug-apk contenant l'APK compilé.

Cela a été fait pour plus de commodité, si vous souhaitez simplement tester l'application sans configurer un environnement local.

Bref aperçu de la vulnérabilité

CVE-2019-2215 est une Use-After-Free (UAF) dans le sous-système IPC Binder du noyau Android.

En simplifiant :

dans le noyau, il existe une structure struct binder_thread qui décrit un thread effectuant des appels Binder ;
cette structure peut être libérée (free), mais avec une séquence d'appels particulière, elle reste encore dans les listes d'attente (waitqueue) ;
plus tard, le noyau tente de travailler avec la mémoire déjà libérée dans remove_wait_queue, ce qui ouvre un scénario UAF classique ;
en ajustant soigneusement l'environnement et les allocations suivantes, on peut forcer le noyau à lire/écrire à des adresses arbitraires, puis obtenir les privilèges noyau, et ensuite le root dans l'espace utilisateur.

Une analyse théorique plus détaillée a été réalisée à partir des ressources suivantes :

1. Préparation de l'environnement et exécution du prototype d'exploit

1.1. Choix et préparation du périphérique virtuel

Selon les instructions, il est recommandé d'utiliser un AVD avec l'image Android 10.0 (Q) x86_64.
J'ai fait ce qui suit :

Dans Android Studio, j'ai créé un AVD (périphérique Pixel, Android 10 (Q), x86_64).
Je me suis assuré que l'image inclut Binder et qu'il y a le périphérique /dev/binder.
J'ai activé le débogage USB/ADB et vérifié l'accès au périphérique :
```
adb shell
ls -l /dev/binder
```

À cette étape, j'ai rencontré un fait désagréable :
actuellement, les images AVD à jour sont déjà livrées avec un noyau patché, dans lequel CVE-2019-2215 est corrigée. Autrement dit, il ne sera pas possible d'obtenir réellement un root sur un émulateur officiel moderne — l'exploit échoue à des stades ultérieurs ou ne permet tout simplement pas l'élévation de privilèges.

En fin de compte, j'utilise l'AVD comme simulateur pour reproduire la logique de l'exploit :

j'obtiens les mêmes séquences d'appels système,
j'observe les tentatives d'UAF, la fuite d'adresses et la tentative de réécriture de addr_limit,
mais l'obtention finale du « root » sur un noyau à jour et patché ne fonctionne évidemment pas (ce qui est attendu).

C'est une nuance importante : tout le code et le rapport ci-dessous sont éducatifs, pas « opérationnels ».

1.2. Compilation de l'application Android avec l'exploit natif

J'ai créé une petite application Android :

UI en Kotlin + Jetpack Compose,
Partie native en C via JNI — le code de l'exploit lui-même,
la communication entre les deux se fait via un callback JNI, afin que les chaînes du code C arrivent directement dans l'UI.

Les principales étapes :

Création d'un projet standard dans Android Studio (Kotlin, prise en charge minimale d'Android 10).
Connexion du NDK et de CMake.
Ajout d'un fichier natif contenant l'exploit (le fameux cve-2019-2215.c avec les fonctions leak_task_struct, overwrite_addr_limit, etc.).
Dans CMakeLists.txt, ajout de la compilation de libcve-2019-2215.so.

Dans MainActivity :

init {
    System.loadLibrary("cve-2019-2215")
}

external fun runNativeExploit(): String
external fun setNativeLogger(logger: NativeLogger)

Côté Kotlin, création d'un ExploitViewModel qui implémente l'interface NativeLogger et stocke tous les messages dans un StateFlow<List<String>>. L'UI est abonnée à ce flux et affiche le journal dans un « terminal ».

Au lancement de l'activité, j'appelle setNativeLogger(viewModel) pour que le code natif reçoive un objet auquel envoyer des chaînes.

1.3. Lancement et scénario d'utilisation

Compilation et installation de l'application :
```
./gradlew installDebug
```
Lancement de l'AVD et de l'application elle-même.
À l'écran, je vois un « terminal » et un bouton RUN EXPLOIT.
Appui sur le bouton :
- Kotlin appelle runNativeExploit() dans un thread d'arrière-plan.
- Le code C commence à exécuter toutes les étapes de l'exploit et journalise les actions.
- Via le callback JNI, le journal parvient au ViewModel et s'affiche dans l'UI Compose.

Sur un noyau vulnérable réel, je m'attendrais à voir à la fin quelque chose comme :

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

Sur l'émulateur Android 10 actuel, cela ne se produit évidemment pas, mais tout le reste — fuite de task_struct, tentative de réécriture de addr_limit, calcul de cred et de kernel_base — s'exécute comme un « scénario », ce qui était requis pour l'exercice.

2. Analyse des principales étapes de l'exploit et correspondance avec le code

Ci-dessous, le schéma logique de l'exploit avec les fonctions C correspondantes.

2.1. Scénario général de l'exploit

Le plan de haut niveau est le suivant :

Créer une UAF sur l'objet struct binder_thread et l'utiliser pour faire fuir l'adresse de task_struct de son propre processus (leak_task_struct).
Avec un deuxième cycle UAF et des structures soigneusement conçues, réécrire le champ addr_limit dans task_struct (overwrite_addr_limit) — cela supprime la restriction entre les adresses espace utilisateur et espace noyau pour les opérations ultérieures copy_to_user / copy_from_user.
En utilisant des pipes, implémenter une lecture/écriture arbitraire de toute mémoire noyau (arb_read / arb_write).
Grâce à cela, trouver cred du processus courant et la base du noyau (verifying), puis :
- désactiver SELinux (selinux_enforcing = 0),
- réécrire les champs de cred pour devenir root et obtenir l'ensemble complet des capacités (runNativeExploit).

En parallèle, j'ai intégré un journaliseur JNI pour que toutes ces étapes soient visibles directement dans l'UI.

2.2. Étape 1 — Fuite de l'adresse de `task_struct` (`leak_task_struct`)

Fonction clé :

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

Ce que fait la fonction :

android-badbinder-demo

Populaires

CVE-2019-2215 (Bad Binder) — Analyse de l'exploit

APK prêt à l'emploi (GitHub Actions)

Bref aperçu de la vulnérabilité

1. Préparation de l'environnement et exécution du prototype d'exploit

1.1. Choix et préparation du périphérique virtuel

1.2. Compilation de l'application Android avec l'exploit natif

1.3. Lancement et scénario d'utilisation

2. Analyse des principales étapes de l'exploit et correspondance avec le code

2.1. Scénario général de l'exploit

2.2. Étape 1 — Fuite de l'adresse de `task_struct` (`leak_task_struct`)

android-badbinder-demo

Populaires

CVE-2019-2215 (Bad Binder) — Analyse de l'exploit

APK prêt à l'emploi (GitHub Actions)

Bref aperçu de la vulnérabilité

1. Préparation de l'environnement et exécution du prototype d'exploit

1.1. Choix et préparation du périphérique virtuel

1.2. Compilation de l'application Android avec l'exploit natif

1.3. Lancement et scénario d'utilisation

2. Analyse des principales étapes de l'exploit et correspondance avec le code

2.1. Scénario général de l'exploit

2.2. Étape 1 — Fuite de l'adresse de task_struct (leak_task_struct)

2.2. Étape 1 — Fuite de l'adresse de `task_struct` (`leak_task_struct`)