CVE-2011-1823
Priorize a correção. Ela está sob exploração confirmada pelo CISA.
Apply updates per vendor instructions.
Resumo
Falha de escalonamento de privilégios local no daemon vold (Volume Manager Daemon) do Android, presente nas versões 2.x anteriores à 2.3.4 e na 3.0 (Honeycomb). Qualquer processo local capaz de enviar mensagens a um socket PF_NETLINK usado pelo vold consegue corromper memória do daemon, que roda como root, e obter shell com privilégios totais. Ficou famosa como a base do exploit público "GingerBreak", amplamente usado para rootear aparelhos — e por isso mesmo entrou tardiamente (2022) no catálogo KEV da CISA, não por exploração recente, mas por uso histórico documentado em malware de root (Lotoor).
Detalhamento técnico
O vold escuta eventos de kernel (uevents) via um socket PF_NETLINK e os trata como confiáveis, sem verificar a origem do processo que os enviou. O método vulnerável é DirectVolume::handlePartitionAdded, em DirectVolume.cpp. Ele lê o parâmetro PARTN do evento netlink, converte para inteiro com atoi() e usa esse valor, decrementado de 1, como índice no array mPartMinors[MAX_PARTITIONS], com MAX_PARTITIONS = 4.
O código só valida o limite superior (part_num > MAX_PARTITIONS), nunca o inferior. Como part_num é um int assinado totalmente controlado pelo atacante (via evt->findParam("PARTN")), um valor negativo passa a checagem e produz um índice negativo em mPartMinors[part_num - 1] = minor. Isso é uma escrita fora dos limites do array (CWE-189, classificação da CISA; na prática também um out-of-bounds write) que corrompe memória adjacente na estrutura do processo vold.
O atacante controla dois graus de liberdade: o offset da escrita (via part_num, o índice negativo) e o valor escrito (via MINOR, também extraído do evento netlink). O exploit público GingerBreak usa essa dupla liberdade para sobrescrever entradas da GOT (Global Offset Table) do vold — por exemplo, o ponteiro de strcmp() ou atoi() — substituindo-o pelo endereço de system(). Ao disparar uma chamada subsequente a essa função
Como é explorada
O vetor é estritamente local: o processo atacante precisa conseguir enviar (ou, mais precisamente, ter contexto para provocar) eventos no socket PF_NETLINK que o vold monitora. O próprio código do exploit GingerBreak documenta essa restrição no comentário-fonte: "It only works if called from adb shell since we need group log" — ou seja, na prática a exploração pública exigia execução via shell ADB (grupo log), não uma app comum instalada sem esse contexto, embora variantes tenham sido adaptadas para funcionar a partir de apps maliciosas com as permissões certas.
A cadeia de exploração observada (GingerBreak) funciona assim: o binário malicioso é copiado para /data/local/tmp com dois nomes (boomsh e sh), envia eventos netlink forjados simulando adição de partição com PARTN negativo, provoca a escrita fora dos limites para sobrescrever a GOT do vold e redirecionar uma chamada de função para system(), e usa isso para remontar /data com permissões de escrita e ajustar o setuid do shell copiado, obtendo uma shell root persistente. É exploração local, sem interação do usuário (UI:N) e sem necessidade de bypass de ASLR/DEP sofisticado — o próprio autor descreve que
Versões
Como se proteger
A correção definitiva é atualizar para Android 2.3.4 ou superior (ramo 2.x) ou para a versão do Honeycomb que incorpora os commits de correção no AOSP para system/vold, system/core e system/netd, que adicionam a validação de limite inferior ausente em handlePartitionAdded e reforçam o tratamento de mensagens netlink no vold. Isso praticamente não é aplicável hoje: trata-se de uma falha de mais de uma década em versões do Android já fora de suporte há muito tempo (Gingerbread/Honeycomb), então o cenário real de exposição atual é dispositivos legados, sistemas embarcados baseados em AOSP antigo, ou firmwares customizados que nunca receberam o patch.
Como paliativo em dispositivos que não podem ser atualizados, não há configuração de runtime que neutralize a falha sem o patch de código — restringir o acesso a shell ADB/depuração USB e a instalação de apps de fontes não confiáveis reduz a superfície de quem pode chegar ao socket netlink do vold, mas não elimina o vetor caso alguma app já instalada tenha as permissões necessárias.
Não funciona como mitigação: apenas remover o app "GingerBreak" ou detectar sua assinatura binária — a vulnerabilidade está no vold do sistema, não no exploit específico; variantes recompiladas ou adaptadas (como relatado por usuários que precisaram ajustar offsets para outros dispositivos/Honeycomb) contornam detecção baseada só naquele binário.
Como detectar
Não há assinatura de rede confiável, pois o vetor é inteiramente local (mensagens PF_NETLINK dentro do próprio dispositivo, sem tráfego externo). Em nível de host, indícios documentados do exploit público incluem a presença de binários nomeados boomsh e sh em /data/local/tmp com permissões setuid-root incomuns (04711), processos vold morrendo ou reiniciando de forma anômala coincidindo com criação desses arquivos, e crashes do vold em logs do kernel/logcat próximos a eventos de criação/remoção de partição forjados. Como a técnica pode ser recompilada com offsets diferentes por dispositivo, a ausência desses artefatos específicos não garante que uma variante adaptada não tenha sido usada.