Cos'e'#
Un hypervisor e' il software (o firmware) che crea e gestisce le macchine virtuali (VM), permettendo a piu' sistemi operativi di girare sullo stesso hardware fisico in modo isolato. La differenza tra Type 1 e Type 2 e' dove si posiziona nell'architettura: direttamente sull'hardware (Type 1) o sopra un OS host (Type 2). Questo impatta performance, sicurezza e uso tipico.
Astrae l'hardware fisico e permette a piu' sistemi operativi (guest) di girare contemporaneamente in isolamento, allocando CPU, RAM e storage virtualmente tra le VM.
TL;DR#
- Type 1 (bare metal) = hypervisor gira direttamente sull'hardware, nessun OS host in mezzo. Piu' performante e sicuro. Usato in cloud e datacenter enterprise (AWS, Azure, VMware ESXi).
- Type 2 (hosted) = hypervisor gira come applicazione sopra un OS host (macOS, Windows, Linux). Meno performante, piu' semplice da usare. Ideale per lab e sviluppo (VirtualBox, UTM).
- VM Escape = vulnerabilita' che permette a codice nella VM guest di uscire dal confine dell'hypervisor e compromettere l'host. Il rischio peggiore nella virtualizzazione: un solo guest compromesso puo' dare controllo su tutti.
- VM Sprawl = proliferazione silenziosa di VM non gestite e non patchate. Non e' un attacco, e' un problema di governance che crea superficie d'attacco invisibile.
- Container vs VM: container condividono il kernel host (piu' leggeri, isolamento minore). VM hanno kernel separato (piu' pesanti, isolamento hardware completo). Container escape e' statisticamente piu' probabile di VM escape.
Hypervisor Type 1 vs Type 2#
La distinzione tra Type 1 e Type 2 e' architetturale: dove si inserisce il layer di virtualizzazione nello stack hardware-software.
| Caratteristica | Type 1 (Bare Metal) | Type 2 (Hosted) |
|---|---|---|
| Posizione nello stack | Direttamente sull'hardware | Sopra OS host |
| Performance | Massima | Ridotta |
| Sicurezza | Migliore (meno superficie) | Maggiore superficie d'attacco |
| Installazione | Complessa, richiede hardware dedicato | Semplice, come qualsiasi app |
| Uso tipico | Datacenter, cloud, produzione | Lab, sviluppo, desktop |
| Esempi | ESXi, Hyper-V, KVM, Xen | VirtualBox, VMware Workstation, UTM |
Dev parallel: Barno usa UTM su Mac con Ubuntu Server e Kali Linux. UTM usa QEMU con HVF (Hypervisor.framework di macOS) come backend, il che lo rende un Type 2: gira sopra macOS come qualsiasi altra applicazione. I cloud provider (AWS, Azure, GCP) usano Type 1: KVM (Linux kernel-based) o Hyper-V bare metal. Ogni istanza EC2 e' una VM Type 1 guest su un host fisico AWS che non vedi mai. Quando fai
ssh ec2-user@ip, ti connetti a una VM Type 1 che condivide l'hardware fisico con decine di altri clienti AWS, completamente isolata.
VM Escape#
La VM Escape e' un attacco in cui codice malevolo eseguito all'interno di una VM guest riesce a uscire dal confine dell'hypervisor e accedere al sistema host. E' considerato uno degli attacchi piu' gravi in ambienti virtualizzati perche' l'hypervisor gira con privilegi equivalenti a quelli di amministratore sull'host fisico: un VM escape riuscito da' controllo illimitato su host e su tutte le VM guest.
Caso reale - Pwn2Own 2017: tre vulnerabilita' concatenate da vendor diversi. Prima: bug nel motore JavaScript di Microsoft Edge per accedere alla sandbox del browser. Seconda: exploit del kernel Windows 10 per escalare a controllo completo del guest. Terza: bug nella simulazione hardware VMware per saltare all'hypervisor. Nessuna delle tre singolarmente e' sufficiente, ma concatenate danno VM escape completo. VMware ha rilasciato patch prima che l'exploit fosse usato in produzione.
VM Escape e' un attacco attivo, non un problema di governance. La difesa principale e' tenere l'hypervisor aggiornato con le patch piu' recenti. Gibson: "Keeping systems up to date with current patches is the best protection from VM escape attacks."
VM Sprawl#
Il VM sprawl e' un problema di governance, non un attacco. Quando non esiste un processo formale per creare e gestire VM, chiunque ne puo' creare una, usarla e dimenticarla accesa. Queste VM orfane non vengono aggiunte ai sistemi di patch management, non vengono monitorate, non vengono aggiornate: diventano superfici d'attacco non visibili e non gestite.
Dev parallel: in Azure e AWS le VM sprawl detection rientra nelle responsabilita' di chi gestisce l'infrastruttura cloud. Un Azure Policy che blocca la creazione di VM senza tag obbligatori (owner, environment, expiry) o un AWS Config Rule che segnala istanze EC2 non taggate sono i controlli tecnici corrispondenti. Microsoft Sentinel puo' avere alert su "VM attiva da piu' di 30 giorni senza patch documentata" per gestire automaticamente il problema.
Container vs VM#
Container e VM sono spesso confrontati come alternativi, ma virtualizzano layer diversi dello stack. La VM astrae l'hardware fisico: ogni VM ha il proprio kernel, il proprio OS, e l'isolamento e' a livello hardware (l'hypervisor media). Il container astrae l'OS: ogni container condivide il kernel dell'host, ma ha il proprio filesystem isolato e i propri namespace. Questo li rende molto piu' leggeri e veloci, ma con isolamento inferiore.
| Confronto | VM | Container |
|---|---|---|
| Virtualizza | Hardware | OS (namespace + cgroups) |
| Kernel | Proprio per ogni VM | Condiviso con l'host |
| Isolamento | Forte - VM escape e' difficile | Buono ma meno completo |
| Avvio | Minuti | Millisecondi |
| Dimensione | GB | MB |
| Vincolo OS | No | Si, stesso OS dell'host |
| Caso d'uso | Ambienti separati, compliance | Microservizi, CI/CD |
CVE-2019-5736 (runc container escape): vulnerabilita' critica in runc, il runtime container usato da Docker e Kubernetes. Un container malevolo poteva sovrascrivere il binario runc sull'host durante l'esecuzione, ottenendo accesso root all'host fisico. L'exploit sfruttava il fatto che il kernel e' condiviso: un attacco al layer OS colpisce sia il container che l'host.
Dev parallel: Docker container su Linux condividono il kernel host. Se c'e' una vulnerabilita' nel kernel Linux (es. privilege escalation), tutti i container sull'host sono potenzialmente esposti indipendentemente dall'isolamento dei namespace. Una VM avrebbe un kernel separato: la stessa vulnerabilita' nel kernel guest non tocca l'hypervisor. Per questo in ambienti ad alta sicurezza (banking, difesa, PCI-DSS) si preferisce la VM al container per workload critici: il costo in performance e' accettabile rispetto al livello di isolamento garantito.
Collegato a#
- docker-overview - Docker e' la piattaforma container piu' usata
- docker-network - networking nei container e isolamento
- docker-security - hardening container e best practice sicurezza
- ids-ips - IDS/IPS a livello rete anche per il traffico tra VM
- linux-processes - namespace e cgroups alla base dell'isolamento container
