Panoramica
Il 13 maggio 2015, il ricercatore sulla sicurezza Jason Geffner di CrowdStrike ha rivelato pubblicamente una vulnerabilità in alcune piattaforme di virtualizzazione che potrebbero consentire un utente malintenzionato per uscire dalla sandbox di una macchina virtuale (VM) e ottenere l'accesso all'host di virtualizzazione protetto. La vulnerabilità è stata battezzata "VENOM", per Virtualized Environment Neglected Operations Manipulation (CVE-2015-345) e interessa qualsiasi host di virtualizzazione senza patch basato sull'emulatore QEMU open source, inclusi Xen, KVM e VirtualBox di Oracle. Le tecnologie che non utilizzano QEMU, come VMWare, Hyper-V di Microsoft e Bochs, non sono interessate.
Principale sulla virtualizzazione
La virtualizzazione, in termini generali, è un'implementazione tecnologica che consente a un computer di grandi dimensioni di suddividere le proprie risorse (processore, memoria, spazio su disco rigido, ad esempio) per eseguire molti computer virtuali più piccoli. Ognuna di queste macchine virtuali viene eseguita come se fosse un sistema discreto, isolato dalle altre macchine virtuali in esecuzione sullo stesso host. Questa architettura consente agli operatori di server di gestire e distribuire più facilmente i server, poiché possono creare una nuova VM in molto meno tempo di quanto sarebbe necessario per creare una versione fisica. Consente inoltre agli operatori di data center e ai provider di hosting di utilizzare in modo più efficiente le proprie risorse. Un host di virtualizzazione che esegue, ad esempio, 10 macchine virtuali utilizza una frazione dello spazio, dell'alimentazione e del raffreddamento utilizzati da 10 macchine fisiche equivalenti.
Cosa può fare un exploit contro VENOM?
Uno degli altri vantaggi di una piattaforma di virtualizzazione è la capacità di separare le macchine virtuali. Pertanto, anche se possono utilizzare lo stesso hardware condiviso, le macchine virtuali sono isolate. Tale isolamento consente a un amministratore del server di eseguire il provisioning di diverse VM, che eseguono diversi sistemi operativi, per diversi clienti. Quei clienti non avrebbero mai saputo che stavano condividendo risorse su un host di virtualizzazione con altri clienti. E anche se disponevano dei privilegi di root o amministratore sulle loro VM, il contenimento impedisce loro di fare qualsiasi cosa che possa influire su qualsiasi altra VM.
Questo concetto di infrastruttura in silos è ciò che rende così preoccupante l'idea di una vulnerabilità come VENOM. Come descrive Geffner sul sito web CrowdStrike:
Questa vulnerabilità può consentire a un utente malintenzionato di sfuggire ai confini di un guest di una macchina virtuale (VM) interessata e di ottenere potenzialmente l'accesso per l'esecuzione di codice all'host. In assenza di mitigazione, questa fuga di VM potrebbe aprire l'accesso al sistema host e a tutte le altre VM in esecuzione su quell'host, offrendo potenzialmente agli avversari un accesso significativo e elevato alla rete locale dell'host e ai sistemi adiacenti.
Per un provider che ha fatto affidamento sulla sicurezza dell'isolamento delle macchine virtuali, una tale vulnerabilità può causare un certo allarme.
Quanto allarme?
Sebbene l'annuncio di questa vulnerabilità sia stato paragonato, in alcuni media, a Heartbleed, è importante soppesare ciò che è noto rispetto a ciò che è possibile e probabile.
Secondo Geffner, la "vulnerabilità VENOM esiste dal 2004", sebbene nessun exploit noto (al momento della stesura di questo articolo) sia stato documentato in natura. Geffner ha condiviso le sue scoperte con i principali fornitori di virtualizzazione che utilizzano QEMU il 20 aprile 2015. Dopo aver sviluppato una patch, ha pubblicato le sue scoperte sul sito Web CrowdStrike il 13 maggio 2015.
Ad oggi, tuttavia, non è stata dimostrata alcuna prova di concetto pubblica. Al momento non sappiamo quanto sia semplice o difficile creare codice in grado di sfruttare VENOM. Poiché VENOM lascia un sistema aperto agli attacchi tramite il vecchio amico dell'hacker, l'overflow del buffer, potrebbe, nella sua forma più semplice, essere sfruttato per causare il crash della macchina host, con conseguente denial of service. Con maggiore attenzione e intelligenza, un utente malintenzionato potrebbe potenzialmente ottenere l'accesso all'host di virtualizzazione stesso ed essere in grado di compromettere le altre VM in esecuzione su quello stesso host.
Cosa possiamo fare per proteggerci?
Poiché VENOM è stato divulgato in modo responsabile, dando ai fornitori il tempo di produrre una patch, spetta agli amministratori degli host di virtualizzazione applicare la patch il più rapidamente possibile. Gli individui i cui servizi vengono eseguiti su macchine virtuali in esecuzione su una piattaforma di virtualizzazione condivisa possono fare poco da soli. Possono, tuttavia, visitare il sito Web del loro provider per vedere se sono vulnerabili e quali misure vengono adottate per affrontare la vulnerabilità. Se necessario, possono esercitare pressioni per spingere i loro amministratori a patchare i loro sistemi prima che questa potenziale minaccia diventi un exploit funzionale ampiamente utilizzato dal lato oscuro di Internet.
Per saperne di più su ciò che Atlantic.Net sta facendo per affrontare la vulnerabilità di VENOM, dai un'occhiata al nostro blog per le ultime novità. Ci sforziamo costantemente di offrire i server privati virtuali più sicuri offrendo il meglio in applicazioni di installazione con un clic come cPanel Hosting, tra gli altri.
Aggiornato il 15 maggio 2015 per includere il link al blog Atlantic.Net