CVE-2019-2215 (Bad Binder) — Analisi dell'exploit

Questo repository è un piccolo progetto di test per lo studio della vulnerabilità
CVE-2019-2215 (Bad Binder) e per la scrittura di un prototipo funzionante di exploit per Android con una semplice interfaccia grafica in Kotlin/Jetpack Compose.

In questo README:

Descrivo la preparazione dell'ambiente e l'esecuzione del prototipo di exploit.
Analizzo le fasi principali dello sfruttamento di CVE-2019-2215 e le associo a funzioni specifiche nel codice C.
Elenco separatamente le difficoltà incontrate lungo il percorso e come le ho risolte.

APK pronto (GitHub Actions)

Nel repository è configurato un workflow GitHub Actions che, ad ogni push/PR, compila il progetto con ./gradlew assembleDebug e pubblica il badbinder-debug.apk come artefatto.

È possibile scaricarlo così:

Aprire la scheda Actions nel repository.
Selezionare l'esecuzione del workflow desiderata.
In fondo alla pagina, trovare la sezione Artifacts e prelevare l'archivio badbinder-debug-apk con l'APK compilato.

Questo è stato fatto per comodità, nel caso si voglia semplicemente testare l'applicazione senza dover configurare un ambiente locale.

Breve descrizione della vulnerabilità

CVE-2019-2215 è un Use-After-Free (UAF) nel sottosistema IPC Binder del kernel Android.

In parole povere:

nel kernel esiste una struttura struct binder_thread che descrive un thread che esegue chiamate Binder;
questa struttura può essere rilasciata (free), ma con una certa sequenza di chiamate rimane ancora nelle liste di attesa (waitqueue);
successivamente il kernel tenta di lavorare con la memoria già rilasciata in remove_wait_queue, aprendo uno scenario UAF classico;
se si sceglie con cura l'ambiente e le allocazioni successive, è possibile costringere il kernel a leggere/scrivere a indirizzi arbitrari, e quindi ottenere privilegi kernel e poi root in userspace.

Un'analisi teorica più dettagliata l'ho fatta basandomi su:

1. Preparazione dell'ambiente e lancio del prototipo di exploit

1.1. Scelta e preparazione del dispositivo virtuale

Per il compito è stato consigliato di utilizzare un AVD con immagine Android 10.0 (Q) x86_64.
Io ho fatto quanto segue:

In Android Studio ho creato un AVD (dispositivo Pixel, Android 10 (Q), x86_64).
Mi sono assicurato che nell'immagine fosse abilitato Binder e che ci fosse il dispositivo /dev/binder.
Ho attivato il debugging USB/ADB e ho verificato l'accesso al dispositivo:
```
adb shell
ls -l /dev/binder
```

In questa fase mi sono imbattuto in un fatto spiacevole:
al momento le immagini AVD attuali sono già fornite con un kernel patchato, in cui CVE-2019-2215 è corretta. Cioè, non è realmente possibile ottenere root su un emulatore ufficiale moderno — l'exploit fallisce in fasi successive o semplicemente non fornisce l'elevazione dei privilegi.

Alla fine utilizzo l'AVD come simulatore per riprodurre la logica dell'exploit:

ottengo le stesse sequenze di syscall,
osservo i tentativi di UAF, la leak di indirizzi e il tentativo di sovrascrivere addr_limit,
ma il finale «ottenimento di root» sul kernel attuale e patchato, ovviamente, non funziona (ed è previsto).

Questa è una sfumatura importante: tutto il codice e il report seguente sono didattici, non «da combattimento».

1.2. Compilazione dell'applicazione Android con exploit nativo

Ho realizzato una piccola applicazione Android:

UI in Kotlin + Jetpack Compose,
Parte nativa in C tramite JNI — effettivamente il codice dell'exploit,
comunicazione tra loro tramite callback JNI, in modo che le stringhe dal codice C arrivino direttamente nell'UI.

I passaggi principali:

Ho creato un normale progetto in Android Studio (Kotlin, supporto minimo per Android 10).
Ho collegato NDK e CMake.
Ho aggiunto un file nativo con l'exploit (lo stesso cve-2019-2215.c con le funzioni leak_task_struct, overwrite_addr_limit, ecc.).
In CMakeLists.txt ho aggiunto la build di libcve-2019-2215.so.

In MainActivity:

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

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

Lato Kotlin ho creato ExploitViewModel, che implementa l'interfaccia NativeLogger e accumula tutti i messaggi in un StateFlow<List<String>>. L'UI è sottoscritta a questo flusso e mostra il log in un «terminale».

All'avvio dell'activity chiamo setNativeLogger(viewModel), in modo che il codice nativo riceva l'oggetto a cui inviare le stringhe.

1.3. Esecuzione e scenario d'uso

Compilo e installo l'applicazione:
```
./gradlew installDebug
```
Avvio l'AVD e l'applicazione stessa.
Sullo schermo vedo un «terminale» e un pulsante RUN EXPLOIT.
Al clic:
- Kotlin chiama runNativeExploit() in un thread in background.
- Il codice C inizia a eseguire tutte le fasi dell'exploit e a registrare i passaggi.
- Tramite callback JNI, il log arriva al ViewModel e viene visualizzato nell'UI Compose.

Su un kernel reale vulnerabile, mi aspetterei di vedere alla fine qualcosa come:

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

Sull'emulatore attuale di Android 10 questo, ovviamente, non accade, ma tutto il resto — leak di task_struct, tentativo di sovrascrivere addr_limit, calcolo di cred e kernel_base — funziona come «scenario», che era quanto richiesto per il compito.

2. Analisi delle fasi principali dell'exploit e associazione al codice

Di seguito lo schema logico dell'exploit con riferimento a specifiche funzioni C.

2.1. Scenario generale dell'exploit

Il piano ad alto livello è il seguente:

Creare un UAF sull'oggetto struct binder_thread e usarlo per fare leak dell'indirizzo di task_struct del proprio processo (leak_task_struct).
Con un secondo ciclo UAF e strutture accuratamente preparate, sovrascrivere il campo addr_limit in task_struct (overwrite_addr_limit) — questo rimuove la limitazione tra gli indirizzi user-space e kernel-space per le successive copy_to_user / copy_from_user.
Utilizzando pipe, implementare lettura/scrittura arbitraria di qualsiasi memoria del kernel (arb_read / arb_write).
Con questo, trovare cred del processo corrente e la base del kernel (verifying), quindi:
- disabilitare SELinux (selinux_enforcing = 0),
- sovrascrivere i campi di cred per diventare root e ottenere il set completo di capability (runNativeExploit).

Parallelamente, ho integrato un logger JNI, in modo che tutte queste fasi siano visibili direttamente nell'UI.

2.2. Fase 1 — leak dell'indirizzo di `task_struct` (`leak_task_struct`)

Funzione chiave:

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

Cosa fa la funzione:

Fissa il thread sulla CPU 0 (sched_setaffinity), in modo che il comportamento dell'allocatore del kernel sia più prevedibile. Questo migliora la stabilità dello sfruttamento UAF.

Apre /dev/binder, crea un descrittore epoll:

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

Il descrittore Binder viene registrato in epoll:

epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &event);

Prepara un array struct iovec iov_buffers[IOVEC_N] e alloca memoria:

android-badbinder-demo

Più Popolari

CVE-2019-2215 (Bad Binder) — Analisi dell'exploit

APK pronto (GitHub Actions)

Breve descrizione della vulnerabilità

1. Preparazione dell'ambiente e lancio del prototipo di exploit

1.1. Scelta e preparazione del dispositivo virtuale

1.2. Compilazione dell'applicazione Android con exploit nativo

1.3. Esecuzione e scenario d'uso

2. Analisi delle fasi principali dell'exploit e associazione al codice

2.1. Scenario generale dell'exploit

2.2. Fase 1 — leak dell'indirizzo di `task_struct` (`leak_task_struct`)

android-badbinder-demo

Più Popolari

CVE-2019-2215 (Bad Binder) — Analisi dell'exploit

APK pronto (GitHub Actions)

Breve descrizione della vulnerabilità

1. Preparazione dell'ambiente e lancio del prototipo di exploit

1.1. Scelta e preparazione del dispositivo virtuale

1.2. Compilazione dell'applicazione Android con exploit nativo

1.3. Esecuzione e scenario d'uso

2. Analisi delle fasi principali dell'exploit e associazione al codice

2.1. Scenario generale dell'exploit

2.2. Fase 1 — leak dell'indirizzo di task_struct (leak_task_struct)

2.2. Fase 1 — leak dell'indirizzo di `task_struct` (`leak_task_struct`)