0xbinder/cve_2019_2215Exploit LPE de prueba de concepto para el UAF de Android Binder que utiliza iovec spraying y sobrescritura de addr_limit para lograr lectura/escritura arbitraria del kernel.
Un exploit reescrito de Prueba de Concepto / Escalada de Privilegios Local (LPE) que apunta a CVE-2019-2215, una vulnerabilidad de uso después de liberación (Use-After-Free) en el controlador Android Binder.
He proporcionado la compilación del kernel vulnerable en la carpeta vulnerable_kernel_builds. Crea un emulador AOSP de Android 10 y ejecuta el kernel con él
emulator -show-kernel -no-window -no-snapshot -wipe-data -avd research -kernel bzImage
Para los detalles técnicos del fallo puedes aprenderlos de este increíble blog: https://projectzero.google/2019/11/bad-binder-android-in-wild-exploit.html
La estructura task_struct tiene un miembro importante addr_limit de tipo mm_segment_t. addr_limit almacena la dirección de espacio de usuario válida más alta. addr_limit es parte de struct thread_info o struct thread_struct dependiendo de la arquitectura objetivo. Como estamos tratando con un sistema x86_64, addr_limit se define en struct thread_struct.
Si podemos sobrescribir este addr_limit con 0xFFFFFFFFFFFFFFFF, podremos leer y escribir en cualquier parte de la memoria del espacio del kernel. Para una mejor compatibilidad del exploit en x86_64 y arm64, es mejor establecer addr_limit a 0xFFFFFFFFFFFFFFFE.
struct iovec se utiliza para E/S vectorizada (Vectored I/O), también conocida como E/S dispersa/agrupada (Scatter/Gather I/O). Uno de los principales problemas con struct iovec es que tienen una vida corta. Son asignados por las llamadas al sistema cuando trabajan con los buffers y se liberan inmediatamente cuando vuelven al modo usuario.
Queremos que la estructura iovec permanezca en el kernel cuando activemos la operación unlink y sobrescribamos el puntero iov_base con la dirección de binder_thread->wait.head para obtener lectura y escritura con alcance limitado. Una forma es usar llamadas al sistema como readv, writev en un descriptor de archivo pipe, porque puede bloquearse si la pipe está llena o vacía. pipe es un canal de datos unidireccional que se puede utilizar para comunicación entre procesos. La característica de bloqueo de pipe nos da una ventana de tiempo significativa para corromper la estructura iovec en el espacio del kernel.
De la misma manera, podemos usar la llamada al sistema recvmsg para bloquear pasando MSG_WAITALL como parámetro de bandera.
Como el tamaño de la estructura binder_thread es de 408 bytes, terminará en la caché kmalloc-512.
necesitaremos apilar 25 iovec estructuras para reasignar el bloque colgante. 408 / 16 = 25.5
Como podemos ver en la imagen anterior, iovecStack[10].iov_len y iovecStack[11].iov_base serán sobrescritos.
Entonces, querríamos procesar iovecStack[10], bloquear la llamada al sistema writev y luego activar la operación unlink. Esto asegurará que cuando iovecStack[11].iov_base sea sobrescrito, reanudemos la llamada al sistema writev. Finalmente, filtra el contenido del bloque binder_thread de vuelta al espacio de usuario y lee el puntero task_struct de él.
Para lograr una write con alcance limitado, vamos a usar la llamada al sistema recvmsg para bloquear pasando MSG_WAITALL como parámetro de bandera. La llamada al sistema recvmsg puede bloquearse igual que la llamada al sistema writev.
Como el tamaño de mm_segment_t es de 0x8 bytes, querríamos sobrescribirlo con 0xFFFFFFFFFFFFFFFE, ya que es la dirección de espacio de kernel válida más alta y no provocará el bloqueo del proceso si se produce un fallo de página en un sistema arm64.
