Si suppone che una macchina virtuale preveda che il codice nel guest sfugga all'host. Quindi, quando una tale fuga è possibile, è dovuta a un buco di sicurezza nell'implementazione VM. Alcuni di questi buchi sono stati trovati in vari motori VM.
Vedi ad esempio Cloudburst , un exploit descritto nel 2009. In questo caso, l'emulazione video è strumentale alla fuga, perché l'obiettivo del motore di fornire emulazione video fast implica l'utilizzo di alcune condivisioni interne di risorse tra host e guest, e questo è in disaccordo con l'obiettivo di sicurezza del livello di isolamento. I computer moderni sono sistemi complessi, quindi anche la virtualizzazione completa è complessa, ed è piuttosto inevitabile che simili buchi del genere accadano.
Per essere onesti, i buchi che consentono la vera fuga dell'ospite sono piuttosto rari. Una buona manutenzione (che applica prontamente le correzioni di sicurezza dal fornitore) per un motore VM è una strategia a rischio ragionevole. Nota, tuttavia, che non si può dire lo stesso per leak di informazioni : una VM può imparare cose su ciò che accade in altre macchine virtuali, o nell'host, attraverso attacchi temporali. È stato dimostrato (in condizioni di laboratorio) per gli algoritmi di crittografia: una VM può apprendere la chiave segreta utilizzata da un'altra VM, poiché quell'altra VM utilizzava un'implementazione AES basata su tabella ed era in esecuzione sul nucleo principale della VM dell'aggressore ( quindi con una cache L1 condivisa).
La fuga dei guest può tuttavia essere facilitata dalla configurazione. Ad esempio, quando l'ospite condivide parte del suo filesystem con il guest, quindi per definizione , il guest ha accesso a parte del filesystem host. Allo stesso modo, host e guest condividono spesso una rete più o meno virtuale, quindi i fori di exploit da remoto sull'host sono nel raggio di copertura dal guest.