CVE-2019-2215

Use-after-free no driver Binder do kernel Android (drivers/android/binder.c ou drivers/staging/android/binder.c, dependendo da árvore), que permite a um app malicioso local escalar de contexto de aplicação para execução no kernel, com controle total do dispositivo. A falha já havia sido corrigida no upstream do Linux em dezembro de 2017, mas o patch nunca chegou a diversos kernels Android (3.18, 4.4, 4.9) até o boletim de segurança de outubro de 2019 — é um caso clássico de patch gap entre upstream e branches vendor/Android. Importa porque foi explorada in-the-wild antes da divulgação pública, encadeada com uma falha de sandbox do Chrome (CVE-2019-2025) em campanhas atribuídas a spyware comercial.

A vulnerabilidade é um use-after-free (CWE-416) na lógica de gerenciamento de threads do Binder, o mecanismo de IPC do Android usado por praticamente todo app e serviço de sistema para se comunicar entre processos. O driver permite que um processo registre um binder_thread e associe esse thread a uma fila de espera usada pelo epoll (via binder_poll). Quando o ioctl BINDER_THREAD_EXIT é disparado, a estrutura do thread é liberada (kfree), mas a referência que ela mantinha na wait_queue do epoll não era removida corretamente em todos os caminhos de código.

O atacante controla a sequência de chamadas: abre /dev/binder, registra o file descriptor num epoll, e força a liberação do binder_thread enquanto ainda existe uma referência pendente na wait_queue. Quando um evento subsequente dispara a callback associada a essa wait_queue, o kernel acessa memória já liberada, que o atacante pode ter realocado com dados controlados — o clássico primitivo de UAF para escrita/leitura arbitrária e, a partir daí, escalonamento de privilégio no kernel.

O Binder é código extremamente exposto: roda com privilégios de kernel, é acessível a qualquer app sem permissão especial (só precisa abrir /dev/binder, algo que toda aplicação Android faz implicitamente) e processa lógica complexa de referência de objetos entre processos. Isso torna a superfície de ataque grande e o bug relativamente fácil de disparar de dentro de um app comum, sem exigir capacidades de root ou permissões elevadas.

A análise técnica mais detalhada foi publicada pelo Project Zero do Google (pesquisadora Maddie Stone, sob o codinome informal 'Bad Binder'), que demonstrou uma cadeia de exploração completa obtendo execução arbitrária no kernel a partir de um app sandboxed em dispositivo Pixel.

O vetor primário é um aplicativo local malicioso instalado no dispositivo — a descrição oficial já deixa isso explícito. Não há interação do usuário necessária além de ter o app instalado e em execução; o app dispara a sequência de ioctls/epoll para produzir o UAF sem qualquer aviso ou permissão visível ao usuário. A CVSS reflete isso com AV:L (acesso local) e PR:L (privilégio baixo, o de qualquer app comum).

A rota secundária de exploração é encadear esta falha com uma vulnerabilidade separada em um componente exposto à rede (por exemplo um bug de sandbox escape em navegador), permitindo que um atacante remoto obtenha inicialmente execução de código em contexto de app sandboxed via web e depois use o binder UAF para escapar do sandbox e obter privilégio de kernel. Essa foi exatamente a cadeia documentada pelo Project Zero, associada a exploração ativa antes da correção pública, o que motivou a inclusão da CVE no catálogo KEV da CISA.

A exploração não é trivial — exige entender a estrutura interna do binder_thread, técnicas de heap grooming para realocar a memória liberada com dados controlados, e normalmente bypass de KASLR/mitigações de kernel. Ainda assim, existem PoCs públicos (incluindo notas de exploração publicadas por pesquisadores independentes cobrindo kernels 3.4.x e 3.18.x em dispositivos Samsung com Android e LineageOS) e um módulo Metasploit, o que reduz a barreira de reprodução para quem já tem acesso a um app instalável no dispositivo-alvo.

A correção definitiva é aplicar o patch do kernel Android incluído no boletim de segurança de outubro de 2019 e mantê-lo em toda a cadeia de build de firmware — o fornecedor do dispositivo (fabricante do aparelho) precisa distribuir uma atualização de sistema/firmware que incorpore o fix do binder, já que o usuário final não consegue aplicar patch de kernel Android isoladamente sem OTA do fabricante. Em distribuições Linux de propósito geral (Debian, Slackware), o driver binder normalmente não é habilitado por padrão, o que já elimina a exposição — os próprios boletins de segurança do Debian confirmam que o driver não estava habilitado nos kernels empacotados, tratando a CVE como não aplicável naquele contexto, mesmo tendo corrigido a linha de código por precaução em builds que a habilitem.

Para dispositivos Android sem atualização disponível (comum em aparelhos fora do ciclo de suporte do fabricante), não existe mitigação de configuração real — o binder é infraestrutura essencial do sistema operacional e não pode ser desabilitado sem quebrar o funcionamento do Android. O controle compensatório prático é restringir a instalação de aplicativos a fontes confiáveis e usar soluções de gerenciamento de dispositivo (MDM) que bloqueiem instalação de APKs não verificados, reduzindo a chance do vetor primário (app malicioso local). Isso não fecha a falha, apenas reduz a superfície de entrega do exploit.

Não existe mitigação via WAF ou controle de rede, pois a exploração ocorre inteiramente no dispositivo, entre processos locais — filtragem de tráfego de rede não tem visibilidade sobre chamadas ioctl/epoll internas ao binder.

Não há assinatura de rede a procurar, pois a exploração é inteiramente local ao dispositivo — não gera tráfego de rede identificável por si só. Em nível de host, o sinal mais próximo é monitoramento de chamadas ioctl anômalas ao /dev/binder combinadas com registro em epoll seguido de crash ou comportamento inesperado do processo, mas isso exige instrumentação de kernel (auditoria de syscalls, eBPF ou hooks customizados) que a maioria dos dispositivos Android não possui habilitada por padrão. Em ambientes de análise forense de dispositivos comprometidos, crashes recorrentes do processo servicemanager ou do próprio kernel com stack trace apontando para binder_poll/binder_thread_release são indício retrospectivo, mas não constituem uma detecção confiável em tempo real para a maioria dos operadores.