Exploit em registradores do controlador de DRAM quebra isolamento de memória em CPUs AMD
O pesquisador Christopher Domas mostrou como manipular o mapeamento físico para DRAM abaixo das barreiras de segurança, acessando enclaves como SMM RAM e firmware do PSP em processadores AMD antigos.

O pesquisador de segurança Christopher Domas apresentou o skitter-creek-bath-salts, um projeto open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → de segurança de hardware que ataca a camada mais baixa da hierarquia física de memória para contornar as fronteiras de privilégio da CPU. Segundo a InfoQ, a técnica manipula registradores de tradução do controlador de memória para alterar dinamicamente, no nível da lógica de hardware, o mapeamento de endereços físicos para posições reais na DRAM. O resultado é que software sem privilégio consegue acessar regiões de memória isoladas da plataforma sem disparar as verificações arquiteturais nem gerar exceções de falha.
O pressuposto que a arquitetura moderna assume
Processadores modernos partem de uma premissa: endereços físicos mapeiam de forma determinística para posições específicas de silício. As barreiras de segurança padrão, incluindo as Extended Page Tables (EPT) do hypervisor, os limites de faixa TSEG do System Management Mode e os carveouts privados do Platform Security Processor (PSP), operam na camada do núcleo e do fabric de interconexão do sistema, ou seja, antes de o tráfego de memória chegar ao controlador.
A descoberta de Domas é que os registradores de tradução do controlador de memória ficam abaixo dessas barreiras de controle de acesso. Ao alterar bits de configuração, como o BankSwizzleMode, muda-se de forma fundamental como o controlador calcula as coordenadas de banco, linha e coluna da DRAM. Como os filtros de segurança a montante só validam o endereço físico não traduzido, esses bit-flips fazem com que acessos comuns de memória caiam silenciosamente dentro de enclaves de hardware protegidos.
Como o exploit extrai os dados
Para ler memória embaralhada sem derrubar o sistema operacional hospedeiro, o exploit usa um pipeline de software em vários estágios. Um módulo de kernel Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps → customizado desliga os núcleos de CPU não usados no boot, faz flush das caches do sistema, pré-aquece os TLBs (translation lookaside buffers) e desabilita interrupções para garantir estabilidade da memória durante o "religamento" dos mapeamentos.
Em seguida, scripts de sondagem automatizados usam uma heurística de coupon-collector combinada com leituras direcionadas em userspace para catalogar colisões de bits de endereço. A toolchain modela a permutação de endereços físicos com aritmética de Galois Field e emprega um SMT solver para derivar o mapeamento exato bit a bit. Resolvido o mapa, o exploit executa rajadas de leitura e escrita contra enclaves antes intocáveis, entre eles:
- SMM RAM (System Management Mode)
- Tabelas de firmware do PSP
- Áreas de save do estado de sleep CC6 do processador
- Buffers de patch de microcódigo
O ponto cego arquitetural
O achado expõe uma distinção central entre privilégio de CPU e privilégio de plataforma. As verificações de segurança a montante não conseguem garantir integridade se a lógica do controlador de memória, a jusante, permitir swizzling dinâmico de endereços. Nas famílias AMD 14h, 15h e 16h, software em Ring 0 pode manipular essas configurações, e esse nível de acesso é, segundo a análise, insuficiente por natureza: ele trata o kernel como inerentemente confiável.
A recomendação técnica que emerge do trabalho é direta: os registradores de tradução do controlador de memória precisam ser travados de forma estrita durante o boot. A realidade de kernels adversários exige que configurações críticas de plataforma sejam gerenciadas por fronteiras acima do privilégio da CPU, e não dentro dele.
Limitações práticas
Comunidades de segurança de hardware e engenharia reversa no Reddit (como r/asm e r/blueteamsec) e podcasts como o SANS ISC Stormcast reagiram com interesse. As discussões destacaram tanto a implicação arquitetural (as barreiras de plataforma vivem acima do controlador de memória e, por isso, ignoram o embaralhamento das coordenadas físicas brutas) quanto os limites do ataque na prática.
Dois pontos contêm o risco imediato: o exploit exige privilégio Ring 0, ou seja, o atacante já precisa ter comprometido o kernel; e ele mira registradores acessíveis principalmente em processadores AMD mais antigos das famílias 15h e 16h. Não se trata de um ataque remoto ou executável por código sem privilégio a partir do zero.
O que muda para quem opera infraestrutura no Brasil
O cenário de risco concreto é o de computação confiável e cloud bare-metal. Provedores que oferecem servidores dedicados ou instâncias bare-metal com hardware AMD dessas gerações, e ambientes que dependem de confidential computing para isolar cargas sensíveis, são exatamente os casos em que a fronteira entre "tenant" e "plataforma" é o que sustenta a garantia de segurança.
Para times brasileiros que rodam infraestrutura própria ou contratam bare-metal, o recado prático é de inventário: identificar quais máquinas usam CPUs AMD das famílias 14h, 15h e 16h e avaliar se elas estão em contextos onde um kernel comprometido é parte realista do modelo de ameaça. Em ambientes multi-tenant sobre bare-metal antigo, a garantia de que SMM RAM, firmware do PSP e buffers de microcódigo estão de fato isolados deixa de ser automática.
Ficam em aberto os pontos de mitigação de longo prazo: se e como a AMD tratará o travamento desses registradores em firmware para o hardware já em campo, e em que medida gerações mais novas de processadores já fecham essa janela. O projeto skitter-creek-bath-salts é open source, o que significa que a técnica está disponível para estudo, e também para reprodução, por qualquer time de segurança.
Fonte: InfoQ
Este artigo foi escrito por Redação iMasters, um agente de inteligência artificial com revisão editorial humana. Publicado sob revisão editorial de Rafael Chinaglia - iMasters. Saiba como produzimos no expediente.









Comentários
Ninguém comentou ainda. Começa a conversa?