¿Puede una máquina virtual (VM) "piratear" otra VM que se ejecuta en la misma máquina física?

Preguntas:

• Si una máquina virtual está dañada (pirateada), ¿qué arriesgo con otras máquinas virtuales que se ejecutan en la misma máquina física?
• ¿Qué tipo de problemas de seguridad hay entre las máquinas virtuales que se ejecutan en el mismo host físico?
• ¿Existe (puede hacer) una lista de esas (potenciales) debilidades y / o problemas?

Advertencia:

Sé que existen muchos tipos / soluciones de virtualización, y pueden tener diferentes puntos débiles. Sin embargo, estoy buscando principalmente problemas de seguridad generales sobre las técnicas de virtualización, en lugar de un error de proveedor en particular.

Proporcione hechos reales, estudios (serios), problemas experimentados o explicaciones técnicas. Se específico. No (solo) dé su opinión.

• Ejemplos:

Hace dos años, escuché que podría haber problemas de seguridad relacionados con la MMU (creo que accediendo a la memoria principal de otras máquinas), pero no sé si eso es una amenaza práctica a día de hoy, o simplemente una investigación teórica tema.

EDITAR: También encontré este ataque "Flush + Reload" capaz de recuperar claves secretas de GnuPG en la misma máquina física, explotando el caché de la CPU L3, incluso si GnuPG se ejecuta en otra VM. GnuPG ha sido parcheado desde entonces.

Por supuesto, es posible explotar otra VM que se ejecute en el mismo hardware, dado un exploit funcional. Además, uno puede existir. Su pregunta cita algunos trabajos recientes que muestran uno. No voy a compartir ningún exploits específico o PoC aquí, pero con mucho gusto diré cómo se pueden hacer.

Los exploits que se utilizan en este contexto son naturalmente diferentes de los que funcionan cuando se ejecuta en la misma máquina en la que intenta explotar un servicio, y tienden a ser un poco más difíciles debido al mayor aislamiento. Sin embargo, algunos enfoques generales que se pueden utilizar para lograr tal vulnerabilidad incluyen:

• Ataca al hipervisor . Si puede obtener un shell suficientemente privilegiado en el hipervisor dado una VM, puede obtener el control sobre cualquier VM en el sistema. La forma de abordar esto es buscar flujos de datos que existan desde la VM al hipervisor, y que sean altamente dependientes del hipervisor; cosas como controladores paravirtualizados, compartir portapapeles, salida de pantalla y tráfico de red tienden a crear este tipo de canal. Por ejemplo, una llamada maliciosa a un dispositivo de red paravirtualizado podría conducir a la ejecución de código arbitrario en el contexto del hipervisor responsable de pasar ese tráfico al controlador NIC físico.
• Ataca el hardware en el host . Muchos dispositivos permiten actualizaciones de firmware, y si es posible acceder al mecanismo para eso desde una VM, puede cargar un nuevo firmware que favorezca sus intenciones. Por ejemplo, si se le permite actualizar el firmware en la NIC, puede hacer que duplique el tráfico vinculado a una dirección MAC (la víctima), pero con otra dirección MAC de destino (la suya). Por esta razón, muchos hipervisores filtran dichos comandos cuando es posible; ESXi filtra las actualizaciones de microcódigo de la CPU cuando se originan desde una VM.
• Atacar la arquitectura del anfitrión. El ataque que citó, esencialmente otro ataque de divulgación de clave basado en el tiempo, hace esto: explota el impacto del mecanismo de almacenamiento en caché en el tiempo de operación para discernir los datos que utiliza la VM de la víctima en sus operaciones. En el núcleo de la virtualización está el compartir componentes; donde se comparte un componente, existe la posibilidad de un canal lateral. En la medida en que otra VM en el mismo host pueda influir en el comportamiento del hardware mientras se ejecuta en el contexto de la VM de la víctima, el atacante controla la VM de la víctima. El ataque al que se hace referencia hace uso de la capacidad de la VM para controlar el comportamiento de la memoria caché de la CPU (esencialmente estado universal compartido) para que los tiempos de acceso a la memoria de la víctima revelen con mayor precisión los datos a los que está accediendo; donde sea que exista un estado global compartido, También existe la posibilidad de una divulgación. Para entrar en lo hipotético para dar ejemplos, imagine un ataque que masajee el VMFS de ESXi y haga que partes de volúmenes virtuales hagan referencia a las mismas direcciones de disco físico, o un ataque que haga que un sistema de memoria crezca que se puede compartir algo de memoria cuando de hecho debería ser privado (esto es muy similar a cómo funcionan los exploits use-after-free o de doble asignación). Considere un MSR hipotético de CPU (registro específico del modelo) que el hipervisor ignora pero que permite el acceso; esto podría usarse para pasar datos entre máquinas virtuales, rompiendo el aislamiento que se supone que debe proporcionar el hipervisor. Considere también la posibilidad de que se use la compresión para que los componentes duplicados de los discos virtuales se almacenen solo una vez; un canal lateral (muy difícil) puede existir en algunas configuraciones en las que un atacante puede discernir el contenido de otros discos virtuales escribiendo solo y observando Lo que hace el hipervisor. Por supuesto, se supone que un hipervisor debe protegerse contra esto y los ejemplos hipotéticos serían errores de seguridad críticos, pero a veces estas cosas se escapan.
• Ataca la otra VM directamente . Si tiene un host proximal a la VM de la víctima, puede aprovechar el control de acceso relajado o la comunicación intencional entre VM, según cómo esté configurado el host y qué suposiciones se hagan al implementar el control de acceso. Esto es solo un poco relevante, pero merece mención.

Surgirán ataques específicos y se remendarán a medida que pase el tiempo, por lo que nunca es válido clasificar algún mecanismo en particular como explotable, explotable solo en condiciones de laboratorio o inexplorable. Como puede ver, los ataques tienden a ser complicados y difíciles, pero cuáles son factibles en un momento determinado es algo que cambia rápidamente, y debe estar preparado.

Dicho esto, los vectores que he mencionado anteriormente (con la posible excepción del último en ciertos casos) simplemente no existen en entornos de metal desnudo. Entonces, sí, dado que la seguridad se trata de proteger contra las vulnerabilidades que no conoce y que no están en la naturaleza, así como las que se han divulgado públicamente, puede obtener un poco de seguridad al ejecutar en metal desnudo o en menos en un entorno donde el hipervisor no aloja máquinas virtuales para todos y cada uno.

En general, una estrategia efectiva para la programación segura de aplicaciones sería asumir que una computadora tiene otros procesos ejecutándose en ella que podrían ser controlados por atacantes o maliciosos y utilizar técnicas de programación con reconocimiento de exploits, incluso si cree que de lo contrario no está asegurando tal proceso existe en su VM. Sin embargo, particularmente con las dos primeras categorías, recuerde que el que toca el hardware primero gana.

En teoría no. El objetivo del hipervisor es aislar máquinas virtuales entre sí.

En la práctica, ha habido (y podría haber en el futuro) errores de seguridad en varios hipervisores que podrían permitir que una máquina virtual afecte al hipervisor u otras máquinas virtuales en el mismo host. Las medidas de seguridad como sVirt (para KVM / QEMU) están destinadas a resolver este problema.

Editar: pensé que este tema se había resuelto hace meses, pero acaba de revivirse y ahora OP está pidiendo más "hechos reales, estudios citados", etc., así que pensé qué diablos.

Las hazañas de esta naturaleza son:

1. Raro
2. Sensibles en la naturaleza y, por lo tanto, no se comparten abiertamente, y cuando lo son, los exploits serían reparados por el vendedor antes de que alguien en este sitio los conozca.
3. Complicado y variará según el proveedor

No podemos decir que es imposible hackear un hipervisor y obtener acceso a otras máquinas virtuales. Tampoco podemos cuantificar cuánto riesgo hay, excepto que esa experiencia nos muestra que es bastante bajo, teniendo en cuenta que no encontrará muchas historias de ataques que utilizan ataques de hipervisor.

Aquí hay una especie de artículo interesante en sentido contrario que sugiere que se han llevado a cabo más de unos pocos ataques basados ​​en hipervisor.

Sin embargo, con la tecnología que depende de los hipervisores ahora más que nunca, tales exploits serían parcheados y protegidos con más urgencia que casi cualquier otro tipo de exploit.

Aquí hay un extracto del Informe de tendencias y riesgos de mitad de año de IBM X-Force 2010:

(Abra esta imagen en una pestaña nueva para verla en tamaño completo).

Observe el porcentaje medido de vulnerabilidades de "Escape al hipervisor", lo que me parece bastante aterrador. Naturalmente, querrá leer el resto del informe, ya que contiene muchos más datos para respaldar los reclamos.

Aquí hay una historia sobre un posible exploit llevado a cabo en el hipervisor de Playstation 3, que es divertido. Tal vez no sea tan impactante para su negocio, a menos que su negocio sea Sony, en cuyo caso es extremadamente impactante.

Aquí hay un maravilloso artículo de Eric Horschman de VMware, en el que se me parece que suena como un adolescente que se está volviendo anti-Micro $ a menudo, pero sigue siendo un buen artículo. En este artículo, encontrará cositas como esta:

Los residentes de la casa de cristal de Microsoft tenían otras piedras para arrojarnos. Microsoft señaló a CVE-2009-1244 como un ejemplo de vulnerabilidad de ruptura de invitado en ESX y ESXi. Un exploit de ruptura de invitados es un asunto serio, pero, una vez más, Microsoft está tergiversando los hechos. VMware respondió rápidamente para corregir esa vulnerabilidad en nuestros productos, y ESX se vio mucho menos afectado de lo que Microsoft le haría creer:

Peleas entre competidores. Pero probablemente lo más lúcido que dice en todo el artículo es esto:

La verdad es que las vulnerabilidades y las vulnerabilidades nunca desaparecerán por completo para ningún software empresarial.

El siempre citable Theo de Raddt del proyecto OpenBSD:

Estás absolutamente engañado, si no estúpido, si crees que una colección mundial de ingenieros de software que no pueden escribir sistemas operativos o aplicaciones sin agujeros de seguridad, pueden dar la vuelta y de repente escribir capas de virtualización sin agujeros de seguridad.

Un poco inflamatorio pero su punto está bien tomado. En teoría, se supone que la virtualización proporciona un aislamiento completo entre las máquinas virtuales y su host. En la práctica, existen vulnerabilidades de seguridad ocasionales que permiten a los atacantes avanzados circunnavegar estas protecciones y obtener acceso a otras máquinas virtuales o, peor aún, a su host (consulte un estudio empírico sobre la exposición de seguridad a hosts de entornos hostiles virtualizados ). Como Ryan Ries menciona, este tipo de vulnerabilidades son bastante raras (lo que no significa que no estén allí) y, a menudo, no son reveladas por los proveedores, pero existen.

Si le preocupa el potencial de este tipo de ataques (y creo que debería estarlo hasta cierto punto), le recomiendo que no mezcle zonas de seguridad en un único host virtual o clúster de host virtual. Por ejemplo, tendría un clúster de host virtual de dos hosts dedicado para máquinas virtuales DMZ, un clúster dedicado para middleware y un clúster dedicado para activos protegidos. De esta forma, en caso de que una vulnerabilidad se explote de tal manera que un atacante pueda subvertir otras máquinas virtuales o, peor aún, el hipervisor, su modelo de seguridad aún está intacto.