Re: [ml] Whitepaper sulla virtualizzazione e sicurezza

Premesso che sono un semplice utilizzatore di tecnologie di
virtualizzazione, seguo con molto interesse però la vostra
discussione. A proposito di quello che è stato detto, mi è sorto un
grosso dubbio:

Il 03/04/07, Claudio Telmon<claudio@xxxxxxxxxx> ha scritto:
> Se ho ben capito il discorso, la logica della virtualizzazione
> dovrebbe essere diversa. La virtualizzazione (mi riferisco alla
> virtualizzazione completa, altrimenti le cose sono meno lineari) non
> ti permette di vedere il sistema guest: anche con il controllo
> completo del kernel della macchina virtuale, non puoi fare più di
> quello che l'hypervisor ti concede. È vero che la granularità è
> quella del sistema operativo, ma è il sistema operativo della
> macchina virtuale, sulla quale di principio puoi arrivare ad avere
> un controllo completo. Se sulla tua macchina virtuale gira un server
> apache, e tu sei già riuscito a compromettere quel server fino al
> punto da riuscire ad eseguire codice arbitrario come root, cosa
> riesci ad ottenere di più? La logica dovrebbe essere: niente, se sei
> in una macchina virtuale, il resto della macchina se sei solo in un
> chroot. Questo naturalmente come modello, prescindendo quindi da
> difetti implementativi.

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] ?
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?

Spero di non aver fatto un'osservazione banale,
saluti

Marco

[1] VMware NAT Networking Buffer Overflow Vulnerability:
http://secunia.com/advisories/18162/