¿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?
Spectre works on a different level ... In this attack, the attacker tricks the speculative execution to predictively execute instructions erroneously. In a nutshell, the predictor is coerced to predict a specific branch result that results in asking for an out-of-bound memory access that the victim process would not normally have requested resulting in incorrect speculative execution. Then by the side-channel, retrieves the value of this memory. In this way memory belonging to the victim process is leaked to the malicious process.qemuhacer 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.Respuestas:
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:
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:
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.
fuente
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.
fuente