it-swarm.dev

Una macchina virtuale impedisce al malware di fare del male?

Vorrei sapere se è sicuro per il sistema Host di una macchina virtuale (VM - VirtualBox OSE nel mio caso) eseguire malware.

Un virus può scoppiare e leggere o scrivere dati dal sistema host? Può stabilire una connessione Internet se la disabilito nella mia macchina virtuale?

A VM è un ambiente sicuro per provare a scoprire cosa fa un virus?

Una bomba a forcella può "uccidere" il sistema Host se riduco la memoria a circa 1/4 della mia memoria reale totale? Quanta CPU tempo/risorse può usare?

66
Martin Thoma

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

Esistono alcuni tipi di attacchi contro i quali VM sono molto efficaci, ad es. bombe a forcella. Dal punto di vista del sistema host, VM è un singolo processo. Una bomba a forcella nell'ospite metterà in ginocchio lo schedulatore nel sistema operativo ospite , ma per l'host questo sarà totalmente innocuo. Allo stesso modo per la memoria: VM emula una macchina fisica con una determinata quantità di RAM e avrà bisogno di quella quantità di "reale" RAM per eseguire il backup in modo efficiente. Indipendentemente da ciò che fa l'ospite, VM non monopolizzerà mai più RAM di quello. (Vuoi ancora limitare VM RAM alle dimensioni, diciamo, al massimo 1/2 delle tue dimensioni fisiche RAM, perché "extra" reale RAM è utile per la memorizzazione nella cache del disco e anche il sistema operativo host ne utilizzerà alcune.)

55
Tom Leek

Disclaimer: sto andando per una comprensione di livello relativamente alto. Se vuoi una guida dettagliata, è fuori portata. Inoltre, ci sono altri modi (interamente nel software) per implementare macchine virtuali a cui questo non si applica. Mi sto anche concentrando sul "superamento" solo attraverso i meccanismi di virtualizzazione, vale a dire non quelli che possono accadere da PC a PC su host di rete reali.

Mi piacciono i dettagli, quindi eccoci con alcuni. In primo luogo, codeproject ha alcuni eccellenti riferimenti assembler su diverse modalità di una CPU x86 (reale, protetta e lunga) e uso di virtualizzazione . C'è un blog Intel VT (non sono sicuro che Intel scriva questo) e infine la prima parte del Rootkit Arsenal è dedicata alla spiegazione di x86 ed è una lettura eccellente, completo di procedure dettagliate e diagrammi di Nizza. Comprendere tutto richiede pazienza, quindi quello che farò qui è fare una breve introduzione su come funziona.

Il modo in cui abbiamo oscillato quando abbiamo eseguito DOS

DOS e primi sistemi a 16 bit in modalità reale utilizzano un modello di memoria segmentato. Non vi è alcun controllo sulla dimensione dei segmenti e non vi sono interruttori di protezione su nessuno di questi segmenti. Il codice viene caricato in un segmento di memoria e viene eseguito; può saltare di gran lunga in altri segmenti, quindi qualsiasi codice, ovunque può alterare qualsiasi cosa, incluso la produzione di un pezzo di codice TSR (termina e rimani residente) che punta semplicemente una delle voci IVT (tabella vettoriale di interrupt) a un indirizzo nel suo spazio, prima di eseguire l'originale. Fondamentalmente, non esiste protezione. Nessuna. Nada.

L'aumento della modalità protetta a 32 bit

La modalità protetta si complica rapidamente. Ci sono tre parti: segmentazione, paginazione e PAE. Ognuno richiede una tabella di dati che informi la CPU su quel segmento, pagina o aiuta a estendere lo spazio degli indirizzi (PAE). Questi includono le famose bandiere ad anello (si applicano a segmenti e pagine) che implementano l'isolamento del processo. Il paging è il tuo modo di caricare i dati da 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 obbliga semplicemente le strutture PAE/Paging. Ancora una volta, per banalizzare totalmente l'implementazione di un sistema operativo, il paging è controllato da strutture in memoria che vengono quindi impostate tramite istruzioni speciali. Voilà, si può ottenere l'isolamento del processo con le giuste impostazioni. Ancora una volta, sto banalizzando leggermente ...

Dammi la virtualizzazione!

Va bene. La virtualizzazione è il stesso concetto generale. Le macchine virtuali sono configurate utilizzando strutture di controllo delle macchine virtuali che determinano il modo in cui la loro memoria viene mappata sulla memoria fisica, un po 'come il paging. Fondamentalmente, in determinate condizioni, alla macchina virtuale verrà richiesto di chiedere qualcosa al sistema operativo Host, un po 'come l'isolamento del processo, un po' come un interruzione del software. Questi sono chiamati VM esce e fornisce informazioni all'host come lo stato dei registri all'uscita. Kinda proprio come una chiamata di sistema.

Può un malware uscire da una macchina virtuale?

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

In termini di impatto diretto sulla memoria host, la macchina virtuale non può, perché non può vederla. L'host deve mappare la memoria richiesta nello spazio della macchina virtuale. Inoltre, in quello spazio di memoria, deve implementare tutto dal BIOS in su. Per comunicare con determinati dispositivi host per determinate attività, il computer host deve impostare quelle VM e la destinazione VM deve attivarle. Quando ciò accade, il controllo viene trasferito all'host.

Vi sono quindi due possibili aree a rischio:

  1. Le azioni intraprese dall'host in risposta a VM. Se ci sono bug in questa gestione, potrebbe essere possibile convincere l'host ad eseguire qualcosa che non dovrebbe.
  2. Qualsiasi accesso dell'host allo spazio di memoria della macchina guest. Ricorda che il codice della macchina host in esecuzione nell'anello 0 può entrare in valanga e mandare in crash la festa ovunque lo desideri. Accade così che puoi impostare la memoria dell'ospite dall'ospite (sorprendentemente).

Questo ti porta al tuo meccanismo di exploit. È necessario un bug di gestione nella VM, quindi è necessario essere in grado di persuadere quel codice per eseguire un po 'di memoria, idealmente codice che hai appena inserito in una pagina dal guest vm. Una volta fatto , saluta Kansas.

Come dice Tom Leek, le VM sono incredibilmente efficaci nella difesa contro le bombe a forcella. Analogamente 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 alla VM. Esaurito e il sistema operativo guest ritiene che sia esaurito la memoria fisica; l'host non lo assegnerà di più a meno che implementi un VM per fare questo, che sarebbe un po 'pericoloso e non credo che sia fatto.

Quanto è probabile?

Non molto. Dipende da quelle VM esci completamente dalle implementazioni o dalla lettura della memoria dal guest sull'Host con un bug piacevole nel tuo codice di lettura. Richiede inoltre che detto bug ti consenta di controllare l'arresto anomalo in in modo tale da poter forzare l'esecuzione all'indirizzo di memoria dell'host. L'uscita VM deve essere in grado di accedere a tale 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 interamente implementata da software.
  3. Virtualizzazione su qualsiasi altro tipo di chip. Questo vale per le configurazioni compatibili con Intel VT.

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

Update

Quindi, ho approfondito ancora di più, specialmente nella ricerca sulla pillola blu. Quello che ho descritto è una visione di alto livello molto semplicistica. Ho trovato maggiori dettagli. Ecco un intero documento dedicato ad esso da Invisible Things Lab. Risulta che il loro discorso difese includeva il concetto di negare l'accesso eseguito alle pagine in modalità utente dall'anello 0, impedendo così l'esecuzione diretta dei dati che la macchina virtuale ha messo in memoria. Si scopre che questo è in fase di implementazione nelle CPU Intel e attualmente esistono patch nel kernel di Linux. Quindi, a seconda di come va, può darsi che attacchi di questa natura diventino molto più difficili, anche se esistono degli exploit.

31
user2213

Ho fatto un bel po 'di sperimentazione di malware in un VM - principalmente usando backtrack4 per entrare da un host all'altro. Sono principalmente un utente di VMware Workstation.

Il problema maggiore deriva dalla possibilità della connessione di rete del tuo VM che ritorna al tuo sistema operativo host. Desideri disabilitare totalmente la rete e/o utilizzare una rete che non ha accesso al tuo host .

Limitare la memoria è una buona pratica. In genere lo tengo a circa un quarto, uguale a te. Il tempo della CPU è limitato al numero di core o (se si dispone di controlli più precisi nel software) alla percentuale di tempo della CPU definita per la specifica VM.

Esistono attacchi mirati in grado di uscire dall'ambiente virtuale e sono disponibili in commercio - come cita il cloudburst @Hendrick - ma sono relativamente rari. Aggiornarsi sulle patch di virtualizzazione è un'ottima idea.

Vedi qui , qui , e qui per i dettagli.

11
Tim Brigham

Oltre a tutte le buone informazioni qui sul fatto che il virus possa uscire dalla VM, vorrei sottolineare un altro problema da considerare:

È possibile che il codice dannoso rilevi se viene eseguito all'interno di una macchina virtuale o meno . Questo spesso si chiama rilevamento della macchina virtuale o "pillole rosse" , e ci sono moltitecniche disponibili.

Inoltre, alcuni virus e altri malware utilizzano queste tecniche per rilevare se vengono eseguiti in una macchina virtuale e, in tal caso, arrestare il loro payload (evitare di intraprendere azioni dannose). Lo fanno per cercare di rendere la vita più difficile alle persone che decodificano il malware o lo rilevano.

Di conseguenza, a 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 fare qualcosa quando è in esecuzione all'interno della VM. Se lo si esegue in VM e si vede che non fa nulla, decidere che è innocuo, quindi decidere di eseguirlo al di fuori di VM - potresti essere di proprietà. Fai attenzione là fuori.

10
D.W.