Re: [ml] Whitepaper sulla virtualizzazione e sicurezza

Marco Simioni wrote:
> Ma chi mi garantisce che non esiste un modo per sfruttare
> vulnerabilità dello strato di virtualizzazione stesso, per esempio un
> banale buffer overflow che mi permette, partendo dalla macchina guest,
> di iniettare del codice nell'applicativo che realizza lo strato di
> virtualizzazione, e fare un privilege escalation andando ad eseguire
> codice nella macchina host, così come già capitato se non sbaglio nel
> caso [1] ?

Nessuno. Qualsiasi cosa tu realizzi può avere dei bachi, qualsiasi
meccanismo di sicurezza può essere di conseguenza inefficace. Questo
è il senso della difesa in profondità giustamente citato nel papero
di Paternò: avere più linee di difesa o, se vuoi, costringere
l'attaccante a superare (trovare vulnerabilità in) diversi
meccanismi diversi e contemporaneamente. Quindi, quando confronti
due modelli diversi, da questo punto di vista devi vedere quanto è
facile che ci siano bug e quanto sono efficaci in termini di difesa
in profondità. Se parti dal confinamento di un'applicazione in una
macchina virtuale, per arrivare ai dati in un'altra macchina
virtuale deve trovare delle vulnerabilità nell'applicazione, di qui
trovare vulnerabilità nel kernel in modo da poter sfruttare
eventuali vulnerabilità nell'interazione con lo strato di
virtualizzazione. In un ambiente chroot c'è un passaggio in meno,
dato che una volta trovata la vulnerabilità nel kernel in gioco è fatto.

> Così come non dobbiamo prescindere da bug implementativi del kernel,
> sfruttabili per fare privilege escalation, perchè dobbiamo prescindere
> da difetti implementativi di applicativi magari non opensource?

Perfetto. Lo strato di virtualizzazione di vmware è realizzato
mediante alcuni moduli nel kernel del sistema host (parlo di linux),
che quindi aumentano la massa (già enorme) di codice eseguita nel
kernel e quindi la probabilità che nel kernel ci siano bachi. Da
questo punto di vista il modulo di vmware non si comporta
diversamente da un qualsiasi modulo, a parte eventuali dicussioni
sul codice proprietario che sono legate al prodotto e non al
modello. Quindi vmware aumenta il controllo sugli applicativi nei
sistemi guest ma aumenta la vulnerabilità del sistema host. Il
chroot ha un minore controllo sull'applicativo ma non introduce di
per sè vulnerabilità nel sistema "host": minore profondità delle
difese, ma maggiore robustezza di uno degli strati (e non uno strato
da poco). Nell'esempio che citi, è un caso che la vulnerabilità
venga sfruttata dal sistema guest, un baco poteva tranquillamente
permettere di attaccare il sistema host da remoto, come una
qualsiasi vulnerabilità in un modulo di netfilter.
Io continuo a preferire il sistema virtuale, perché in un kernel la
probabilità di bachi che permettono di uscire da un chroot è secondo
me maggiore di quello di bachi in un modulo di virtualizzazione tipo
quello di vmware. Naturalmente, è uno di quei casi in cui la
valutazione del rischio è fatta a spanna ;)

ciao

- Claudio

-- 

Claudio Telmon
claudio@xxxxxxxxxx
http://www.telmon.org