CVE-2017-1000253
Prioriza la corrección. Ella está bajo explotación confirmada por CISA y tiene prueba de concepto pública.
Apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable.
Resumen
Falha no carregador de binários ELF do kernel Linux (função load_elf_binary) permite que um usuário local sem privilégios escale para root ao executar um binário PIE (Position Independent Executable) instalado com SUID root, causando corrupção de memória por sobreposição entre o segmento de dados do binário e a área de pilha (stack). É conhecida como parte da série de falhas relatadas pela Qualys Research Labs sobre 'stack clash', e afeta praticamente todas as distribuições Linux que rodavam kernels antigos sem o patch de abril de 2015 aplicado.
Detalle técnico
O problema está em load_elf_binary(), no carregamento de executáveis PIE. Com CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE habilitado e a estratégia padrão de alocação de endereços top-down, o kernel tenta mapear o binário PIE imediatamente abaixo de mm->mmap_base — a mesma região reservada como 'gap' entre a pilha (stack) e o restante do espaço de endereçamento do processo. O carregador calcula o mapeamento do primeiro segmento PT_LOAD levando em conta apenas parte do binário, mas não reserva espaço suficiente para os segmentos PT_LOAD subsequentes. Resultado: o primeiro segmento é mapeado abaixo de mmap_base como esperado, mas os segmentos seguintes acabam mapeados por cima do que deveria ser o gap de segurança entre stack e heap/binário, permitindo colisão de memória (CWE-787/CWE-119, escrita fora dos limites por corrupção de layout de memória).
O commit de correção (a87938b2e246b81b4fb713edb371a9fa3c5c3c86), de abril de 2015, ajusta esse cálculo de espaço, mas na época não foi tratado como correção de segurança — apenas como bugfix de estabilidade. Isso significa que ele não foi necessariamente backportado para todos os branches estáveis e de longo prazo (LTS) das distribuições, mesmo tendo sido incorporado ao mainline e a alguns kernels 3.10.x (a partir do 3.10.77, maio de 2015). Só em 2017, quando a Qualys Research Labs analisou a cadeia de bugs relacionados a 'stack clash' em múltiplos sistemas operacionais, o impacto de segurança foi reconhecido e as distribuições passaram a tratar isso como CVE.
O atacante não controla o conteúdo do kernel diretamente; controla o binário PIE que é executado (ou aciona a execução de um binário PIE com bit SUID já presente no sistema) e, em builds de exploit conhecidas, também manipula variáveis de ambiente/argumentos para influenciar o tamanho de pilha usado e forçar a colisão entre as regiões de memória. O resultado é corrupção de memória controlável, usada para escalar privilégios.
Cómo se explota
O vetor é estritamente local: exige acesso de shell (ou execução de código) na máquina alvo com privilégio de usuário comum, e a presença de pelo menos um binário PIE com SUID (ou outro binário privilegiado) que o atacante possa invocar. Não há componente de rede nem de autenticação remota — a CVSS reflete isso com AV:L e PR:L. Diferente de vulnerabilidades de escalonamento de privilégio 'zero-clique', aqui o atacante precisa conseguir executar o binário-alvo e, em muitos PoCs documentados publicamente, manipular o tamanho da pilha (por exemplo, via limites de recursos ou variáveis de ambiente grandes) para deslocar o layout de memória e induzir a colisão entre o segmento de dados carregado e a região da stack.
A exploração foi demonstrada publicamente por pesquisadores (Qualys) como parte da divulgação da família de bugs 'Stack Clash', que afetou diversos sistemas operacionais e mecanismos de proteção de stack. Existem PoCs públicos documentados. A CVE está no catálogo KEV da CISA, o que indica exploração confirmada em cenários reais — plataformas multiusuário (servidores compartilhados, hosts de hospedagem, ambientes de containers com kernel compartilhado sem isolamento adequado) são o cenário de maior risco, já que dependem de isolamento entre usuários locais não confiáveis.
O resultado final da exploração bem-sucedida é execução de código com privilégios do binário SUID afetado — tipicamente root — a partir de uma sessão de usuário sem privilégios. Não há evidência, nas fontes analisadas, de exploração remota nem de exigência de configuração exótica adicional: o pré-requisito central é sistema multiusuário rodando kernel vulnerável com algum binário PIE privilegiado disponível para o atacante executar.
Versiones
Cómo protegerse
A correção definitiva é atualizar o kernel para uma versão que incorpore o commit a87938b2e246b81b4fb713edb371a9fa3c5c3c86 ou os patches equivalentes distribuídos pelos fornecedores. Para Red Hat Enterprise Linux, os pacotes corrigidos incluem: RHEL 7.3 EUS/AUS/TUS — kernel-3.10.0-514.32.3.el7; RHEL 7.2 EUS/AUS — kernel-3.10.0-327.59.3.el7; RHEL 6 — kernel-2.6.32-696.10.3.el6; RHEL 6.7 EUS — kernel-2.6.32-573.48.1.el6 (consulte também RHSA-2017:2797, 2798, 2799 e 2800 para outros branches/arquiteturas não detalhados aqui). Reboot é obrigatório após a atualização, pois a correção está no kernel.
Se a atualização imediata não for viável, não existe mitigação de configuração completa e confiável documentada pelo fornecedor além de reduzir a superfície: remover ou revogar o bit SUID de binários PIE privilegiados que não sejam estritamente necessários, restringir acesso a shell/execução de código a usuários confiáveis, e usar isolamento adicional (namespaces, containers com kernels distintos, virtualização) para separar usuários não confiáveis do kernel host vulnerável. Esses controles reduzem a probabilidade de exploração, mas não eliminam a falha subjacente no carregador ELF.
Mito a evitar: acreditar que apenas atualizar a versão 'estável' mais recente do pacote de distribuição resolve — como o patch original de 2015 não foi tratado como correção de segurança em muitos ramos LTS, é preciso confirmar explicitamente que o kernel instalado inclui o backport de segurança de 2017 (não apenas alguma versão pós-abril de 2015), verificando o changelog do pacote ou a versão mínima indicada pelo fornecedor específico.
Cómo detectar
Não há assinatura de rede a procurar, já que a exploração é inteiramente local — não há tráfego de rede associado ao ataque em si. Em nível de host, sinais possíveis incluem: crashes ou core dumps inesperados envolvendo binários SUID/PIE (segmentation faults com padrões de mapeamento de memória anômalos), tentativas repetidas de execução de um binário privilegiado combinadas com manipulação de limites de recursos (ulimit -s) ou variáveis de ambiente de tamanho anormal antes da execução, e logs de auditoria (auditd/execve) mostrando execução de binários SUID por usuários não administrativos seguida de escalonamento de sessão para root sem passagem por sudo/su legítimos.
Não há um indicador único e confiável de tentativa de exploração dessa CVE documentado nas fontes consultadas — a ausência de assinatura clara é, em si, uma informação relevante: detecção depende de monitoramento comportamental genérico de escalonamento de privilégio local, não de uma assinatura específica desta falha.