Un gruppo di ricercatori delle università di Leuven, Lubecca e Birmingham ha sviluppato un metodo di attacco BadRAM (CVE-2024-21944) che consente di bypassare il meccanismo di autenticazione e compromettere ambienti protetti attraverso l'estensione SEV-SNP nei processori AMD. Per eseguire l'attacco, a meno di rare eccezioni, l'aggressore deve avere accesso fisico ai moduli di memoria e la possibilità di eseguire codice a livello di ring zero (ring0) su un server che esegue ambienti guest protetti.
Le estensioni AMD SEV (Secure Encrypted Virtualization) mirano a garantire l'integrità della memoria delle macchine virtuali e a proteggerle da intrusioni e analisi da parte dell'amministratore del sistema host, che può eseguire codice a livello di hypervisor. Inizialmente, la protezione AMD SEV si limitava alla crittografia del contenuto della memoria del sistema guest e all'isolamento dei registri, ma successivamente nei processori AMD EPYC è stata realizzata un'estensione SEV-SNP (Secure Nested Paging) per il funzionamento sicuro con le tabelle di paging nidificate della memoria, garantendo l'integrità della memoria e prevenendo modifiche alla memoria del sistema guest da parte dell'hypervisor.
Il meccanismo AMD SEV-SNP è stato creato affinché i servizi di intelligence o il personale dei data center e dei fornitori di cloud, dove vengono eseguiti sistemi guest protetti, non possano interferire con il funzionamento del sistema guest. Il metodo di attacco BadRAM proposto consente di bypassare le garanzie fornite attraverso la modifica dei metadati SPD (Serial Presence Detect) nei moduli di memoria DDR4 o DDR5. In caso di attacco riuscito, l'aggressore può sovrascrivere i dati crittografati nella memoria del sistema guest (a livello di testo cifrato, senza possibilità di decrittografia) e bypassare il meccanismo di attestazione, ad esempio per nascondere l'inserimento di un backdoor in una macchina virtuale protetta tramite la tecnologia SEV-SNP.
L'attacco si basa sull'impostazione di parametri fittizi del modulo di memoria nello SPD, che costringono il processore a fare riferimento a indirizzi inesistenti, riflessi in aree di memoria esistenti. L'attaccante può modificare lo SPD in modo tale che il modulo di memoria restituisca al processore una dimensione superiore alle reali caratteristiche del modulo. Successivamente, l'attaccante può effettuare una mappatura di una memoria inesistente inventata su un'area reale nella DRAM, già utilizzata in forma crittografata nei sistemi guest protetti. Risultando in una situazione in cui indirizzi diversi puntano a una stessa memoria fisica (due aree riflettono una sola area nel chip DRAM), cioè l'indirizzo dell'area di memoria fittizia riflessa può accedere a quella reale già in uso, aggirando i meccanismi di protezione della memoria nella CPU.
Per eseguire l'attacco è sufficiente assemblare un semplice programmatori del costo di circa 10 dollari, costituito da un microcontrollore Raspberry Pi Pico, una connessione per i moduli DDR4/DD5 e un'alimentazione. Le utilità utilizzate per compiere l'attacco, il modulo del kernel e i prototipi degli exploit sono disponibili su GitHub.
Per i chip di alcuni produttori, in cui non è stata attivata la protezione contro la riscrittura dello SPD, l'attacco è possibile in modo software senza accesso fisico al server. Ad esempio, è possibile modificare programmaticamente i parametri dei moduli di memoria della Corsair con retroilluminazione RGB. In caso di attacco completamente software, il sistema può essere compromesso, ad esempio attraverso l'uso di un aggiornamento del BIOS dannoso o tramite una diversione da parte degli amministratori. server nei servizi cloud.
A conferma dell'efficacia del metodo sono state dimostrate due attacchi. Nel primo attacco è stata mostrata la possibilità di riprodurre il testo cifrato—utilizzando AMD SEV, i dati in memoria sono memorizzati in forma crittografata e l'attaccante non può determinare il contenuto, ma ha la possibilità di leggere i dati crittografati e quindi sostituirli con un altro contenuto crittografato.
Nella seconda attacco è stata dimostrata la possibilità di bypassare il meccanismo di attestazione SEV-SNP, che fornisce una conferma crittografica dell'integrità della macchina virtuale eseguita in un ambiente protetto. L'attaccante può intercettare il rapporto di attestazione di una macchina virtuale corretta e poi applicarlo a una macchina virtuale compromessa, ad esempio nascondendo le tracce di un'iniezione backdoor.
Il problema riguarda i processori AMD delle serie EPYC di terza e quarta generazione, forniti con i nomi in codice Milan, Milan-X, Genoa, Bergamo, Genoa-X e Siena. Per bloccare la vulnerabilità, AMD ha già rilasciato un aggiornamento del firmware SEV, nel quale è stata implementata la verifica ALIAS_CHECK, che impedisce manipolazioni della memoria proprie dell'attacco considerato.
Le tecnologie proposte da Intel, Scalable SGX e TDX, non sono soggette all'attacco, poiché le verifiche necessarie sono presenti fin dall'inizio. La tecnologia classica Intel SGX, che nel 2021 è stata dichiarata obsoleta da Intel, è parzialmente vulnerabile (analogamente all'attacco MemBuster precedentemente noto, l'attaccante può analizzare gli accessi alla memoria crittografata, cioè è possibile solo la lettura del testo cifrato, ma non la sua riscrittura). I test delle estensioni CCA (Confidential Compute Architecture) nei processori ARM non sono stati effettuati.
In aggiunta, viene segnalata un'altra vulnerabilità legata a AMD SEV-SNP. La vulnerabilità è stata identificata in un fork di QEMU in fase di sviluppo da AMD, destinato all'esecuzione macchine virtuali con SEV-SNP. Il problema consente all'amministratore dell'ambiente host di ottenere accesso root ai sistemi guest tramite manipolazioni delle tabelle ACPI. La vulnerabilità è causata dal fatto che durante il caricamento del sistema guest viene eseguita una verifica dell'integrità del kernel Linux, dell'immagine RAM iniziale e dei parametri del kernel, ma non si tengono in considerazione le tabelle ACPI, attraverso le quali il hypervisor può iniettare codice AML (ACPI Machine Language) appositamente formattato, destinato all'esecuzione nell'ambiente guest. Si sostiene che il problema non sia specifico di QEMU e si manifesti in qualsiasi hypervisor ed emulatore, poiché il kernel Linux si fida di qualsiasi dato ACPI ricevuto dall'hypervisor.
Fonte: opennet.ru
