Nel 2010 il giornalista Paul Rubens intervistava Jonathan Brossard (ai tempi CTO di P1 Code Security ed attualmente arruolato nella divisione di sicurezza informatica Salesforce) sui rischi della virtualizzazione in ambienti condivisi.
Brossard affermò che la presenza di più VM (virtual machine) ospitate sullo stesso hardware rappresenta un fattore di potenziale rischio: “ciò significa che non occorre più individuare un exploit remoto. La condivisione è davvero interessante per i malintenzionati perchè anche i bug locali più insignificanti hanno un “valore”: la virtualizzazione non fa altro che amplificarne [l’efficacia]. [Acquisire i privilegi dell’host] da guest è [relativamente semplice], per questo la sicurezza mediante la virtualizzazione è un fallimento” sentenziava il CTO.
Le dichiarazioni risalgono come già detto a sei anni fa: nel mentre la virtualizzazione e gli hypervisor si sono evoluti ed abbiamo assistito anche all’arrivo (o al ritorno) dei container, un’interessante soluzione alternativa . I container sono delle VM indipendenti dal sistema operativo (OS) dell’host con il quale condividono solo il kernel. Rispetto alle virtualizzazione classica, i container richiedono un quantitativo di risorse minore permettendo di eseguire più applicazioni su un singolo host OS. Da quando Docker li ha rilanciati con successo nell’industria, si è tuttavia parlato diffusamente degli imprevisti legati al loro utilizzo.
Una scuola di pensiero considera generalmente le VM una soluzione più sicura dei container perchè in grado di assicurare un grado superiore di isolamento: un’applicazione eseguita in una VM dispone infatti di un proprio sistema operativo e non condivide il kernel con l’host. Le applicazioni “containerizzate”, dovendo necessariamente appoggiarsi al kernel dell’host, possono dare vita in certi casi a spiacevoli incidenti come la fuga di processi interni nel kernel space dell’host.
Sicurezza e VM: sei anni dopo
Come risaputo, nel mondo dell’informatica non esistono soluzioni infallibili ed in grado di assicurare una protezione totale: ci sarà sempre qualche bug (minore o critico) che verrà sfruttato dal malintenzionato di turno per superare il “perimetro difensivo”; a loro volta arriveranno le consuete patch correttive degli sviluppatori, in grado di bloccare gli exploit di consentire che il ciclo appena descritto ricominci da capo. Tenendo conto di quanto appena detto, in riferimento alla virtualizzazione ed alle VM possono verificarsi le seguenti ed indesiderate situazioni:
- VM escape. Quando il guest di una VM riesce ad ottenere il controllo dell’host sottostante.
- VM DDoS. Un attacco effettuato da un guest admin con l’obiettivo di causare il crash della macchina/host e di tutte le altre VM guest presenti.
- VM Hopping. Quando il “proprietario” di una VM trova il modo di indirizzare un attacco ad altre VM presenti sul medesimo hypervisor.
Secondo alcuni esperti di sicurezza online, gli indiscutibili vantaggi offerti dal cloud computing pubblico (convenienza, flessibilità etc.) hanno fatto dimenticare ai più i pericoli insiti in un ambiente condiviso. Un recente bug che ha interessato il noto hypervisor Xen dimostra invece come l’attenzione debba essere mantenuta sempre alta.
Il bug in questione, abbastanza serio, consentiva di mettere in atto la precedentemente menzionata pratica della VM escape, garantendo ad un guest admin paravirtualizzato (solo su hardware x86, i guest completamente virtualizzati su x86 ed ARM non sono invece in grado di sfruttare la falla) l’acquisizione degli stessi privilegi dell’host admin.
Considerando che Xen è uno degli hypervisor più adoperati nel cloud computing, la falla avrebbe potuto facilmente trasformarsi in un problema di portata globale. Il team di sviluppo dell’hypervisor è fortunamente riuscito a rilasciare in tempo di record un fix, mettendo in sicurezza tutte le versioni dell’hypervisor dalla 4.3.x in su. In conclusione: la questione sicurezza resta e resterà sempre attuale.
