Ataque BTR usa Spectre-v2 para vazar hash de root no Linux

Um grupo de pesquisadores da Vrije Universiteit Amsterdam (VUSec) e da Scuola Superiore Sant’Anna apresentou o ataque BTR (Branch Target Reuse), uma variante do Spectre-v2 que explora entradas antigas do preditor de saltos deixadas para trás por código gerado em tempo de execução. Em testes de laboratório, dois exploits contra o kernel Linux recuperaram o hash da senha de root em questão de minutos, em máquinas Intel com as mitigações padrão ativas.

A divulgação pública ocorreu em 29 de setembro de 2026, junto do artigo técnico aceito na ACM CCS 2026, conferência marcada para 15 a 19 de novembro em Haia, nos Países Baixos. O trabalho é assinado por Sander Wiebing e Yuhui Zhu (primeiros autores em pé de igualdade), Alessandro Biondi e Cristiano Giuffrida.

O que diferencia o BTR de ataques especulativos anteriores é o alvo: em vez de treinar um salto indireto a partir de outro contexto, ele reaproveita a previsão deixada pelo próprio salto, depois que o código apontado por ele foi liberado e substituído. O resultado é o que os autores descrevem como um primitivo de “execução transiente de uso após liberação”, e que atinge motores JIT de navegadores, máquinas virtuais e do próprio kernel.

Contexto: por que motores JIT entram na conta

Compiladores just-in-time (JIT) geram código de máquina enquanto o programa roda — navegadores com JavaScript, runtimes gerenciados com bytecode, o kernel Linux com filtros BPF. Esse código é constantemente alocado, reescrito e descartado, comportamento que, do ponto de vista do processador, é código automodificável (SMC, na sigla em inglês).

As CPUs modernas tratam esse caso: há mecanismos que garantem que, depois de uma reescrita, a execução arquitetural enxergue sempre os bytes novos. O que os pesquisadores mostram é que essa garantia não se estende ao preditor de saltos indiretos — as entradas do Branch Target Buffer (BTB) sobrevivem ao descarte do código ao qual se referiam.

Quando o motor JIT reutiliza a mesma região de memória para compilar algo novo — agora sob controle do atacante —, a previsão obsoleta continua lá. O processador pode especular um salto para o endereço antigo e executar transitoriamente as instruções novas a partir de um deslocamento que o desenvolvedor nunca previu, inclusive no meio de uma instrução. Nada disso fica visível no estado arquitetural, mas deixa rastro mensurável no cache.

Esse é o mesmo princípio que sustenta a família Spectre desde 2018, e o Plugged Ninja já cobriu episódios anteriores, como o ataque Spectre v2 que atingiu sistemas Linux em CPUs Intel em 2024. A novidade aqui é o vetor: um ataque in-place, sem necessidade de treinar um ramo diferente e sem depender de nenhuma falha de memória no software.

Como o ataque BTR funciona na prática

O alvo escolhido para a exploração completa foi o cBPF, o BPF clássico do Linux, e a escolha não é acidental. Diferentemente do eBPF, que exige privilégios, o cBPF está disponível para usuários sem privilégios via Linux Socket Filtering e, principalmente, via seccomp, usado por padrão em contêineres. Seu comportamento de recompilação também é previsível, o que facilita forçar a reutilização de regiões de memória.

A cadeia montada pelos pesquisadores combina etapas já conhecidas da literatura: quebra do KASLR, construção de um conjunto de despejo de cache em L3, localização de uma huge page compartilhada para servir de canal Flush+Reload e, então, o vazamento byte a byte. Para chegar ao hash, o exploit percorre estruturas do kernel por encadeamento de ponteiros a partir de init_task até o task_struct do processo su, caminha pelas tabelas de página e procura o prefixo root: nas páginas do heap.

Os autores testaram duas variantes. A primeira roda contra a configuração padrão do Ubuntu 24.04 (kernel 6.14.0-27) e usa um gadget desalinhado. A segunda ataca uma configuração endurecida, com constant blinding do cBPF habilitado, defesa que existe justamente para impedir que o atacante plante constantes úteis no código gerado — e que o BTR contorna usando constantes implícitas, como deslocamentos de salto.

Números medidos e hardware testado

Vale separar duas taxas que costumam ser confundidas. O primitivo de reutilização, medido isoladamente, chega a 5,7 KB/s em Raptor Cove e 5,4 KB/s em Lion Cove. Já a cadeia completa, com todo o custo do canal lateral, fica em 8 bytes por segundo no primeiro exploit e 10 bytes por segundo no segundo — pouco, e ainda assim suficiente, porque o hash é pequeno e a busca é dirigida.

A caracterização microarquitetural do primitivo foi feita em cinco plataformas: os dois processadores Intel acima, um AMD Ryzen 9 7950X (Zen 4), um Broadcom BCM2712 do Raspberry Pi 5 (Cortex-A76) e um Google Tensor G3 (Cortex-X3). Todas se mostraram suscetíveis ao reaproveitamento de entradas obsoletas do BTB, com capacidades bem diferentes: enquanto as microarquiteturas Intel ficam na casa das centenas de entradas controláveis, Zen 4 e Cortex-X3 passam de 4.000.

Aqui entra uma distinção importante, e que algumas coberturas não deixam clara: o comportamento de hardware aparece em Intel, AMD e ARM, mas os exploits ponta a ponta contra o kernel são Intel. Os pesquisadores excluíram o AMD desse cenário porque a implementação atual do AutoIBRS no Linux desativa por completo a previsão de saltos indiretos dentro do kernel. No ARM, o caminho de retorno do cBPF é mais complexo e reduz as oportunidades de exploração.

Correções, CVEs e divergência de gravidade

Duas CVEs foram atribuídas pelo time de segurança do kernel Linux:

• CVE-2026-64507 — referente à emissão de IBPB na alocação do JIT de BPF. A Red Hat publicou pontuação CVSS v3.1 preliminar de 5,5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), classificada sob CWE-515 (canal de armazenamento encoberto).
• CVE-2026-64508 — referente ao endurecimento do BPF contra JIT spraying. A Red Hat atribuiu CVSS v3.1 de 6,7 (AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H).

Há um ponto que merece atenção de quem for priorizar a correção. O vetor publicado pela Red Hat para a CVE-2026-64508 indica privilégios altos (PR:H), enquanto o modelo de ameaça descrito no artigo pressupõe um atacante local sem privilégios, usando cBPF via seccomp — disponível por padrão. Da mesma forma, a mitigação sugerida pela Red Hat, kernel.unprivileged_bpf_disabled=1, atua sobre a chamada bpf() e o eBPF; ela não cobre filtros cBPF anexados por seccomp ou por socket, que são exatamente o caminho usado no exploit. Essa divergência ainda não foi reconciliada publicamente, e a recomendação segura é tratar a atualização do kernel como a correção efetiva, não o sysctl.

Quanto às mitigações já aplicadas, os mantenedores do kernel integraram uma defesa para x86 que dispara um IBPB em todos os núcleos quando um programa cBPF reutiliza uma região previamente executada de cBPF ou eBPF, além de desencorajar essa reutilização como otimização — e vale independentemente de o IBT estar habilitado. A Oracle seguiu outro caminho no GraalVM, randomizando a posição do code cache do JIT. A Mozilla avaliou mitigações com IBPB no Firefox, mas priorizou concluir o isolamento de site; a Apple sinalizou preferência semelhante para o WebKit, e a ARM considerou que a complexidade de exploração não justificava novas mitigações de kernel.

O que isso muda, e o que não muda

O mérito técnico do trabalho é derrubar uma premissa confortável. Até aqui, o único primitivo transiente baseado em código automodificável era restrito ao x86 e dependia de uma janela de coerência de cache curtíssima, o que sustentava a leitura de que ataques desse tipo seriam impraticáveis em motores JIT reais. O BTR mostra o contrário, e em três motores distintos.

Também há valor defensivo direto, porque a avaliação das contramedidas é granular: FineIBT sozinho não resolve; combinado com constant blinding oferece proteção forte, mas que os próprios autores classificam como não à prova de futuro, já que mudanças no JIT podem reabrir o vetor. IBPB e retpoline seletivo são eficazes, ao custo de complexidade e desempenho. Um detalhe útil para quem planeja parque de máquinas: Lion Cove é a primeira geração Intel em que o IBT não permite nenhuma instrução transiente antes da verificação do endbr64 — em Raptor Cove, uma instrução ainda passa.

As limitações, por outro lado, são relevantes e devem conter o alarme. O ataque exige execução de código local, não funciona remotamente e não entrega execução de código nem escrita em memória: é vazamento de informação. A montagem da cadeia é trabalhosa, e boa parte do tempo medido é gasta localizando a huge page compartilhada — algo que varia com a memória instalada. Nos outros dois motores avaliados o cenário é menos favorável: no SpiderMonkey os pesquisadores confirmaram a viabilidade e construíram prova de conceito, e no GraalVM demonstraram a fuga de sandbox em princípio, mas nenhum dos dois chegou a exploit ponta a ponta. Até o momento não há relato público de uso do BTR fora de ambiente de pesquisa.

A consequência estratégica de médio prazo é a mais incômoda. Como observam os autores, nenhuma CPU atual mantém o preditor de saltos sincronizado com o código efetivamente presente na memória. Enquanto isso não mudar em silício, cada motor JIT terá de resolver o problema por conta própria, com mitigações que custam desempenho — e ambientes multi-inquilino, contêineres e funções serverless são os que mais sentem esse custo.

Recomendações práticas

• Atualize o kernel. As correções das CVE-2026-64507 e CVE-2026-64508 já estão integradas; aplique o kernel mais recente fornecido pela sua distribuição e reinicie.
• Verifique o estado das mitigações com cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 e confirme a versão em uso com uname -r.
• Aplique atualizações de firmware e microcódigo do fabricante da placa ou do servidor, já que parte das defesas de Spectre-v2 depende delas.
• Priorize hosts que executam código de terceiros: nós de contêiner multi-inquilino, runners de CI/CD, plataformas de função como serviço e qualquer máquina com shell compartilhado.
• Atualize runtimes e navegadores, em particular GraalVM, que recebeu a randomização do code cache, e Firefox, cuja estratégia depende do avanço do isolamento de site.
• Não conte com detecção por indicadores. Canais laterais microarquiteturais não deixam IoC confiável. O controle efetivo é redução de superfície: limitar quem executa código arbitrário no host e manter o kernel atualizado.
• Consulte os avisos oficiais da sua distribuição antes de definir a janela de manutenção: as páginas de CVE trazem o estado por versão de pacote.

Conclusão

O BTR não é uma falha que exija resposta de emergência na madrugada: precisa de acesso local, não executa código e já tem correção disponível. Mas é um resultado de pesquisa consistente, que elimina uma suposição de projeto compartilhada por praticamente todos os motores JIT em uso e que, no caminho, derruba uma defesa específica — o constant blinding do cBPF — que vinha sendo tratada como barreira suficiente.

Três frentes merecem acompanhamento: se os fabricantes de CPU passarão a invalidar entradas do BTB em operações de código automodificável, mudança de hardware que levaria anos para alcançar o parque instalado; se o custo de desempenho do IBPB no caminho do cBPF se mostrará aceitável em produção; e se a técnica será estendida a motores JIT de navegador com exploração completa, cenário em que a exposição deixaria de exigir acesso local. A apresentação no CCS 2026, em novembro, deve trazer detalhes sobre essas direções.

Fontes e referências

• BleepingComputer — “New Spectre v2 attack variant leaks Linux root password hash in minutes”, por Bill Toulas, 29 de setembro de 2026: bleepingcomputer.com
• VUSec — Página oficial do projeto “Branch Target Reuse”: vusec.net/projects/btr
• Sander Wiebing, Yuhui Zhu, Alessandro Biondi, Cristiano Giuffrida — “Branch Target Reuse: Practical Spectre-v2 Attacks in JIT Engines via Stale Branch Prediction Entries”, ACM CCS 2026, DOI 10.1145/3830454.3846672: PDF do artigo
• VUSec — Artefatos de pesquisa e código de prova de conceito: github.com/vusec/btr
• oss-security — Anúncio de divulgação da pesquisa na lista: seclists.org
• Red Hat — CVE-2026-64507: access.redhat.com
• Red Hat — CVE-2026-64508: access.redhat.com
• Plugged Ninja — “Novo ataque Spectre v2 impacta sistemas Linux em CPUs Intel” (abril de 2024): plugged.ninja