Teoricamente, il sistema guest è totalmente isolato dalla VM e non può nemmeno "vedere" l'host, figuriamoci attaccarlo; quindi il guest non può uscire dalla VM. Ovviamente, in pratica, è successo occasionalmente ( link all'archivio web). Un attacco richiede lo sfruttamento di un problema di sicurezza (cioè un bug di programmazione che si rivela avere conseguenze negative) nell'implementazione della VM o, eventualmente, le funzionalità hardware su cui si basa la VM. Esistono poche vie di uscita per i dati in uscita dalla VM; Ad esempio, per l'accesso a Internet, la VM sta emulando una scheda di rete virtuale, che gestisce solo i pacchetti di livello più basso, non il TCP / IP completo, quindi la maggior parte dei problemi dello stack IP rimane confinata all'interno della VM stessa. Quindi i bug che portano al breakout dalla VM tendono a rimanere eventi rari.

Ci sono alcuni tipi di attacchi contro i quali le VM sono molto efficaci, ad es. bombe a forcella. Dal punto di vista del sistema host, la VM è un unico processo. Una fork bomb nell'ospite metterà in ginocchio lo scheduler nel sistema operativo guest , ma per l'host questo sarà totalmente innocuo. Allo stesso modo per la memoria: la VM emula una macchina fisica con una data quantità di RAM e avrà bisogno di quella quantità di RAM "reale" per eseguire il backup in modo efficiente. Indipendentemente da ciò che fa il guest, la VM non monopolizzerà mai più RAM di così. (Si desidera comunque limitare la dimensione della RAM della VM a, diciamo, al massimo la metà della dimensione della RAM fisica, perché la RAM "reale" aggiuntiva è utile per il caching del disco; e anche il sistema operativo host vorrà usarne un po '.)

Disclaimer: sto cercando di ottenere una comprensione di livello relativamente alto. Se vuoi una guida dettagliata, è fuori portata. Inoltre, ci sono altri modi (interamente in software) per implementare macchine virtuali a cui ciò non si applica. Mi sto anche concentrando sulla "rottura" solo attraverso i meccanismi di virtualizzazione, cioè non quelli che possono accadere da PC a PC su host in rete reali.

Mi piacciono i dettagli, quindi vai con alcuni. In primo luogo, codeproject ha alcuni eccellenti riferimenti all'assemblatore sulle diverse modalità di una CPU x86 (reale, protetta e lunga) e sull'uso della virtualizzazione. C'è un blog Intel VT (non sono sicuro che sia stato scritto da Intel) e infine la prima parte del Rootkit Arsenal è dedicata alla spiegazione di x86 ed è un'ottima lettura, completo di procedure dettagliate e bei diagrammi. Capire tutto richiede pazienza, quindi quello che farò qui è fornire una breve introduzione a come funziona.

Il modo in cui abbiamo funzionato quando abbiamo eseguito DOS

DOS e i primi sistemi in modalità reale a 16 bit gestiscono un modello di memoria segmentata. Non c'è controllo sulla dimensione dei segmenti e non ci sono interruttori di protezione su nessuno di questi segmenti. Il codice viene caricato in un segmento di memoria e viene eseguito; può saltare molto in altri segmenti, quindi qualsiasi codice, ovunque può alterare qualsiasi cosa, inclusa la produzione di un pezzo di codice TSR (terminare e rimanere residente) che punta semplicemente una delle voci IVT (tabella vettoriale di interruzione) a un indirizzo nel suo spazio, prima di eseguire l'originale. Fondamentalmente, non c'è protezione. Nessuna. Nada.

L'ascesa della modalità protetta a 32 bit

La modalità protetta si complica rapidamente. Ci sono tre parti: segmentazione, paging e PAE. Ciascuno richiede una tabella di dati che informi la CPU di quel segmento, pagina o che la aiuti a estendere lo spazio degli indirizzi (PAE). Questi includono i famosi ring flag (si applicano a segmenti e pagine) che implementano l'isolamento del processo. Il paging è il tuo modo per caricare i dati dalla RAM e sul disco e creare cose fantasiose come la memoria virtuale (vedi, la parola virtuale! Ci stiamo arrivando!)

Modalità lunga

La modalità lunga elimina la segmentazione e impone semplicemente le strutture PAE / Paging. Ancora una volta, per banalizzare totalmente l'implementazione di un OS, il Paging è controllato da strutture in memoria che vengono poi impostate tramite apposite istruzioni. Voilà, si può ottenere l'isolamento del processo con le giuste impostazioni. Di nuovo, sto banalizzando un po '...

Dammi la virtualizzazione!

Va ​​bene. La virtualizzazione è lo stesso concetto generale . Le macchine virtuali vengono configurate utilizzando strutture di controllo delle macchine virtuali che determinano il modo in cui la loro memoria viene mappata alla memoria fisica, un po 'come il paging . Fondamentalmente, in determinate condizioni la macchina virtuale dovrà chiedere qualcosa al sistema operativo host, un po 'come l'isolamento del processo, un po' come un interrupt software . Questi sono riferiti alle uscite VM e forniscono informazioni all'host come lo stato dei registri all'uscita. Un po 'come una chiamata di sistema .

Può un pezzo di malware uscire da una macchina virtuale?

Quindi, come per quanto riguarda la VM, il sistema operativo host ha tutto il proprio spazio di memoria e può essere infettato / danneggiato / distrutto a piacimento.

In termini di influenza diretta della memoria host, la macchina virtuale non può, perché non può vederla. L'host deve mappare la memoria richiesta nello spazio della macchina virtuale. Deve anche, in quello spazio di memoria, implementare tutto dal BIOS in su. Per comunicare con determinati dispositivi host per determinate attività, la macchina host deve configurare tali condizioni di uscita dalla VM e la VM di destinazione deve attivarle. Quando ciò accade, il controllo viene trasferito all'host.

Vi sono, quindi, due possibili aree a rischio:

1. Le azioni che l'host intraprende in risposta a una VM Uscita. Se ci sono bug in questa gestione, potrebbe essere possibile persuadere l'host a eseguire qualcosa che non dovrebbe.
2. Qualsiasi accesso host allo spazio di memoria della macchina ospite. Ricorda che il codice della macchina host in esecuzione nell'anello 0 può entrare e mandare in crash la festa dove preferisce. Accade così che tu possa impostare la memoria del guest dal guest (sorprendentemente).

Questo ti porta al tuo meccanismo di exploit. Hai bisogno di un bug di gestione nella routine di uscita della VM, quindi devi essere in grado di persuadere quel codice ad eseguire un po 'di memoria, idealmente codice che hai appena inserito in una pagina dalla VM guest. Una volta fatto, saluta il Kansas.

Come dice Tom Leek, le VM sono incredibilmente efficaci nel difendersi dalle fork bomb. In modo simile al modo in cui il sistema operativo può limitare la quantità di memoria che un processo può allocare, quindi può limitare la quantità di memoria mappata sulla VM. Se si esaurisce, il sistema operativo guest ritiene di aver esaurito la memoria fisica; l'host non lo allocherà più a meno che non implementi un'uscita dalla VM per farlo, il che sarebbe un po 'pericoloso e non credo che ciò avvenga.

Come probabilmente è questo?

Non molto. Dipende interamente dalle implementazioni di uscita della VM o dalla lettura della memoria dal guest sull'host con un bel bug nel codice di lettura. Richiede anche che detto bug ti permetta di controllare il crash in modo tale da poter forzare l'esecuzione all'indirizzo di memoria del tuo host. L'uscita della VM deve essere in grado di accedere a quella memoria.

Cosa non ho coperto?

1. Attacchi a stack di software esistenti come TCPIP. Le vulnerabilità qui sono le stesse di se avessi comunque due PC fisici reali.
2. Virtualizzazione implementata interamente dal software.
3. Virtualizzazione su qualsiasi altro tipo di chip. Questo si applica alle configurazioni compatibili con Intel VT.

Infine, ho già sostenuto che l'isolamento dei processi è una forma di sandbox. Leggendo quella risposta e questa, ora dovresti essere in grado di capire perché le definisco in questo modo. Ci sono notevoli somiglianze tra l'isolamento dei processi e le macchine virtuali in x86.

Aggiorna

Quindi, ho approfondito ancora di più questo aspetto, specialmente nel ricerca sulla pillola blu. Quello che ho descritto è una visione di alto livello molto semplicistica. Ho trovato più dettagli. Ecco un documento intero dedicato ad esso da Invisible Things Lab. Si scopre che i loro discorsi sulle difese includevano il concetto di negare l'accesso in esecuzione alle pagine in modalità utente dall'anello 0, impedendo così l'esecuzione diretta dei dati che la macchina virtuale ha inserito in memoria. Si scopre che questo viene implementato nelle CPU Intel e le patch attualmente esistono nel kernel Linux. Quindi, a seconda di come va, potrebbe essere il caso che attacchi di questa natura diventino molto più difficili, anche se esistono degli exploit.

Ho fatto un bel po 'di sperimentazione di malware all'interno di una VM, principalmente utilizzando backtrack4 per passare da un host all'altro. Sono un utente di VMware Workstation, principalmente.

Il problema maggiore deriva dalla possibilità che la connessione di rete della tua VM venga nuovamente trasferita al tuo sistema operativo host. Vuoi disabilitare completamente la rete e / o utilizzare una rete che non ha accesso al tuo host.

Limitare la memoria è una buona best practice. Generalmente lo tengo a circa un quarto, come te. Il tempo della CPU è limitato al numero di core o (se si dispone di controlli granulari nel software) alla percentuale di tempo della CPU definita per la specifica VM.

Gli attacchi mirati in grado di uscire dall'ambiente virtuale esistono e sono disponibili in commercio, come il cloudburst menzionato da @Hendrick, ma sono relativamente rari. Mantenersi aggiornati sulle patch di virtualizzazione è un'ottima idea.

Vedi qui, qui e qui per i dettagli.

Oltre a tutte le buone informazioni qui sulla possibilità che il virus possa fuoriuscire dalla VM, vorrei sottolineare un altro problema da considerare:

È possibile che il codice dannoso rilevi se viene eseguito all'interno di una macchina virtuale oppure no. Questo viene spesso chiamato rilevamento della macchina virtuale o "pillole rosse" e sono disponibili molte tecniche.

Inoltre, alcuni virus e altri malware utilizzano queste tecniche per rilevare se vengono eseguiti in una VM e, in tal caso, disattivare il loro payload (evitare di intraprendere azioni dannose). Lo fanno per cercare di rendere la vita più difficile alle persone per decodificare il malware o rilevarlo.

Di conseguenza, una VM non è un buon modo per scoprire cosa fa un malware. Il malware potrebbe non essere in grado di uscire dalla VM, ma allo stesso tempo potrebbe non eseguire alcuna operazione quando è in esecuzione all'interno della VM. Se lo esegui nella VM e vedi che non fa nulla, decidi che è innocuo e poi decidi di eseguirlo al di fuori della VM: potresti essere posseduto. Fai attenzione là fuori.

Qualunque cosa intendiate per voi, Abilitare l'impostazione del BIOS per interagire con il vostro computer, sarà facile da manipolare o violare dall'hacker. Immagino che se il software che usi online venisse violato. semplice come sarebbe molto meglio acquistare l'estensione della memoria piuttosto che consentire all'applicazione software in linea di gestirla. questi pensieri sono solo un certo punto di vista. beh, che tu ci creda o non hai studiato online per gli hacker al giorno d'oggi, ce ne sono molti di cui non puoi immaginare che abbiano detto che sono oltre milioni in tutto il mondo.