Mior viola AMD SEV-SNP: le VM cifrate si possono leggere e l’attestazione può essere falsificata

Executive Summary

• Mior compromette il modello di sicurezza AMD SEV-SNP. L’attacco CVE-2026-0462 manipola l’instradamento della memoria durante l’inizializzazione e permette a un hypervisor malevolo di aggirare le protezioni delle macchine virtuali riservate.
• Gli esperimenti dimostrano lettura e modifica della memoria e falsificazione delle attestazioni. I ricercatori di ETH Zurich riferiscono il successo in tutti i 1.000 tentativi delle prove di accesso alla memoria, anche con ciphertext hiding attivato.
• AMD ha pubblicato firmware SEV correttivi e prepara aggiornamenti delle piattaforme. La vulnerabilità interessa diverse famiglie EPYC, ma l’attacco è stato dimostrato direttamente su un processore EPYC 9135 Zen 5.

Il cloud può continuare a dichiarare sicura una macchina virtuale anche quando un operatore malevolo ne ha compromesso la memoria e falsificato l’attestazione crittografica. È il risultato della ricerca Mior: Breaking AMD SEV-SNP with Device-as-Memory, sviluppata da Christoph Wech, Philipp Giersfeld, Benedict Schlüter e Shweta Shinde dell’ETH Zurich e destinata alla conferenza ACM CCS 2026. La vulnerabilità, identificata come CVE-2026-0462, colpisce il sistema AMD Secure Encrypted Virtualization-Secure Nested Paging, utilizzato per proteggere i dati elaborati dalle macchine virtuali anche dal gestore dell’infrastruttura. AMD ha riconosciuto il problema il 10 novembre 2026, annunciando aggiornamenti firmware. Gli esperimenti mostrano una compromissione delle garanzie di riservatezza e integrità, ma non documentano attacchi criminali già avvenuti.

Mior aggira AMD SEV-SNP sfruttando l’instradamento della memoria

La tecnologia AMD SEV-SNP nasce per risolvere un problema fondamentale del cloud: consentire a un’organizzazione di utilizzare server appartenenti a un fornitore esterno senza concedere automaticamente a quest’ultimo la possibilità di leggere o modificare i dati durante l’elaborazione. La protezione utilizza la cifratura della memoria, controlli hardware sulle pagine assegnate alle macchine virtuali e un sistema di attestazione attraverso il quale il cliente può verificare la configurazione dell’ambiente di esecuzione. Al centro dell’architettura si trova il Platform Security Processor (PSP), coprocessore che inizializza e gestisce componenti fondamentali della sicurezza. Uno di questi è la Reverse Map Table (RMP), struttura che registra l’appartenenza delle pagine di memoria e impedisce all’hypervisor di modificarne arbitrariamente le associazioni.

Mior interviene proprio durante questa inizializzazione, sfruttando le configurazioni di instradamento delle transazioni di memoria attraverso AMD Infinity Fabric. L’hypervisor malevolo altera il percorso utilizzato dal PSP affinché alcune operazioni destinate alla memoria di sistema vengano indirizzate verso un dispositivo PCIe controllato dall’attaccante. Nei test è stata utilizzata una scheda grafica. Il risultato è che il processore di sicurezza può completare la procedura considerando correttamente inizializzata una struttura che, nella memoria reale, conserva porzioni non inizializzate. La protezione viene compromessa prima ancora che la macchina virtuale inizi a lavorare, senza dover necessariamente decifrare il contenuto della memoria.

La Reverse Map Table perde il controllo e l’hypervisor ottiene accesso ai dati

Il punto decisivo dell’attacco consiste nella possibilità di interferire con le operazioni del PSP senza provocare il fallimento dell’avvio della piattaforma. Il coprocessore dovrebbe verificare che le proprie scritture raggiungano le aree di memoria previste, ma la manipolazione del percorso consente al dispositivo controllato dall’aggressore di partecipare alla procedura. Parte della RMP rimane quindi priva delle protezioni necessarie, compresa la voce incaricata di difendere la stessa struttura di controllo. Da quella posizione l’hypervisor può modificare i metadati che normalmente gli impediscono di accedere alle pagine riservate alle macchine virtuali.

Il risultato permette di abilitare la modalità debug su una Confidential Virtual Machine che l’aveva disabilitata, utilizzando successivamente i comandi del PSP per leggere e modificare la memoria del sistema ospite. Secondo la ricostruzione degli esperimenti, questa procedura è riuscita in 1.000 tentativi su 1.000, sia con la funzionalità opzionale ciphertext hiding disabilitata sia con la protezione attivata. Il precedente più vicino è RMPocalypse, l’attacco presentato ad ACM CCS 2025 contro l’inizializzazione della Reverse Map Table. Le due ricerche condividono il bersaglio architetturale, ma Mior sfrutta una diversa debolezza nella gestione dell’instradamento della memoria e non costituisce semplicemente una ripetizione della vecchia vulnerabilità.

Leggi anche: DDRop rompe Intel TDX e AMD SEV-SNP: la memoria cifrata non sa se i dati sono vecchi

Mior falsifica anche l’attestazione crittografica delle macchine virtuali

La conseguenza più delicata non riguarda soltanto la possibilità di leggere o modificare la memoria. Mior permette anche di falsificare il processo di attestazione, una delle garanzie fondamentali offerte dal confidential computing. Normalmente una macchina virtuale protetta produce una misurazione crittografica del software utilizzato durante l’avvio. Il PSP contribuisce a generare un rapporto firmato che può essere controllato da un soggetto esterno prima di affidare dati riservati al sistema. L’obiettivo è impedire che il gestore del server sostituisca silenziosamente il software autorizzato con una versione modificata. Nei test di Mior, invece, i ricercatori sono riusciti a trasferire la misurazione di una macchina virtuale legittima a un ambiente malevolo, ottenendo un’attestazione che descriveva il software innocuo anziché quello effettivamente in esecuzione.

Questo risultato mette in discussione il rapporto tra fiducia crittografica e fiducia nell’hardware che produce la prova. Una firma può essere formalmente valida, ma non garantire più la corrispondenza tra configurazione dichiarata e sistema realmente avviato quando la struttura sottostante è stata compromessa. Il problema assume particolare rilevanza per gli ambienti cloud che elaborano informazioni finanziarie, sanitarie e industriali, ma anche per i servizi AI progettati per proteggere i dati attraverso enclave hardware. Il ruolo dell’attestazione era già emerso nell’architettura di Brave Leo basata su confidential computing e verifica crittografica dell’ambiente di esecuzione. Mior non dimostra che quel servizio sia vulnerabile: evidenzia invece perché l’affidabilità della prova dipenda dal processore, dal firmware e dall’intera catena di fiducia.

CVE-2026-0462 interessa AMD EPYC ma richiede un host già controllato

La vulnerabilità è stata riprodotta direttamente su un AMD EPYC 9135 basato su architettura Zen 5. I ricercatori considerano potenzialmente interessate anche generazioni precedenti, mentre il bollettino AMD elenca fra i prodotti coinvolti le serie EPYC 7003, 8004, 8005, 9004 e 9005. Questa distinzione è fondamentale: l’elenco dei processori per i quali AMD prevede mitigazioni non equivale a una dimostrazione sperimentale dell’attacco su ciascun modello. Il produttore classifica CVE-2026-0462 con punteggio CVSS 4.0 pari a 5,9, identificando il problema come un’insufficiente granularità dei controlli di accesso nel firmware SEV, capace di consentire a un hypervisor malevolo di alterare il percorso verso la memoria mappata dei dispositivi.

Mior non è una vulnerabilità utilizzabile automaticamente da un aggressore remoto che raggiunge un server attraverso Internet. La dimostrazione richiede controllo dell’hypervisor, possibilità di modificare la configurazione UEFI e disponibilità di un dispositivo PCIe utilizzabile nella manipolazione della memoria. Nei test, il BIOS è stato modificato per lasciare accessibili alcune configurazioni necessarie all’attacco. Questi requisiti limitano lo scenario operativo, ma non lo collocano fuori dal modello di sicurezza di SEV-SNP: la tecnologia nasce proprio per difendere le macchine virtuali anche da un gestore dell’host non affidabile. Una normale VM, che già considera attendibile il proprio hypervisor, non acquisisce con Mior una nuova garanzia da perdere. Il problema riguarda specificamente gli ambienti che promettono isolamento hardware dal provider.

AMD pubblica i firmware correttivi e prepara gli aggiornamenti BIOS

AMD ha pubblicato il bollettino ufficiale AMD-SB-3059 il 10 novembre 2026, confermando la vulnerabilità e indicando le mitigazioni previste. Il produttore riporta firmware SEV correttivi datati 12 agosto 2026, mentre gli aggiornamenti Platform Initialization destinati ai costruttori dei server sono programmati per dicembre 2026. Per la famiglia EPYC 7003 viene indicato il firmware SEV 1.3A.03, associato al valore TCB[SNP] 0x1F; per EPYC 8004 e 9004 compare 1.3A.4, con TCB[SNP] 0x1E; per EPYC 8005 e 9005 viene indicato 1.3A.0A, con TCB[SNP] 0x8. Questi valori sono rilevanti per verificare la versione della componente di sicurezza riportata nei meccanismi di attestazione, ma la presenza di un numero atteso non deve essere interpretata senza considerare l’intera configurazione del sistema.

Le aziende che utilizzano server fisici devono verificare con il produttore della piattaforma la disponibilità del BIOS appropriato, mentre chi utilizza Confidential VM presso un cloud provider dipende dall’aggiornamento dell’infrastruttura effettuato dal fornitore. Diventa quindi importante ottenere informazioni sulla generazione dei processori, sul firmware installato e sulle regole utilizzate per accettare le attestazioni. Il precedente degli attacchi WireTap e Battering RAM contro Intel SGX e AMD SEV aveva già evidenziato i rischi derivanti da componenti hardware normalmente esclusi dalle verifiche applicative. Mior trasferisce l’attenzione all’interno del processore e del suo sistema di interconnessione.

Continua con: Intel SGX esce dai futuri Xeon e lascia spazio a TDX e NEAR AI violata tramite SGLang: i limiti del confidential computing.

Il cloud confidenziale deve dimostrare di proteggere anche dal proprio gestore

Mior conferma un problema strutturale già emerso nelle ricerche contro le Trusted Execution Environments: cifrare la memoria non basta quando il componente incaricato di applicare la protezione può essere ingannato durante la propria inizializzazione. Le soluzioni di confidential computing dipendono da una catena che comprende microarchitettura, interconnessioni, firmware, processore di sicurezza e procedure di attestazione. Se uno di questi livelli consente al gestore non affidabile di modificare ciò che il sistema considera vero, le garanzie superiori possono perdere efficacia anche senza violare gli algoritmi crittografici.

La ricerca di ETH Zurich, descritta nel paper Mior presentato per ACM CCS 2026, rappresenta una dimostrazione sperimentale e non una prova di compromissioni già avvenute nei servizi cloud commerciali. Tuttavia, la combinazione di lettura della memoria, modifica dei contenuti e falsificazione dell’attestazione rende la vulnerabilità particolarmente significativa per organizzazioni che affidano dati sensibili a infrastrutture esterne. Il valore del confidential computing rimane concreto, ma richiede verifiche sulle componenti che sostengono la fiducia, non soltanto sulla presenza di un’etichetta commerciale o di una funzione attivata. Mior dimostra che la sovranità dei dati nel cloud dipende anche dal controllo tecnico delle condizioni in cui l’hardware produce e certifica le proprie garanzie.