Una vulnerabilità in KVM consente l'esecuzione di codice al di fuori del sistema guest sui processori AMD

I ricercatori del team di Google Project Zero hanno svelato alcuni giorni fa in un post sul blog che hanno identificato una vulnerabilità (CVE-2021-29657) nell'hypervisor KVM (un hypervisor open source basato su Linux che supporta la virtualizzazione con accelerazione hardware su x86, ARM, PowerPC e S/390) che consente di evitare l'isolamento del sistema ospite ed esegui il tuo codice sul lato dell'ambiente host.

Il post menziona che il problema manifesti dal kernel Linux 5.10-rc1 a v5.12-rc6, esso decir, copre solo i kernel 5.10 e 5.11 (La maggior parte dei rami stabili delle distribuzioni non sono stati interessati dal problema.) Il problema è presente nel meccanismo nested_svm_vmrun, implementato utilizzando l'estensione AMD SVM (Secure Virtual Machine) e che consente l'avvio annidato dei sistemi guest.

In questo post del blog, descrivo una vulnerabilità nel codice KVM specifico di AMD e discuto come questo bug può trasformarsi in una fuga completa della macchina virtuale. Per quanto ne so, questo è il primo resoconto pubblico di un breakout KVM guest-to-host che non si basa su bug nei componenti dello spazio utente come QEMU.

Il bug discusso è stato assegnato a CVE-2021-29657, interessa le versioni del kernel da v5.10-rc1 a v5.12-rc6 ed è stato corretto alla fine di marzo 2021. Poiché il bug è diventato sfruttabile solo nella v5.10 ed è stato scoperto circa 5 mesi dopo, la maggior parte delle implementazioni KVM del mondo reale non dovrebbe essere interessata. Penso ancora che il problema sia un caso di studio interessante nel lavoro necessario per costruire una fuga stabile da ospite a host contro KVM e spero che questo articolo possa dimostrare che i compromessi dell'hypervisor non sono solo problemi teorici.

I ricercatori affermano che per la corretta implementazione di questa funzionalità, l'hypervisor deve intercettare tutte le istruzioni SVM eseguito su sistemi guest, emulare il suo comportamento e sincronizzare lo stato con l'hardware, che è un compito piuttosto difficile.

Dopo aver analizzato l'implementazione KVM proposta, i ricercatoris ha riscontrato un errore logico che consente il contenuto del MSR (Registrazione specifica per modello) dell'host essere influenzato dal sistema ospite, che può essere utilizzato per eseguire codice a livello di host.

In particolare, l'esecuzione di un'operazione VMRUN da un guest di secondo livello annidato (L2 lanciato da un altro guest) porta a una seconda chiamata a nested_svm_vmrun e danneggia la struttura svm-> nested.hsave, che è sovrapposta ai dati di vmcb dal sistema guest L2 .

Di conseguenza, si verifica una situazione in cui a livello del guest L2 è possibile liberare memoria nella struttura svm-> nested.msrpm, che memorizza il bit MSR, anche se continua ad essere utilizzato, e accedere all'MSR dell'host ambiente. .

Ciò significa, ad esempio, che la memoria di un ospite può essere ispezionata scaricando la memoria allocata del suo processo di spazio utente o che i limiti di risorse per il tempo della CPU e la memoria possono essere facilmente applicati. 

Inoltre, KVM può scaricare la maggior parte del lavoro relativo all'emulazione del dispositivo sul componente dello spazio utente.

Il problema è presente nel codice utilizzato sui sistemi con processori AMD (modulo kvm-amd.ko) e non compare sui processori Intel.

 Al di fuori di un paio di dispositivi sensibili alle prestazioni che si occupano della gestione degli interrupt, tutto il codice complesso di basso livello per fornire l'accesso al disco virtuale, alla rete o alla GPU può essere distribuito nello spazio utente.  

I ricercatori oltre a descrivere il problema hanno anche preparato un prototipo funzionante di un exploit che consente di eseguire una shell di root da un ambiente guest in un ambiente host su un sistema con un processore AMD Epyc 7351P e un kernel Linux 5.10.

Si osserva che questo è il primo ospite a ospitare la vulnerabilità nell'hypervisor KVM stesso, non correlato a bug nei componenti dello spazio utente come QEMU. La correzione è stata accettata nel kernel alla fine di marzo.

Infine se sei interessato a saperne di più sulla nota, puoi controllare i dettagli nel seguente link


Lascia un tuo commento

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati con *

*

*

  1. Responsabile dei dati: Miguel Ángel Gatón
  2. Scopo dei dati: controllo SPAM, gestione commenti.
  3. Legittimazione: il tuo consenso
  4. Comunicazione dei dati: I dati non saranno oggetto di comunicazione a terzi se non per obbligo di legge.
  5. Archiviazione dati: database ospitato da Occentus Networks (UE)
  6. Diritti: in qualsiasi momento puoi limitare, recuperare ed eliminare le tue informazioni.