Una macchina virtuale (VM) può "hackerare" un'altra VM in esecuzione sulla stessa macchina fisica?

Domande:

• se una VM è danneggiata (compromessa), cosa rischio sulle altre VM in esecuzione sulla stessa macchina fisica?
• Che tipo di problemi di sicurezza esistono tra le macchine virtuali in esecuzione sullo stesso host fisico?
• Esiste (puoi fare) un elenco di quelle (potenziali) debolezze e / o problemi?

Avvertimento:

So che esistono molti tipi / soluzioni di virtualizzazione e possono avere diversi punti deboli. Tuttavia, cerco principalmente problemi di sicurezza generali relativi alle tecniche di virtualizzazione, piuttosto che un bug specifico del fornitore.

Fornisci dati concreti, studi (gravi), problemi con esperienza o spiegazioni tecniche. Sii specifico. Non (solo) dare la tua opinione.

• Esempi:

Due anni fa, ho sentito che potrebbero esserci problemi di sicurezza legati alla MMU (accesso alla memoria principale di altre macchine, penso), ma non so se questa sia una minaccia pratica a oggi, o solo una ricerca teorica soggetto.

EDIT: Ho anche trovato questo attacco "Flush + Reload" in grado di recuperare chiavi segrete GnuPG sulla stessa macchina fisica, sfruttando la cache della CPU L3, anche se GnuPG viene eseguito su un'altra macchina virtuale. GnuPG è stato corretto da allora.

Ovviamente è possibile sfruttare un'altra VM in esecuzione sullo stesso hardware, dato un exploit funzionante. Inoltre, uno può esistere. La tua domanda cita alcuni lavori recenti che ne mostrano uno. Non condividerò nessun exploit o PoC specifico qui, ma dirò volentieri come possono essere fatti.

Gli exploit utilizzati in questo contesto sono naturalmente diversi da quelli che funzionano quando si esegue sulla stessa macchina su cui si sta tentando di sfruttare un servizio e tendono ad essere un po 'più difficili a causa del maggiore isolamento. Tuttavia, alcuni approcci generali che possono essere utilizzati per realizzare tale exploit includono:

• Attacca l'hypervisor . Se è possibile ottenere una shell sufficientemente privilegiata sull'hypervisor con una macchina virtuale, è possibile ottenere il controllo su qualsiasi macchina virtuale nel sistema. Il modo per affrontarlo è cercare flussi di dati esistenti dalla VM all'hypervisor e che dipendono fortemente dall'hypervisor; cose come driver paravirtualizzati, condivisione di appunti, output di visualizzazione e traffico di rete tendono a creare questo tipo di canale. Ad esempio, una chiamata dannosa a un dispositivo di rete paravirtualizzato può portare a un'esecuzione arbitraria di codice nel contesto dell'hypervisor responsabile del passaggio di tale traffico al driver NIC fisico.
• Attacca l'hardware sull'host . Molti dispositivi consentono aggiornamenti del firmware e, se è possibile accedere al meccanismo per questo da una macchina virtuale, è possibile caricare un nuovo firmware che favorisce le tue intenzioni. Ad esempio, se si è autorizzati ad aggiornare il firmware sulla scheda NIC, è possibile che venga duplicato il traffico associato a un indirizzo MAC (quello della vittima), ma con un altro indirizzo MAC di destinazione (il proprio). Per questo motivo molti hypervisor filtrano tali comandi ove possibile; ESXi filtra gli aggiornamenti del microcodice CPU quando hanno origine da una macchina virtuale.
• Attacca l'architettura dell'host. L'attacco che hai citato, essenzialmente un altro attacco di divulgazione delle chiavi basato sul timing, fa questo: sfrutta l'impatto del meccanismo di memorizzazione nella cache sui tempi delle operazioni per discernere i dati utilizzati dalla VM vittima nelle sue operazioni. Al centro della virtualizzazione c'è la condivisione dei componenti; dove un componente è condiviso, esiste la possibilità di un canale laterale. Nella misura in cui un'altra VM sullo stesso host è in grado di influenzare il comportamento dell'hardware durante l'esecuzione nel contesto della VM vittima, la VM vittima è controllata dall'aggressore. L'attacco referenziato sfrutta la capacità della VM di controllare il comportamento della cache della CPU (essenzialmente stato universale condiviso) in modo che i tempi di accesso alla memoria della vittima rivelino più accuratamente i dati a cui sta accedendo; ovunque esista uno stato globale condiviso, esiste anche la possibilità di una divulgazione. Per entrare nell'ipotetico fornire esempi, immagina un attacco che massaggia il VMFS di ESXi e fa in modo che parti dei volumi virtuali facciano riferimento agli stessi indirizzi del disco fisico, o un attacco che faccia credere a un sistema di ballooning della memoria che una parte della memoria possa essere condivisa quando in realtà dovrebbe essere privato (è molto simile a come funzionano gli exploit use-after-free o double-allocation). Si consideri un ipotetico MSR della CPU (registro specifico del modello) che l'hypervisor ignora ma consente l'accesso; questo potrebbe essere usato per trasferire dati tra VM, interrompendo l'isolamento che l'hypervisor dovrebbe fornire. Considera anche la possibilità che la compressione venga utilizzata in modo tale che i componenti duplicati dei dischi virtuali vengano archiviati una sola volta: in alcune configurazioni potrebbe esistere un canale laterale (molto difficile) in cui un utente malintenzionato può discernere il contenuto di altri dischi virtuali scrivendo e osservando cosa fa l'hypervisor. Ovviamente si suppone che un hypervisor si protegga da questo e gli esempi ipotetici sarebbero bug critici per la sicurezza, ma a volte queste cose scivolano via.
• Attacca direttamente l'altra VM . Se si dispone di un host prossimale per la macchina virtuale vittima, è possibile trarre vantaggio dal controllo dell'accesso rilassato o dalla comunicazione inter-VM intenzionale a seconda della configurazione dell'host e delle ipotesi che vengono fatte durante la distribuzione del controllo di accesso. Questo è solo leggermente rilevante, ma menziona.

Sorgono attacchi specifici che verranno corretti col passare del tempo, quindi non è mai valido classificare alcuni meccanismi particolari come sfruttabili, sfruttabili solo in condizioni di laboratorio o inesplicabili. Come puoi vedere, gli attacchi tendono a essere coinvolti e difficili, ma quali sono fattibili in un determinato momento è qualcosa che cambia rapidamente e devi essere preparato.

Detto questo, i vettori che ho menzionato sopra (con la possibile eccezione dell'ultimo in alcuni casi) semplicemente non esistono in ambienti bare metal. Quindi sì, dato che la sicurezza riguarda la protezione contro gli exploit di cui non si è a conoscenza e che non sono in circolazione così come quelli che sono stati resi pubblici, è possibile ottenere un po 'di sicurezza correndo in metallo nudo o in almeno in un ambiente in cui l'hypervisor non ospita VM per tutti.

In generale, una strategia efficace per la programmazione sicura delle applicazioni sarebbe quella di supporre che un computer abbia altri processi in esecuzione su di esso che potrebbero essere controllati da malintenzionati o malintenzionati e utilizzare tecniche di programmazione consapevoli degli exploit, anche se si ritiene che non si assicurerebbe altrimenti tale processo esiste nella tua VM. Tuttavia, in particolare con le prime due categorie, ricorda che vince chi tocca prima l'hardware.

In teoria, no. Il punto centrale dell'hypervisor è isolare le macchine virtuali l'una dall'altra.

In pratica, ci sono stati (e potrebbero esserci in futuro) bug di sicurezza in vari hypervisor che potrebbero consentire a una macchina virtuale di influenzare l'hypervisor o altre macchine virtuali sullo stesso host. Misure di sicurezza come sVirt (per KVM / QEMU) hanno lo scopo di risolvere questo problema.

Modifica: ho pensato che questo argomento fosse stato affrontato mesi fa, ma è stato appena ripreso e ora OP sta chiedendo ulteriori "fatti reali, studi citati", ecc., Quindi ho capito cosa diamine.

Gli exploit di questa natura sono:

1. Raro
2. Di natura sensibile e quindi non condiviso apertamente, e quando lo sono, gli exploit sarebbero riparati dal venditore prima che chiunque su questo sito ne venisse a conoscenza
3. Complicato e varierà a seconda del venditore

Non possiamo dire che sia impossibile hackerare un hypervisor e ottenere l'accesso ad altre VM. Né possiamo quantificare il rischio che esiste, tranne che per quell'esperienza ci mostra che è piuttosto basso, considerando che non troverete molte storie di attacchi che hanno utilizzato exploit hypervisor.

Ecco una sorta di articolo interessante al contrario che suggerisce che sono stati effettuati più di alcuni attacchi basati su hypervisor.

Tuttavia, con la tecnologia che dipende dagli hypervisor ora più che mai, tali exploit sarebbero riparati e protetti con più urgenza di quasi ogni altro tipo di exploit.

Ecco un estratto dal rapporto sulle tendenze e sui rischi di metà anno di IBM X-Force 2010:

(Apri questa immagine in una nuova scheda per visualizzarla a schermo intero.)

Nota la percentuale misurata di vulnerabilità "Escape to hypervisor", che mi sembra abbastanza spaventosa. Ovviamente vorresti leggere il resto del rapporto in quanto contiene molti più dati per il backup dei reclami.

Ecco una storia su un possibile exploit realizzato sull'hypervisor di Playstation 3, che è divertente. Forse non è così efficace per la tua attività, a meno che la tua attività non sia Sony, nel qual caso è estremamente efficace.

Ecco un meraviglioso articolo di Eric Horschman di VMware, in cui mi viene in mente che suona come un adolescente pieno di anti-Micro $ oft, ma è comunque un buon articolo. In questo articolo, troverai bocconcini come questo:

I residenti della casa di vetro di Microsoft avevano altre pietre da lanciare. Microsoft ha indicato CVE-2009-1244 come un esempio di vulnerabilità di tipo breakout guest in ESX ed ESXi. Un exploit per gli ospiti è una faccenda seria, ma, ancora una volta, Microsoft sta travisando i fatti. VMware ha risposto rapidamente alla correzione di tale vulnerabilità nei nostri prodotti e ESX è stata molto meno colpita di quanto Microsoft ti avrebbe fatto credere:

Quibbling tra concorrenti. Ma probabilmente la cosa più lucida che dice in tutto l'articolo è questa:

La verità è che le vulnerabilità e gli exploit non scompariranno mai completamente per nessun software aziendale.

Il sempre citabile Theo de Raddt del progetto OpenBSD:

Sei assolutamente illuso, se non stupido, se pensi che una raccolta mondiale di ingegneri del software che non sono in grado di scrivere sistemi operativi o applicazioni senza falle di sicurezza, possa quindi voltarsi e scrivere improvvisamente livelli di virtualizzazione senza falle di sicurezza.

Un po 'infiammatorio ma il suo punto è ben preso. In teoria la virtualizzazione dovrebbe fornire un completo isolamento tra le macchine virtuali e il loro host. In pratica ci sono occasionali vulnerabilità della sicurezza che consentono agli aggressori avanzati di circumnavigare queste protezioni e ottenere l'accesso ad altre macchine virtuali o, peggio ancora, il loro host (vedere Uno studio empirico sull'esposizione alla sicurezza degli host di ambienti virtualizzati ostili ). Come afferma Ryan Ries, questo tipo di vulnerabilità è piuttosto raro (il che non significa che non ci siano) e spesso non viene divulgato dai fornitori, ma esiste.

Se sei preoccupato per il potenziale di questo tipo di attacchi (e penso che dovresti esserlo), ti consiglio di non mescolare le zone di sicurezza su un singolo host virtuale o cluster di host virtuale. Ad esempio, avresti un cluster host virtuale dedicato a due host per macchine virtuali DMZ, un cluster dedicato per middleware e un cluster dedicato per risorse protette. In questo modo nel caso in cui una vulnerabilità venga sfruttata in modo tale da consentire a un utente malintenzionato di sovvertire altre macchine virtuali o, peggio ancora, l'hypervisor stesso, il modello di sicurezza è ancora intatto.