Um grupo de pesquisadores das universidades de Leuven, Lübeck e Birmingham desenvolveu um método de ataque BadRAM (CVE-2024-21944) que permite contornar o mecanismo de autenticação e comprometer ambientes protegidos com o uso da extensão SEV-SNP nos processadores AMD. Para executar o ataque, o invasor, com raras exceções, deve ter acesso físico aos módulos de memória e ser capaz de executar código no nível zero (ring0) em um servidor que roda ambientes virtuais protegidos.
As extensões AMD SEV (Secure Encrypted Virtualization) visam fornecer garantias de integridade da memória das máquinas virtuais, bem como protegê-las contra interferências e análises por parte do administrador do sistema host, que consegue executar código no nível do hipervisor. Inicialmente, a proteção AMD SEV se limitava à criptografia do conteúdo da memória do sistema convidado e à isolação dos registradores, mas posteriormente foram implementadas nos processadores AMD EPYC a extensão SEV-SNP (Secure Nested Paging) para o funcionamento seguro com tabelas de página aninhadas, garantindo a integridade da memória e impedindo modificações na memória do sistema convidado por parte do hipervisor.
O mecanismo AMD SEV-SNP foi criado para que agências de segurança ou o pessoal de data centers e provedores de nuvem, onde sistemas convidados protegidos estão em operação, não possam interferir no funcionamento do sistema convidado. O método de ataque BadRAM proposto permite contornar as garantias fornecidas ao alterar os metadados SPD (Serial Presence Detect) nos módulos de memória DDR4 ou DDR5. Em um ataque bem-sucedido, o invasor pode reescrever os dados criptografados na memória do sistema convidado (no nível do texto cifrado, sem possibilidade de descriptografia) e contornar o mecanismo de verificação, por exemplo, para ocultar a inserção de um backdoor em uma máquina virtual protegida pela tecnologia SEV-SNP.
O ataque baseia-se na apresentação de parâmetros fictícios do módulo de memória no SPD, fazendo com que o processador acesse endereços inexistentes refletidos nas áreas de memória existentes. O atacante pode ajustar o SPD de tal forma que o módulo de memória retorne ao processador um tamanho que excede as características reais do módulo. Depois disso, o atacante pode mapear a memória fictícia inexistente em uma área real na DRAM, que já está sendo usada em forma criptografada em sistemas convidados protegidos. O resultado é uma situação em que diferentes endereços apontam para uma mesma memória física (duas áreas refletidas em uma área no chip DRAM), ou seja, ao endereço da área de memória refletida fictícia pode-se acessar já uma memória real em uso, contornando os mecanismos de proteção de memória no CPU.
Para realizar o ataque, basta montar um programador simples que custa cerca de 10 dólares, composto por um microcontrolador Raspberry Pi Pico, um conector para módulos DDR4/DD5 e uma fonte de alimentação. As ferramentas utilizadas para realizar o ataque, o módulo do kernel e protótipos de exploits estão disponíveis no GitHub.
Para chips de alguns fabricantes, onde a gravação do SPD não está bloqueada, a realização do ataque é possível via software, sem acesso físico ao servidor. Por exemplo, é possível alterar programaticamente os parâmetros de módulos de memória da Corsair com retroiluminação RGB. No caso de um ataque totalmente programático, o sistema pode ser comprometido, por exemplo, através da aplicação de uma atualização de BIOS maliciosa ou por intermédio de uma ação de sabotagem por parte de administradores. servidores em serviços de nuvem.
Como confirmação do funcionamento do método, duas ataques foram demonstrados. No primeiro ataque, foi mostrada a possibilidade de reproduzir novamente o texto criptografado — ao usar AMD SEV, os dados na memória são armazenados em forma criptografada e o atacante não consegue determinar o conteúdo, mas tem a capacidade de ler os dados criptografados e, em seguida, substituí-los por outro conteúdo criptografado.
No segundo ataque, foi demonstrada a possibilidade de contornar o mecanismo de atestação SEV-SNP, que fornece confirmação criptográfica da integridade da máquina virtual operando em um ambiente protegido. O atacante pode interceptar o relatório de atestação de uma máquina virtual correta e então substituí-lo por um de uma máquina virtual comprometida, como ocultar vestígios de uma backdoor.
O problema afeta as gerações 3 e 4 dos processadores AMD da série EPYC, conhecidos pelos codinomes Milan, Milan-X, Genoa, Bergamo, Genoa-X e Siena. Para bloquear a vulnerabilidade, a AMD já lançou uma atualização de firmware SEV, na qual foi implementada a verificação ALIAS_CHECK, que impede a manipulação de memória própria do ataque em questão.
As tecnologias Scalable SGX e TDX propostas pela Intel não são suscetíveis ao ataque, pois as verificações necessárias estão presentes desde o início. A tecnologia clássica Intel SGX, que em 2021 foi descontinuada pela Intel, é parcialmente suscetível ao ataque (similar ao ataque MemBuster anteriormente conhecido, um invasor pode analisar acessos à memória criptografada, ou seja, é possível apenas a leitura do texto cifrado, mas não sua reescrita). Testes das extensões CCA (Confidential Compute Architecture) em processadores ARM não foram realizados.
Adicionalmente, há relatos de mais uma vulnerabilidade relacionada ao AMD SEV-SNP. A vulnerabilidade foi identificada em um fork em desenvolvimento da AMD do emulador QEMU, destinado a operar máquinas virtuais com SEV-SNP. O problema permite que o administrador do ambiente host obtenha acesso root às máquinas hóspedes através de manipulações com as tabelas ACPI. A vulnerabilidade é causada pelo fato de que, durante a inicialização do sistema hóspede, uma verificação de integridade do núcleo Linux, do disco RAM inicial e dos parâmetros do núcleo é realizada, mas as tabelas ACPI não são consideradas, através das quais o hypervisor pode apresentar um código AML (ACPI Machine Language) especialmente formatado, destinado à execução no ambiente hóspede. Afirma-se que o problema não é específico do QEMU e se manifesta em qualquer hypervisor e emulador, uma vez que o núcleo Linux confia em qualquer dado ACPI que venha do hypervisor.
Fonte: opennet.ru
