Cibersegurança

A manipulação dos registos do controlador de DRAM compromete o isolamento da memória da CPU

A manipulação dos registos do controlador de DRAM compromete o isolamento da memória da CPU

O investigador de segurança Christopher Domas revelou o «skitter-creek-bath-salts», um projeto de segurança de hardware de código aberto que contorna os limites tradicionais de privilégios da CPU, atuando na camada mais baixa da hierarquia da memória física. Ao manipular os registos de tradução do controlador de memória, a ferramenta altera dinamicamente os mapeamentos de endereços da memória física para a DRAM ao nível da lógica do hardware. Isto permite que software sem privilégios aceda a regiões isoladas da memória da plataforma sem ativar barreiras de memória arquitetónicas a montante nem exceções de falha.

As arquiteturas de segurança dos processadores modernos partem do princípio de que os endereços físicos se mapeiam de forma determinística para locais específicos de armazenamento no silício. As barreiras de segurança padrão — incluindo as Tabelas de Páginas Estendidas do hipervisor, os limites de intervalo TSEG do Modo de Gestão do Sistema e as áreas privadas do Processador de Segurança da Plataforma (PSP) — operam na camada do núcleo e de interligação da malha do sistema, antes de o tráfego de memória chegar ao controlador. Domas descobriu que os registos de tradução do controlador de memória se situam abaixo destas barreiras de controlo de acesso. A manipulação de bits de configuração, como o «BankSwizzleMode», altera fundamentalmente a forma como o controlador calcula as coordenadas do banco, da linha e da coluna da DRAM. Como os filtros de segurança a montante validam apenas o endereço físico não traduzido, estas inversões de bits permitem que os acessos de memória padrão cheguem silenciosamente ao interior de enclaves de hardware protegidos.

Para extrair dados da memória codificada sem desestabilizar o SO anfitrião, a exploração utiliza um pipeline de software em várias etapas. Um módulo personalizado do kernel Linux desativa os núcleos da CPU que não estão a iniciar o sistema, esvazia as caches do sistema, pré-aquece os buffers de tradução (TLB) e desativa as interrupções para garantir a estabilidade da memória durante a reestruturação. Scripts de sondagem automatizados utilizam então uma heurística de «recolha de cupões», combinada com leituras direcionadas no espaço do utilizador, para catalogar colisões de bits de endereço. A cadeia de ferramentas associada modela a permutação do endereço físico utilizando aritmética de campo de Galois e recorre a um solucionador SMT para derivar o mapeamento exato, bit a bit. Assim que o mapeamento é resolvido, a exploração executa rajadas direcionadas de leitura/gravação contra enclaves anteriormente impenetráveis, incluindo a RAM do Modo de Gestão do Sistema (SMM), tabelas de firmware do PSP, áreas de poupança de energia do processador CC6 e buffers de correções de microcódigo.

Estas descobertas expõem um ponto cego arquitetónico crítico: as verificações de segurança a montante não podem garantir a integridade se a lógica do controlador de memória a jusante permitir a troca dinâmica de endereços, o que representa riscos para a nuvem «bare-metal» e a computação confidencial. Esta vulnerabilidade destaca a distinção vital entre privilégios da CPU e da plataforma. Embora os processadores AMD das famílias 14h, 15h e 16h permitam que software de Anel 0 manipule estas configurações, este nível de acesso é fundamentalmente insuficiente, uma vez que trata o kernel como inerentemente fiável. Para proteger os sistemas futuros, as equipas de hardware devem garantir que os registos de tradução do controlador de memória fiquem estritamente bloqueados durante o arranque, uma vez que a realidade dos kernels maliciosos exige que a configuração da plataforma crítica para a segurança seja gerida por limites elevados acima dos privilégios ao nível da CPU.

As comunidades de segurança de hardware e de engenharia reversa no Reddit (por exemplo, r/asm e r/blueteamsec) e podcasts como o SANS ISC Stormcast reagiram ao projeto com grande interesse. As discussões têm-se centrado nas implicações arquitetónicas da descoberta, salientando que, uma vez que as barreiras de segurança da plataforma existem acima do controlador de memória, estas permanecem alheias à alteração das coordenadas físicas brutas. Os especialistas também enfatizam as limitações práticas da exploração, que requer privilégios de Anel 0 e tem como alvo registos acessíveis principalmente em processadores AMD mais antigos das famílias 15h e 16h.

Sobre o autor

Olimpiu Pop

Mostrar maisMostrar menos