Branch Target Reuse: Spectre v2 vaza hash root no Linux

Uma nova técnica chamada Branch Target Reuse (BTR) mostra que previsões antigas mantidas pelo processador podem continuar válidas mesmo depois que uma região de código foi liberada e reutilizada. Em testes contra o Linux, pesquisadores conseguiram recuperar da memória o hash da senha do usuário root em poucos minutos.

O trabalho, apresentado por pesquisadores do VUSec, da Vrije Universiteit Amsterdam, e da Scuola Superiore Sant’Anna, amplia novamente a superfície de ataques da família Spectre v2. A descoberta não depende de uma falha convencional em um aplicativo: ela explora a diferença entre o estado real do código na memória e informações ainda preservadas pelo mecanismo de previsão de desvios da CPU.

Os pesquisadores chamaram essa condição de Branch Target Reuse. O ponto técnico é especialmente relevante para ambientes com compilação just-in-time (JIT), nos quais regiões de memória são frequentemente usadas, liberadas e reaproveitadas para armazenar novo código. Esse comportamento aparece em navegadores, runtimes de linguagens e também em componentes do próprio sistema operacional.

Como o Branch Target Reuse funciona

Processadores modernos tentam antecipar qual será o próximo caminho de execução para reduzir latência. Em ataques Spectre v2, o adversário busca influenciar essa previsão para fazer a CPU executar especulativamente instruções que não deveriam ser alcançadas naquele contexto. Mesmo quando a execução incorreta é descartada, efeitos deixados no cache podem revelar informações protegidas.

No BTR, o atacante treina um desvio indireto para apontar para uma região específica de código. Depois, o código original é removido e a mesma área de memória recebe um novo bloco. O processador restaura a coerência arquitetural do código, mas a entrada antiga do preditor de desvios pode continuar existindo. Quando o desvio é acionado novamente, a CPU pode especular usando o alvo antigo e entrar no novo código por um ponto inesperado.

Segundo o VUSec, esse mecanismo cria uma espécie de execute-after-free especulativo. O fluxo normal continua protegido pelas verificações arquiteturais, mas a execução transitória pode alcançar instruções desalinhadas ou sequências que expõem dados por canais laterais de cache.

Hash da senha root recuperado em 3 a 5 minutos

O experimento mais completo foi construído contra o cBPF do Linux. Os pesquisadores usaram programas BPF clássicos não privilegiados como filtros seccomp para treinar o preditor, liberar a região de código e instalar um novo programa na mesma área de memória. A partir de uma entrada obsoleta do Branch Target Buffer (BTB), foi possível forçar a execução especulativa de instruções controladas pelo atacante.

O exploit demonstrado vazou dados a aproximadamente oito bytes por segundo. A taxa é baixa quando comparada a uma leitura convencional de memória, mas suficiente para percorrer estruturas do kernel até localizar o processo su e chegar ao espaço de memória que continha o hash da senha root. Nos testes citados pelos pesquisadores, o segredo foi recuperado em média em cerca de três minutos em Raptor Cove e cinco minutos em Lion Cove.

O resultado não significa que a senha em texto claro tenha sido obtida diretamente. O material recuperado é um hash, que ainda precisa ser quebrado por força bruta, dicionários ou outras técnicas. A resistência dessa etapa depende do algoritmo de hashing, de sua configuração e da qualidade da senha. Ainda assim, a pesquisa demonstra que uma barreira fundamental de isolamento entre código não privilegiado e dados sensíveis pode ser ultrapassada.

O alcance vai além de um único processador

A exploração completa contra o Linux foi demonstrada em CPUs Intel modernas, mas o comportamento que torna o BTR possível foi observado pelos pesquisadores em processadores Intel, AMD e Arm. Isso não significa que o mesmo exploit funcione de forma idêntica em todas as plataformas: cada arquitetura, JIT e mecanismo de mitigação altera as condições necessárias para transformar o comportamento microarquitetural em vazamento útil.

O estudo também analisou o SpiderMonkey, motor JavaScript e WebAssembly do Firefox, e o GraalVM, da Oracle. No Firefox, os pesquisadores confirmaram que entradas antigas do preditor sobrevivem ao ciclo de liberação e reutilização do código e construíram uma prova de conceito, mas não um exploit completo de navegador. No GraalVM, conseguiram ultrapassar especulativamente uma verificação de sandbox, embora a atividade interna de compilação e garbage collection tenha eliminado as previsões antes que o ataque pudesse ser concluído.

Notícias Relacionadas

Risco para empresas e ambientes compartilhados

O cenário mais sensível envolve sistemas que executam código de diferentes níveis de confiança no mesmo hardware. Servidores multiusuário, plataformas que usam filtros BPF, runtimes JIT, sandboxes, navegadores e infraestruturas virtualizadas precisam considerar ataques de execução transitória dentro do modelo de ameaça, principalmente quando um processo não confiável consegue compartilhar recursos físicos com processos que manipulam credenciais ou outros segredos.

Para o negócio, o impacto potencial não se limita à obtenção de uma senha. Um canal capaz de extrair memória privilegiada pode atingir chaves criptográficas, tokens, credenciais de serviço e outros dados mantidos temporariamente em RAM. O risco cresce em ambientes nos quais uma única máquina concentra múltiplos workloads ou tenants, porque a eficiência operacional aumenta também a importância do isolamento fornecido pelo hardware e pelo sistema operacional.

A descoberta reforça uma dificuldade recorrente das vulnerabilidades microarquiteturais: scanners tradicionais podem indicar que o sistema operacional está atualizado e ainda assim o nível efetivo de proteção depender da combinação entre CPU, microcódigo, kernel, parâmetros de boot, compilador e política de execução de código não confiável.

Correções já chegaram ao Linux

Os pesquisadores comunicaram os fornecedores afetados antes da divulgação. Para o Linux, foram atribuídos os identificadores CVE-2026-64507 e CVE-2026-64508. O kernel passou a emitir uma barreira IBPB (Indirect Branch Prediction Barrier) nos núcleos quando uma região de JIT BPF previamente executada é reutilizada, além de reduzir a reutilização dessas áreas como otimização.

A Oracle adotou uma abordagem diferente no GraalVM, dificultando a reutilização previsível de regiões do cache de código JIT por meio de randomização. No caso do Firefox, a discussão inclui mecanismos baseados em IBPB e a evolução do isolamento entre sites, que reduz a possibilidade de conteúdo de origens diferentes compartilhar o mesmo espaço de endereçamento.

Medidas de proteção

A prioridade é atualizar o kernel, o sistema operacional e o firmware disponibilizado pelo fabricante. Em Linux, administradores também podem verificar o estado das mitigações Spectre v2 em /sys/devices/system/cpu/vulnerabilities/spectre_v2. O próprio kernel documenta mecanismos como retpolines, Enhanced IBRS, IBPB e STIBP, escolhidos conforme a CPU e o modelo de uso.

Ambientes com maior criticidade devem revisar se parâmetros de boot ou ajustes de desempenho desabilitaram proteções contra Spectre. Opções como nospectre_v2 ou spectre_v2=off removem mitigadores e podem reabrir caminhos de vazamento. A documentação do kernel também prevê controles por processo para restringir especulação indireta em aplicações que manipulam segredos ou executam conteúdo não confiável.

Outra medida é reduzir a execução desnecessária de código não confiável no mesmo host de processos sensíveis. Quando houver workloads de diferentes níveis de confiança, isolamento por host, afinidade de CPU, políticas de virtualização e revisão do uso de SMT podem fazer parte de uma estratégia de defesa em profundidade, especialmente enquanto as correções dependem de software.

A gestão de patches precisa incluir microcódigo e firmware, não apenas pacotes do sistema operacional. Ataques Spectre v2 exploram componentes que atravessam as fronteiras tradicionais entre software e hardware; manter apenas o kernel atualizado pode não ser suficiente quando a mitigação recomendada pelo fornecedor exige também uma atualização de BIOS ou microcódigo.

Conclusão

O Branch Target Reuse é relevante porque rompe uma suposição confortável: substituir o código em uma região de memória não garante que o histórico usado pelo processador para prever o fluxo de execução tenha sido descartado no mesmo momento. Em ambientes JIT, essa diferença cria uma nova oportunidade para reaproveitar previsões antigas e alcançar dados que deveriam permanecer isolados.

O ataque divulgado ainda pertence ao campo de pesquisa e demonstração técnica, mas os patches incorporados ao Linux mostram que o problema foi tratado como risco concreto pelos mantenedores. Para equipes de infraestrutura e segurança, a resposta deve combinar atualização, validação das mitigações realmente ativas e revisão de ambientes que executam código não confiável sobre o mesmo hardware que processa segredos.

Veja também

Referências

Branch Target Reuse: Spectre-v2 Attacks in JIT Engines

New Spectre v2 attack variant leaks Linux root password hash in minutes

Spectre Side Channels — The Linux Kernel documentation

Branch History Injection and Intra-mode Branch Target Injection

Branch Target Reuse: nova variante do Spectre v2 vaza hash da senha root em minutos

Como o Branch Target Reuse funciona

Hash da senha root recuperado em 3 a 5 minutos