Acabo de ver this nueva escalada de privilegios de Ring 0 a SMM.
Diga que estoy operando una pequeña infraestructura de VM / nube para que las personas internas ejecuten lo que quieran, ¿hay alguna forma de evitar que esta vulnerabilidad sea explotada? Tal vez algunos bits CPUID para ocultar?
Esta vulnerabilidad es no explotable para el escape de VM .
El ataque funciona aproximadamente de la siguiente manera:
La conclusión es que este tipo de ataque es factible solo cuando el atacante puede controlar el MSR IA32_APIC_BASE.
Suponiendo que ejecute máquinas virtuales "compatibles con hardware" (modo no root VMX), un intento de escribir un MSR desde una VM generalmente provocará una salida de VM, que será manejada por VMM. La forma "normal" de manejar una reasignación APIC MMIO es ignorarla o emular la reasignación en la VMM, pero esto no hará que la rango APIC del host sea reasignada.
La única excepción que se me ocurre es cuando el VMM usa mapas de bits MSR (que pueden usarse para "poner en la lista blanca" ciertos MSR para no causar salidas de VM), y de alguna manera calcula incorrectamente ese mapa de bits (tal vez en el proceso de fusionar mapas de bits MSR cuando usando la virtualización anidada) de una manera que permita a los invitados modificar IA32_APIC_BASE, pero eso sería una vulnerabilidad del VMM en sí.
Dicho esto, esta vulnerabilidad todavía puede ser útil para una explotación posterior: si su VMM se ve comprometida, el atacante puede usarla para evitar TXT o instalar un rootkit muy difícil de detectar.
¿Hay alguna forma de evitar que esta vulnerabilidad sea explotada?
En realidad, una forma es usar la virtualización, o puedes esperar un parche oficial (se dice que Intel está trabajando en ello).
Jacob Torrey también tiene una interesante entrada de blog sobre este tema:
enlace
Lea otras preguntas en las etiquetas hardware privilege-escalation