È possibile che una macchina virtuale come VirtualBox abbia la vulnerabilità di sicurezza "spettro"? Penso che la VM possa eseguire un'esecuzione fuori servizio, ma secondo me non è possibile dare un'occhiata alla cache per leggere il risultato.

C'è qualche spiegazione su come è possibile leggere la cache di una CPU virtuale?

Sì Lo spettro può attraversare i confini host / guest, guest / host e guest / guest perché si tratta di un difetto a livello di CPU che significa che le informazioni potenzialmente sensibili possono essere trapelate su tutto ciò che viene eseguito su un core della CPU.

La maggior parte delle notizie su Internet parlano dei peggiori fornitori di servizi cloud in quanto hanno enormi gruppi di sistemi che sono virtualizzati e potrebbero essere potenzialmente abusati di fughe di informazioni sensibili.

La maggior parte dei grandi fornitori avrebbe dovuto essere riparata contro i difetti ormai, come meglio possono essere, ma questo sarà un problema che vive con noi da qualche tempo.

Security.SE ha una domanda e risposta canonica in merito e menziona le macchine virtuali:

Sto eseguendo una macchina virtuale / container, in che misura sono vulnerabile?

Secondo la risposta di Steffen Ullrich

• Gli attacchi di fusione non attraversano le macchine virtuali, perdono solo la memoria del kernel nei processi locali.
• Lo spettro può funzionare su macchine virtuali.

Inoltre, da Steffen di nuovo , Meltdown e Spectre funzionano con i contenitori, poiché i contenitori si basano sul kernel host.

Le macchine virtuali utilizzano la CPU effettiva nel sistema con alcune istruzioni privilegiate intrappolate e in grado di essere reindirizzate. Utilizza le stesse cache e le stesse istruzioni dell'host. È essenzialmente solo un altro livello all'interno della CPU fisica del tuo sistema.

La virtualizzazione è veloce solo perché utilizza la CPU fisica con la minore astrazione possibile e si basa sull'hardware della CPU per fornire isolamento. Cose come qemu possono eseguire emulazioni che sarebbero più sicure in quanto non è una CPU hardware, ma è molto più lenta ed è diversa dalla virtualizzazione.

Dal post canonico Security.se :

Lo spettro funziona a un livello diverso e non consente l'accesso ai dati dello spazio kernel dallo spazio utente. In questo attacco, l'attaccante inganna l'esecuzione speculativa per eseguire in modo predittivo istruzioni errate. In poche parole, il predittore è costretto a prevedere un risultato di ramo specifico (se -> vero), che si traduce nella richiesta di un accesso alla memoria fuori limite che il processo della vittima normalmente non avrebbe richiesto, con conseguente esecuzione speculativa errata. Quindi dal canale laterale, recupera il valore di questa memoria. In questo modo, la memoria appartenente al processo della vittima viene trasferita al processo dannoso.

Pertanto, poiché la VM viene eseguita nell'hardware effettivo della CPU e tutto ciò che deve fare è eseguire un ciclo particolare per "addestrare" il motore di esecuzione speculativo. Quindi può utilizzare un tempismo preciso per controllare le cache per particolari schemi di accesso indicativi del processo host o guest (o altra macchina virtuale) che sta cercando di sfruttare.

In questo modo significa che una macchina è sfruttabile in ogni direzione. Dall'host alla VM, dalla VM all'host e dalla VM alla VM.

Sì, non è affatto facile ed è una cosa difficile da realizzare poiché il core della CPU della VM potrebbe cambiare per capriccio dell'host e l'host potrebbe pianificare felicemente attività anche su core diversi, ma per un lungo periodo di tempo sufficienti informazioni potrebbe essere trapelato per rinunciare a una chiave segreta per alcuni sistemi o account importanti. Dato abbastanza tempo e alcuni software opportunamente invisibili, tutto è potenzialmente aperto.

Se volevi una VM "sicura", devi garantire che i suoi core siano isolati. L'unico vero modo per bloccare questo attacco sarebbe quello di "forzare" l'host e le macchine virtuali a utilizzare solo determinati core in modo che non siano mai in esecuzione sullo stesso hardware ma ciò comporterebbe un effettivo aumento dei costi in quanto non si sarebbe in grado di avere quante più macchine virtuali su un determinato host. Non saresti mai in grado di cavartela con un numero di VM superiore a quello dei core disponibili, cosa che mi aspetterei di essere eseguita su server "a basso carico" poiché molti sistemi rimangono inattivi per il 90% della loro vita.

gem5

Se sei interessato a studiare / riprodurre le vulnerabilità esclusivamente con l'emulazione, senza utilizzare la CPU host, non penso che QEMU sia abbastanza dettagliato da osservarle in quanto non simula la pipeline della CPU.

gem5, tuttavia, viene utilizzato per stimare le prestazioni del sistema in ricerca e sviluppo e simula abbastanza interni della CPU da poter osservare Spectre in un ambiente completamente pulito e controllato.

Una bella demo x86_64 con visualizzazione è stata pubblicata su: http://www.lowepower.com/jason/visualizing-spectre-with-gem5.html

Il rovescio della medaglia di gem5 è che è molto più lento di QEMU, la simulazione è più dettagliata.