CVE-2013-6282
Patch now. It under exploitation confirmed by CISA and has a working public exploit.
Apply updates per vendor instructions.
Summary
Falha de validação de endereço nas funções get_user e put_user do kernel Linux, usadas internamente por syscalls para copiar dados entre espaço de usuário e kernel em plataformas ARM v6k e v7. Uma aplicação local sem privilégios pode passar um endereço de kernel arbitrário como se fosse um ponteiro de usuário e conseguir ler ou escrever memória do kernel, resultando em escalonamento de privilégio local. Importa porque foi explorada in the wild contra dispositivos Android (app de root 'vroot') antes mesmo da correção e da atribuição pública da CVE.
Technical detail
get_user e put_user são macros/rotinas de baixo nível em arch/arm/lib/getuser.S e putuser.S que o kernel usa para ler e escrever valores vindos de ponteiros fornecidos por processos em userspace (ex.: argumentos de syscalls). Em arquiteturas ARM que usam o modelo de 'domains' de memória (CONFIG_CPU_USE_DOMAINS), o hardware valida automaticamente se o endereço pertence ao domínio de usuário. Em builds sem esse mecanismo — comuns em ARMv6k/v7, inclusive na maioria dos kernels Android da época — essa validação de hardware não existe, e antes do patch as rotinas assembly não faziam nenhuma verificação de software equivalente.
How it’s exploited
O código malicioso simplesmente passa, como argumento a uma chamada que internamente usa get_user/put_user (via syscall), um endereço apontando para dentro do espaço de endereçamento do kernel em vez de um endereço de usuário válido. Sem a checagem, a rotina lê ou grava naquele endereço como se fosse legítimo, dando ao atacante uma primitiva arbitrária de leitura e escrita de memória do kernel. CWE-20 (Improper Input Validation), classificação usada pela CISA no KEV.
A exploração documentada (app 'vroot' distribuída para root de dispositivos Android em out/nov de 2013, e posteriormente encapsulada em módulo Metasploit por fi01/cubeundcube) usa a primitiva de leitura para localizar em memória os endereços de commit_creds e ptmx_fops (via kallsyms), e a primitiva de escrita para sobrescrever esses pontos e executar código com uid 0.
Pré-requisito real: é preciso executar código nativo local no dispositivo — uma aplicação instalada e executada pelo usuário ("crafted application", conforme a descrição oficial). Não há vetor de rede. O vetor CVSS informado (AV:N) reflete a metodologia de scoring genérica aplicada retroativamente pelo NVD a vulnerabilidades antigas de kernel, e não corresponde ao mecanismo real de exploração, que é estritamente local (AV:L seria mais fiel ao comportamento observado).
Versions
How to protect
A correção está no commit 8404663f81d212918ff85f493649a7991209fa04, que adiciona a macro check_uaccess para validar o endereço contra current_thread_info()->addr_limit antes de get_user/put_user operarem, quando CONFIG_CPU_USE_DOMAINS não está habilitado. Isso entrou no kernel mainline na versão 3.5.5.
Para distribuições de kernel embarcado — o caso típico afetado, Android — a correção depende do fabricante do dispositivo fazer backport do patch para o branch de kernel usado naquele SoC/firmware específico, já que esses kernels raramente seguem o mainline diretamente. Não há uma lista pública consolidada de quais builds Android por fabricante já incorporaram o backport; a única forma confiável de verificar é conferir se o patch do commit citado está presente no código-fonte do kernel do dispositivo.
Não há mitigação de configuração equivalente que substitua o patch: habilitar CONFIG_CPU_USE_DOMAINS reintroduz a validação via hardware e reduz a exposição nos builds sem o fix, mas altera o modelo de proteção de memória do kernel e tem impacto de desempenho — não é um controle recomendado como substituto permanente da atualização, apenas um dado técnico sobre por que alguns builds eram menos expostos.
How to detect
Não há assinatura de rede a procurar, pois a exploração é inteiramente local. Sinais indiretos incluem: instalação/execução de aplicativos Android desconhecidos que carregam bibliotecas nativas (.so) com nomes gerados aleatoriamente e depois as removem do disco imediatamente após o carregamento — padrão usado pelo módulo Metasploit e por ferramentas de root da época (ex.: 'vroot'); processos userspace realizando syscalls repetidas com padrões de leitura/escrita sequencial de memória consistentes com scanning de kallsyms; e presença de artefatos correspondentes ao EDB-40975 ou variantes do exploit original. Sem instrumentação de auditoria de syscalls ou EDR no próprio dispositivo, não há sinal confiável de exploração passada.