¿Es posible que una máquina virtual como VirtualBox tenga la vulnerabilidad de seguridad "espectro"? Creo que la máquina virtual tal vez realiza una ejecución fuera de orden, pero en mi opinión no es posible mirar el caché para leer el resultado.

¿Hay alguna explicación de cómo es posible leer el caché de una CPU virtual?

Sí, Spectre puede cruzar los límites de host / invitado, invitado / host e invitado / invitado porque este es un defecto de nivel de CPU que significa que se puede filtrar información potencialmente confidencial a través de cualquier cosa que se ejecute en un núcleo de CPU.

La mayoría de las noticias en Internet hablan de los proveedores de la nube más afectados por esto, ya que tienen grupos masivos de sistemas que están virtualizados y podrían ser abusados ​​para filtrar información confidencial.

La mayoría de los grandes proveedores ya deberían haber sido reparados contra las fallas, lo mejor que pueden ser, pero este será un problema que vivirá con nosotros por algún tiempo.

Security.SE tiene preguntas y respuestas canónicas al respecto y menciona las máquinas virtuales:

Estoy ejecutando una máquina virtual / contenedores, ¿en qué medida soy vulnerable?

Según la respuesta de Steffen Ullrich

• Los ataques de fusión no cruzan las máquinas virtuales, solo filtran la memoria del núcleo a los procesos locales.
• Specter puede trabajar en máquinas virtuales.

Además, desde Steffen nuevamente , Meltdown and Spectre trabaja con contenedores, ya que los contenedores se basan en el núcleo del host.

Las máquinas virtuales usan la CPU real en su sistema con algunas instrucciones privilegiadas atrapadas y que pueden redirigirse. Utiliza los mismos cachés e instrucciones que el host. Esencialmente es solo otra capa dentro de la CPU física en su sistema.

La virtualización solo es rápida porque utiliza la CPU física con la menor abstracción posible y depende del hardware de la CPU para proporcionar aislamiento. Cosas como qemu pueden hacer una emulación que sería más segura ya que no es una CPU de hardware, pero es mucho más lenta y diferente de la virtualización.

Desde la publicación canónica Security.se nuevamente:

Specter trabaja en un nivel diferente y no permite el acceso a los datos del espacio del núcleo desde el espacio del usuario. En este ataque, el atacante engaña la ejecución especulativa para ejecutar instrucciones predictivas erróneamente. En pocas palabras, el predictor se ve obligado a predecir un resultado de rama específico (si -> verdadero), que resulta en solicitar un acceso a la memoria fuera del límite que el proceso de la víctima normalmente no habría solicitado, lo que resulta en una ejecución especulativa incorrecta. Luego, por el canal lateral, recupera el valor de esta memoria. De esta manera, la memoria que pertenece al proceso de la víctima se filtra al proceso malicioso.

Entonces, debido a que la VM se ejecuta en el hardware real de la CPU y todo lo que necesita hacer es ejecutar un ciclo particular para "entrenar" el motor de ejecución especulativo. Luego, puede usar el tiempo preciso para observar los cachés para patrones particulares de acceso indicativos del proceso de host o invitado (u otra VM) que está buscando explotar.

De esta manera, significa que una máquina es explotable en todas las direcciones. De host a VM, de VM a host, y de VM a VM.

Sí, de ninguna manera es fácil y es algo difícil de lograr, ya que el núcleo de la CPU de VM podría cambiar a voluntad del host y el host también podría programar tareas en diferentes núcleos, pero durante un largo período de tiempo suficiente información podría filtrarse para entregar una clave secreta a algún sistema o cuenta importante. Dado el tiempo suficiente y un software sigiloso adecuado, todo está potencialmente abierto.

Si desea una máquina virtual "segura", debe garantizar que sus núcleos estén aislados. Las únicas formas reales de bloquear este ataque serían "obligar" al host y a las máquinas virtuales a usar solo ciertos núcleos para que nunca se ejecuten en el mismo hardware, pero esto conduciría a un aumento efectivo en el costo, ya que no podría tener tantas máquinas virtuales en un host determinado. Nunca sería capaz de ejecutar más máquinas virtuales de las que tiene núcleos disponibles, que es algo que esperaría que se hiciera en servidores de "baja carga", ya que muchos sistemas permanecen inactivos durante el 90% de su vida útil.

gem5

Si está interesado en estudiar / reproducir vulnerabilidades únicamente con la emulación, sin usar la CPU host, no creo que QEMU sea lo suficientemente detallado como para observarlas, ya que no simula la canalización de la CPU.

Sin embargo, gem5 se utiliza para estimar el rendimiento del sistema en investigación y desarrollo, y simula suficientes componentes internos de la CPU para que pueda observar a Spectre en un entorno completamente limpio y controlado.

Se ha publicado una demo x86_64 con visualización en: http://www.lowepower.com/jason/visualizing-spectre-with-gem5.html

La desventaja de gem5 es que es mucho más lento que QEMU, la simulación es más detallada.