O pesquisador de segurança Christopher Domas revelou o Repositório skitter-creek-bath-salts no GitHub (github.com), um projeto open-source de segurança de hardware que desmantela as fronteiras tradicionais de privilégio da CPU ao atingir a camada mais baixa da hierarquia de memória física. Ao manipular registradores de tradução do controlador de memória, a ferramenta altera dinamicamente os mapeamentos de endereços físicos para DRAM no nível da lógica de hardware, permitindo que software não privilegiado acesse regiões de memória isoladas da plataforma sem acionar fences de memória arquiteturais ou exceções de falha.
- Christopher Domas revelou o skitter-creek-bath-salts, um projeto open-source que quebra o isolamento de memória da CPU manipulando registradores de tradução do controlador DRAM.
- O exploit permite acessar regiões protegidas como SMM RAM, firmware do PSP, áreas de sleep CC6 e buffers de microcódigo em processadores AMD das famílias 14h, 15h e 16h.
- As cercas de segurança tradicionais (EPT, TSEG, PSP) operam acima do controlador de memória, deixando um ponto cego explorável.
- A mitigação recomendada é bloquear estritamente os registradores de tradução durante o boot, elevando a configuração de segurança acima do privilégio de CPU.
- A descoberta expõe a distinção entre privilégio de CPU e privilégio de plataforma, com riscos para nuvem bare-metal e computação confidencial.
Como a manipulação de registradores do controlador de memória quebra o isolamento
A arquitetura de segurança dos processadores modernos parte do pressuposto de que endereços físicos mapeiam deterministicamente para locais específicos de armazenamento de silício. As fronteiras de segurança padrão, como Extended Page Tables de hipervisores, limites de faixa TSEG do System Management Mode e carveouts privados do Platform Security Processor (PSP), operam na camada de núcleo e interconexão do sistema, antes que o tráfego de memória alcance o controlador.
Domas descobriu que os registradores de tradução do controlador de memória ficam abaixo dessas cercas de controle de acesso. A manipulação de bits de configuração, como o BankSwizzleMode, muda fundamentalmente a forma como o controlador calcula as coordenadas de banco, linha e coluna da DRAM. Como os filtros de segurança a montante validam apenas o endereço físico não traduzido, esses bit-flips permitem que acessos padrão à memória alcancem silenciosamente enclaves de hardware protegidas.
Para extrair dados de memória embaralhada sem desestabilizar o sistema operacional hospedeiro, o exploit utiliza um pipeline de software em múltiplas etapas. Um módulo de kernel Linux personalizado desativa núcleos de CPU não utilizados para boot, limpa caches do sistema, pré-aquece buffers de tradução e desativa interrupções para garantir estabilidade de memória durante o re-cabeamento.
Scripts de sondagem automatizados usam uma heurística de coupon-collector, combinada com leituras direcionadas no espaço do usuário, para catalogar colisões de bits de endereço. A toolchain acompanhante modela a permutação de endereços físicos usando aritmética de campo de Galois e emprega um solver SMT para derivar o mapeamento bit a bit exato.
# publicidade
Mas o que isso significa para a segurança prática de sistemas em produção? A resposta é que a confiança na integridade da memória depende de todos os níveis da hierarquia, desde o núcleo até o controlador, e qualquer brecha nessa cadeia compromete as garantias de isolamento.
Os alvos: smm RAM, firmware psp e outras enclaves protegidas
Uma vez resolvido o mapa, o exploit executa rajadas direcionadas de leitura/escrita contra enclaves anteriormente impenetráveis, incluindo RAM do System Management Mode (SMM), tabelas de firmware do PSP, áreas de save de sleep CC6 do processador e buffers de patch de microcódigo. Esses componentes são considerados parte do chamado 'trusted computing base' das plataformas modernas.
O pesquisador destaca que essa vulnerabilidade expõe um ponto cego arquitetônico crítico: verificações de segurança a montante não podem garantir integridade se a lógica do controlador de memória a jusante permitir swizzling dinâmico de endereços. Isso representa riscos especialmente para ambientes de nuvem bare-metal e computação confidencial, onde a separação física e lógica da memória é um pilar de segurança.
A descoberta também evidencia a distinção vital entre privilégio de CPU e privilégio de plataforma. Enquanto processadores AMD das famílias 14h, 15h e 16h permitem que software Ring 0 manipule essas configurações, esse nível de acesso é fundamentalmente insuficiente, pois trata o kernel como inerentemente confiável.
Qual a implicação prática disso para equipes de segurança? A resposta está na necessidade de reavaliar o modelo de confiança: o kernel, mesmo rodando em Ring 0, não deve ser capaz de alterar configurações críticas da plataforma sem que isso seja detectado ou bloqueado.
A resposta da comunidade e as recomendações para sistemas futuros
A comunidade de segurança de hardware e engenharia reversa no Reddit, em subreddits como r/asm e r/blueteamsec, e podcasts como SANS ISC Stormcast responderam ao projeto com interesse significativo. As discussões centram-se nas implicações arquitetônicas da descoberta, observando que, como as cercas de segurança de plataforma existem acima do controlador de memória, elas permanecem alheias ao embaralhamento das coordenadas físicas brutas.
Especialistas também enfatizam as limitações práticas do exploit: exige privilégios Ring 0 e tem como alvo registradores primariamente acessíveis em processadores AMD mais antigos das famílias 15h e 16h. Isso reduz o impacto em sistemas modernos, mas não elimina o risco para ambientes legados.
Para proteger sistemas futuros, as equipes de hardware devem garantir que os registradores de tradução do controlador de memória sejam estritamente bloqueados durante o boot, elevando a configuração crítico de segurança da plataforma para fronteiras acima do privilégio de nível de CPU. A realidade de kernels adversários exige essa mudança de paradigma.
Enquanto isso, pesquisadores e profissionais de segurança podem acompanhar o repositório no GitHub e as discussões técnicas nos canais da comunidade para entender melhor o alcance da técnica e desenvolver contramedidas.
| Camada de segurança | Funcionamento | Limitação | Risco explorado |
|---|---|---|---|
| Extended Page Tables (EPT) | Tradução de endereços virtuais do hipervisor | Opera acima do controlador de memória | Não detecta swizzling de coordenadas físicas |
| TSEG range limits | Limita o acesso à RAM do SMM | Valida apenas o endereço físico não traduzido | Permite acesso direto a SMM RAM via mapeamento alterado |
| PSP private carveouts | Isola firmware do Platform Security Processor | Confia na tradução determinística de endereços | Exposição de tabelas de firmware via leitura/escrita |
| Controlador de memória | Calcula coordenadas de banco, linha e coluna da DRAM | Registradores de tradução abaixo das cercas | Bit-flips em bits como BankSwizzleMode |
Arraste para o lado para ver toda a tabela.
O que falta para que essas recomendações virem prática? A adoção exigirá mudanças nos firmwares, nos hipervisores e nos designs de próxima geração de processadores, mas o primeiro passo já foi dado com a divulgação da técnica.
Leia também:
Fonte: Infoq
