
Reprodução do ataque microarquitetural Retbleed (CVE-2022-29900/29901) no gem5. Underflow do RSB, vazamento por canal lateral Flush+Reload e uma mitigação lfence verificada.
Uma reprodução prática do Retbleed (CVE-2022-29900 / CVE-2022-29901) — o ataque microarquitetural de 2022 que quebrou a defesa "Retpoline" ao provar que instruções ret, há muito consideradas seguras, podem ser sequestradas quando o Return Stack Buffer (RSB) da CPU sofre underflow.
Este projeto simula o ciclo de vida completo do ataque em um modelo de CPU Out-of-Order x86 no gem5: disparando um RSB underflow, vazando dados secretos byte a byte através de um canal lateral de cache Flush+Reload, e então verificando uma mitigação de software (lfence) que fecha o vazamento.
Projeto de curso — Arquitetura Avançada de Computadores, Outono de 2025, CUNY City College Autores: Abdul Kalam Mansoor & Rebiha Selmani
Ataques no estilo Spectre mostraram que a execução especulativa deixa efeitos colaterais em nível de cache mesmo quando a CPU "desfaz" uma previsão errada. A correção da indústria — Retpoline — substituiu saltos indiretos perigosos por instruções ret, partindo do pressuposto de que retornos são previstos com segurança a partir de uma pequena pilha de hardware (o RSB). O Retbleed mostrou que esse pressuposto é falso: esgote o RSB com recursão profunda, e a CPU silenciosamente recorre ao mesmo preditor inseguro que o Retpoline foi projetado para evitar.
| Estágio | O que acontece |
|---|---|
| 1. Gatilho | rsb_deep_call() recursa 32 níveis de profundidade, transbordando o RSB de 16 entradas. Quando a recursão se desenrola, o RSB está vazio. |
| 2. Fallback | Com o RSB vazio, a CPU recorre ao Branch Target Buffer (BTB) para prever o alvo do ret — que um atacante pode envenenar. |
| 3. Gadget | O caminho especulativo sequestrado executa gadget(), que lê um byte da senha secreta e o usa para indexar em probe_array, trazendo uma página desse array para o cache. |
| 4. Espião Flush+Reload | Antes do ataque, cada página de probe_array é removida do cache (_mm_clflush). Após a janela especulativa fechar, o programa cronometra o acesso a cada valor de byte possível (__rdtscp) — aquele que retorna rápido (cache hit) revela o byte secreto. |
Repetir isso para cada byte de ROOT_PASSWORD reconstrói todo o segredo sem nunca chamar arquiteturalmente gadget().
| Modo | Latência de acesso | Resultado |
|---|---|---|
Vulnerável (SECURE_MODE indefinido) | ~49 ciclos (cache hit) | Segredo vazado byte a byte, confirmado por indicadores vermelhos HIT! |
Corrigido (SECURE_MODE definido, _mm_lfence() injetado) | >150 ciclos (cache miss / ruído) | Ataque falha — a saída mostra SAFE / Found: ??? |
O lfence força a CPU a resolver o endereço de retorno antes que qualquer instrução subsequente possa executar, colapsando a janela especulativa antes que o gadget sequer toque em memória dependente de segredo.
src/
retbleed.c # Full PoC: trigger, gadget, Flush+Reload spy, and lfence mitigation (toggle via SECURE_MODE)
docs/
Retbleed_Report.pdf # Full written report: methodology, related work, gem5 setup, results
Retbleed_Attack_Demonstration.pptx # Slide deck used to present the project
O PoC foi compilado e medido sob o gem5 (DerivO3CPU, um modelo out-of-order — necessário porque modelos in-order não implementam execução especulativa):
gcc -O0 -static -o retbleed src/retbleed.c
./build/X86/gem5.opt configs/deprecated/example/se.py \
--cpu-type=DerivO3CPU --caches --l2cache \
--l1d_size=64kB --l1i_size=64kB --cmd=retbleed
Para alternar entre o comportamento vulnerável e o corrigido, comente/descomente esta linha no topo de retbleed.c:
#define SECURE_MODE
O código usa intrinsics reais de x86 (
_mm_clflush,__rdtscp,_mm_lfence) e também pode ser compilado e executado nativamente em hardware x86 (gcc -O0 -o retbleed src/retbleed.c) para uma demonstração mais rápida — os resultados variarão conforme as próprias mitigações da CPU hospedeira (eIBRS, patches de microcódigo, etc.), o que por si só é uma ilustração útil de quão completamente essa classe de bug foi corrigida desde 2022.
lfences extras) mediram 14–39% de sobrecarga de desempenho em hardware afetado.