Un gruppo di ricercatori delle università di Lovanio, Lubecca e Birmingham ha sviluppato un metodo di attacco BadRAM (CVE-2024-21944) che consente di bypassare il meccanismo di autenticazione e compromettere gli ambienti protetti utilizzando l'estensione SEV-SNP nei processori AMD. Per eseguire l'attacco, l'attaccante, con rare eccezioni, deve ottenere accesso fisico ai moduli di memoria e avere la capacità di eseguire codice a livello di anello zero (ring0) sul server che esegue ambienti guest protetti.
Le estensioni AMD SEV (Secure Encrypted Virtualization) sono progettate per garantire l'integrità della memoria delle macchine virtuali e per proteggerle da interferenze e analisi da parte dell'amministratore del sistema host, in grado di eseguire codice a livello di hypervisor. Inizialmente, la protezione AMD SEV era limitata alla crittografia del contenuto della memoria del sistema ospite e all'isolamento dei registri, ma in seguito nei processori AMD EPYC è stata implementata l'estensione SEV-SNP (Secure Nested Paging) per consentire un'operazione sicura con le tabelle di pagina annidate, garantendo l'integrità della memoria e impedendo modifiche alla memoria del sistema ospite da parte dell'hypervisor.
Il meccanismo AMD SEV-SNP è stato progettato per impedire a servizi segreti o personale dei data center e dei fornitori di servizi cloud, dove vengono eseguiti sistemi guest protetti, di intromettersi nel funzionamento del sistema guest. Il metodo di attacco BadRAM proposto consente di eludere le garanzie fornite modificando i metadati SPD (Serial Presence Detect) nei moduli di memoria DDR4 o DDR5. In caso di attacco riuscito, un malintenzionato può riscrivere i dati crittografati nella memoria del sistema guest (a livello di testo cifrato, senza possibilità di decrittazione) e bypassare il meccanismo di attestazione, ad esempio, per nascondere l'inserimento di un backdoor in una macchina virtuale protetta mediante tecnologia SEV-SNP.
L'attacco si basa sulla manipolazione dei parametri fittizi del modulo di memoria nel SPD, costringendo la CPU ad accedere a indirizzi non esistenti mappati su aree di memoria reali. L'attaccante può modificare lo SPD in modo tale che il modulo di memoria restituisca alla CPU una dimensione superiore alle specifiche reali del modulo. Successivamente, l'attaccante può mappare memoria fittizia non esistente su un'area reale nella DRAM che è già utilizzata in forma crittografata da sistemi ospiti protetti. Ne risulta una situazione in cui indirizzi diversi puntano alla stessa memoria fisica (due aree mappate su una singola area nel chip DRAM), ovvero, accedendo all'indirizzo dell'area di memoria fittizia si può accedere alla memoria reale già in uso, eludendo i meccanismi di protezione della memoria nella CPU.
Per realizzare l'attacco è sufficiente assemblare un semplice programmator costato circa 10 dollari, composto da un microcontrollore Raspberry Pi Pico, un'interfaccia per moduli DDR4/DDR5 e un alimentatore. Gli strumenti utilizzati per l'attacco, il modulo kernel e i prototipi degli exploit sono disponibili su GitHub.
Per i chip di alcuni produttori, in cui non è stata eseguita la blocco della riscrittura SPD, è possibile effettuare l'attacco 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 un aggiornamento BIOS dannoso o un'azione ostile da parte degli amministratori. server nei servizi cloud.
Come dimostrazione della funzionalità del metodo sono state presentate due attacchi. Nel primo attacco, viene mostrata la possibilità di riprodurre nuovamente il testo cifrato: utilizzando AMD SEV, i dati in memoria vengono mantenuti in forma cifrata e l'attaccante non può determinare il contenuto, ma ha la possibilità di leggere i dati cifrati e successivamente inserirli al posto di un altro contenuto cifrato.
La seconda attack ha dimostrato la possibilità di aggirare il meccanismo di attestazione SEV-SNP, che fornisce una conferma crittografica dell'integrità della macchina virtuale eseguita in un ambiente protetto. L'attaccante può catturare il report di attestazione di una macchina virtuale corretta e poi sostituirlo con quello di una macchina virtuale compromessa, ad esempio, nascondendo le tracce di un'infezione da backdoor.
Il problema riguarda le generazioni 3 e 4 dei processori AMD della serie EPYC, 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, che implementa il controllo ALIAS_CHECK, impedendo le manipolazioni di memoria tipiche dell'attacco in questione.
Le tecnologie Scalable SGX e TDX offerte da Intel non sono vulnerabili agli attacchi, in quanto le necessarie verifiche sono integrate fin dall'inizio. La tecnologia classica Intel SGX, che nel 2021 è stata declassata da Intel, è parzialmente vulnerabile agli attacchi (analogamente al noto attacco MemBuster, un malintenzionato può analizzare gli accessi alla memoria crittografata, consentendo solo la lettura del testo cifrato, ma non la sua riscrittura). Non sono stati condotti test sugli estensioni CCA (Confidential Compute Architecture) nei processori ARM.
Si segnala inoltre un'altra vulnerabilità legata ad AMD SEV-SNP. La vulnerabilità è stata individuata in un fork di QEMU in fase di sviluppo da parte di AMD, progettato per l'esecuzione. di macchine virtuali con SEV-SNP. Il problema consente all'amministratore dell'ambiente di hosting di ottenere l'accesso root ai sistemi guest attraverso manipolazioni delle tabelle ACPI. La vulnerabilità è causata dal fatto che durante il caricamento del sistema guest viene eseguita una verifica dell'integrità del kernel di Linux, dell'immagine di avvio e delle opzioni del kernel, ma non vengono considerati i tavoli ACPI, attraverso i quali il hypervisor può esporre codice AML (ACPI Machine Language) formattato appositamente, destinato a essere eseguito nell'ambiente guest. Si afferma che il problema non sia specifico per QEMU e si manifesti in qualsiasi hypervisor ed emulatore, poiché il kernel di Linux si fida di qualsiasi dato ACPI fornito dall'hypervisor.
Fonte: opennet.ru
