Pesquisadores do MIT reabriram um dos capítulos mais desconfortáveis da segurança de sistemas modernos. Batizada de TONTOU — acrônimo de Time-of-Neutralization to Time-of-Use —, a técnica explora uma janela mínima para reenvenenar o preditor de desvios da CPU depois que a mitigação do Spectre v2 neutraliza a ameaça, mas antes de o kernel usar o desvio. O resultado é alarmante: em um host AMD Zen 2 com Linux e as proteções mais recentes, os pesquisadores leram memória do kernel a cerca de 5,47 bytes por segundo, com 91,97% de precisão, e localizaram o /etc/shadow, que guarda hashes de senha, em cinco de dez tentativas.
Para entender o impacto, é preciso lembrar o que é o Spectre v2, também chamado de Branch Target Injection (BTI). Processadores modernos executam instruções especulativamente, adivinhando o destino de desvios indiretos por meio de um buffer de predição de desvios (BTB). Quando a previsão falha, o estado arquitetural é descartado, mas os efeitos colaterais no cache permanecem. Essas pegadas temporais permitem reconstruir dados secretos que nunca deveriam ser lidos.
As defesas conhecidas, como o eIBRS da Intel e o Safe RET da AMD, existem para neutralizar o BTB: limpam ou restringem os alvos especulativos na transição entre o espaço do usuário e o kernel. É aí que entra a TONTOU. A defesa neutraliza o preditor em um instante, mas o kernel só consome o desvio ciclos depois. Nesse intervalo — no Zen 2, apenas duas instruções, seis bytes — o atacante injeta uma interrupção de temporizador e reenvenena o BTB antes do uso.
O ataque se desenrola em etapas: neutralização, redirecionamento, envenenamento e uso. A vítima é induzida a redirecionar o fluxo especulativo para um gadget que vaza dados por um canal lateral. Como mostram os autores no paper da USENIX Security 2026, a técnica contorna as premissas de projeto tanto do Safe RET quanto do eIBRS, não apenas uma delas.
A TONTOU não é isolada; é mais um elo de uma longa cadeia. Desde Spectre e Meltdown, em 2018, a indústria lidou com Retbleed, Inception e variantes do mesmo princípio: a especulação é eficiente demais para ser abandonada, mas cada mitigação de software cria janelas que ataques exploram. que as mitigações seguem sendo contornadas? Porque o problema é estrutural. Corrigir de verdade o microprocessador exigiria redesenhar a predição de desvios, custo que os fabricantes relutam em pagar. A solução recai em barreiras de software, patches que cobrem os fluxos conhecidos, mas não todos os fluxos possíveis entre neutralização e uso.
Para sistemas Linux e ambientes de nuvem, a severidade é alta. O exploit exige acesso local sem privilégios, mas em infraestrutura compartilhada — contêineres, VMs, servidores multiusuário — é exatamente o cenário de risco. Vazar hashes de senha e chaves de criptografia da memória do kernel compromete o modelo de isolamento. O CVE-2026-68480 já recebeu correções nos kernels 6.18.43, 6.6.149 e 6.1.181, e a AMD confirmou impacto nas microarquiteturas Zen 1 a 4.
A mitigação prática é a receita de sempre: manter o kernel atualizado, minimizar a exposição local e, onde o risco for alto, isolar workloads. A baixa taxa de exfiltração ainda limita ataques em tempo real, mas a precisão e a localização de arquivos específicos tornam a ameaça real.
A pergunta que fica é provocadora: se cada defesa de Spectre v2 criou uma nova janela, estamos condenados a um jogo de gato e rato, ou o desempenho um dia cederá e a indústria finalmente redesenhará a predição de desvios na arquitetura?
Fontes: BleepingComputer, The Hacker News, USENIX Security 2026 (MIT, Privacy Guides, LinuxCompatible
✓ Fontes independentes cruzadas e verificadas antes da publicação
