Ho appena visto this nuovo escalation di privilegi da Ring 0 a SMM.
Supponiamo che io gestisca una piccola infrastruttura VM / cloud per consentire alle persone interne di eseguire ciò che preferiscono, esiste un modo per impedire che questa vulnerabilità venga sfruttata? Forse alcuni bit CPUID da mascherare?
Questa vulnerabilità è non sfruttabile per l'escape della VM .
L'attacco funziona grosso modo nel seguente modo:
La linea di fondo è che questo tipo di attacco è fattibile solo quando l'attaccante può controllare l'MSR IA32_APIC_BASE.
Supponendo di eseguire macchine virtuali "hardware supportate" (modalità VMX non root), un tentativo di scrivere un MSR da una VM genererà generalmente un'uscita VM, che verrà gestita da VMM. Il modo "normale" di gestire un rimappare MMIO APIC è ignorarlo o emulare il remapping in VMM, ma ciò non causerà la rimappatura dell'intervallo APIC dell'host.
L'unica eccezione che posso pensare è quando il VMM utilizza bitmap MSR (che può essere usato per "autorizzare" determinati MSR per non causare uscite VM), e in qualche modo calcola erroneamente quel bitmap (forse nel processo di fusione dei bitmap MSR quando utilizzando la virtualizzazione nidificata) in un modo che consenta agli ospiti di modificare IA32_APIC_BASE, ma sarebbe una vulnerabilità del VMM stesso.
Detto questo, questa vulnerabilità può ancora essere utile per il post-exploitation: se il tuo VMM viene compromesso, l'hacker può usarlo per bypassare TXT o installare un rootkit molto difficile da rilevare.
is there any way to prevent this vulnerability from being exploited?
In realtà, un modo è usare la virtualizzazione, oppure puoi aspettare una patch ufficiale (Intel si dice che ci stia lavorando)
Jacob Torrey ha anche un interessante post su questo argomento: link
Leggi altre domande sui tag hardware privilege-escalation