12 votos

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

Preguntas:

  • si una máquina virtual está dañado (hackeado), ¿qué he de riesgo en otros Vm que se ejecutan en la misma máquina física?
  • ¿Qué tipo de problemas de seguridad hay entre máquinas virtuales en ejecución en el mismo host físico?
  • Hay (se puede hacer) una lista de los (potenciales) debilidades y/o problemas?

Advertencia:

Sé que muchos de los tipos de virtualización y soluciones existen, y pueden tener diferentes debilidades. Sin embargo, yo soy todo buscando general de los problemas de seguridad acerca de las técnicas de virtualización, en lugar de un proveedor determinado error.

Sírvanse proporcionar datos reales, (graves) de los estudios, problemas experimentados o explicaciones técnicas. Ser específico. No (sólo) dar su opinión.

  • Ejemplos:

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

EDIT: también he encontrado este "Ras+Reload" ataque capaz de recuperar GnuPG claves secretas en la misma máquina física, mediante la explotación de la L3 de caché de CPU, incluso si GnuPG se ejecuta en otra VM. GnuPG ha sido revisado desde entonces.

13voto

Michael Hampton Puntos 88271

En teoría, no. El punto central de todo el hipervisor es aislar las máquinas virtuales de cada uno de los otros.

En la práctica, ha sido (y podría ser en el futuro) errores de seguridad en varios hipervisores que podría permitir una máquina virtual a afectar el hipervisor o de otras máquinas virtuales en el mismo host. Medidas de seguridad tales como sVirt (para KVM/QEMU) están destinados a resolver este problema.

9voto

Falcon Momot Puntos 16915

Por supuesto que es posible explotar otra máquina virtual que se ejecuta en el mismo hardware, dado un trabajo de explotar. Además, uno puede existir. Su pregunta cites algunos trabajos recientes que muestran. No voy a compartir cualquier específicos explota o PoC aquí, pero estaré encantado de decir cómo se puede hacer.

Las hazañas que se utilizan en este contexto son, naturalmente, diferentes de las que funcionan cuando se está ejecutando en la misma máquina que usted está tratando de explotar un servicio, y tienden a ser un poco más difícil debido a la mayor aislamiento. Sin embargo, algunos criterios generales que pueden ser usados para llevar a cabo tal explotar incluyen:

  • Ataque el hipervisor. Si usted puede conseguir una lo suficientemente privilegiado de shell en el hipervisor dada una máquina virtual, usted puede tener el control sobre cualquier máquina virtual en el sistema. La forma de abordar esto es buscar los flujos de datos que existen de la VM en el hipervisor, y son muy hipervisor-dependiente; cosas como controladores paravirtualizados, portapapeles, de compartir, de salida de pantalla, y el tráfico de la red tienden a crear este tipo de canal. Por ejemplo, una llamada maliciosa a un paravirtualizados dispositivo de red podría provocar la ejecución de código arbitrario en el hipervisor en el contexto de la responsabilidad de aprobar que el tráfico de la NIC física del conductor.
  • Ataque con el hardware del host. Muchos dispositivos permiten actualizaciones de firmware, y si es posible acceder al mecanismo para que a partir de una máquina virtual, se puede cargar un nuevo firmware que favorece a sus intenciones. Por ejemplo, si se le permite actualizar el firmware de la tarjeta de red, usted podría duplicar el tráfico obligado para una dirección MAC (de la víctima), pero con otra dirección MAC de destino (el suyo). Por esta razón muchos de los hipervisores filtro de comandos, donde sea posible; ESXi filtros de actualizaciones de microcódigo cuando proceden de una máquina virtual.
  • El ataque de la acogida de la arquitectura. El ataque citado, esencialmente otro sincronización de claves basada en la divulgación de ataque, hace esto: explota el mecanismo de almacenamiento en caché del impacto en la operación de temporización de discernir los datos que están siendo utilizados por la víctima de la VM en sus operaciones. En el núcleo de la virtualización es el intercambio de componentes; cuando un componente es compartida, la posibilidad de un canal lateral existe. En la medida en que otra máquina virtual en el mismo host es capaz de influir en el comportamiento del hardware mientras se ejecuta en la víctima de VM contexto, la víctima VM es controlado por el atacante. La referencia de ataque hace uso de la VM de la capacidad para controlar el comportamiento de la caché de CPU (esencialmente universales compartidos estado), de modo que la memoria de la víctima tiempos de acceso más revelar con precisión los datos es de acceso; donde compartió estado global existe, la posibilidad de una revelación, también existe. A paso en el hipotético para dar ejemplos, imaginar un ataque que los masajes ESXi del VMFS y hace las piezas de los volúmenes virtuales de referencia en el mismo disco físico direcciones, o un ataque que hace que una memoria de globos de sistema creer algo de memoria puede ser compartida cuando en realidad debería ser privada (esto es muy similar a cómo la use-after-free o doble-asignación de trabajo hazañas). Considere la posibilidad de un hipotético de la CPU MSR (modelo de registro específicas) que el hipervisor ignora, pero permite el acceso; esto podría ser utilizado para pasar los datos entre máquinas virtuales, romper el aislamiento de la hipervisor debe proporcionar. Considere también la posibilidad de que la compresión se utiliza para que duplicar los componentes de los discos virtuales se almacenan sólo una vez - una (muy difícil) de canal lateral puede existir en algunas configuraciones donde un atacante puede discernir el contenido de otros discos virtuales por escrito a su propia y observar lo que el hipervisor. Por supuesto, un hipervisor se supone que debe proteger contra este y los ejemplos hipotéticos sería crítico de los fallos de seguridad, pero a veces estas cosas a través de deslizamiento.
  • Atacar a la otra VM directamente. Si usted tiene un proximal de acogida a la víctima VM, usted puede ser capaz de tomar ventaja de relajado de control de acceso o intencional inter-VM comunicación dependiendo de cómo el host está configurado y en los supuestos que se hizo la hora de implementar el control de acceso. Este es sólo un poco pertinente, pero son dignas de mención.

Ataques específicos se levantará y será parcheado como pasa el tiempo, por lo que no es siempre válida para clasificar algunas mecanismo particular como ser aprovechables aprovechables sólo en condiciones de laboratorio, o unexploitable. Como se puede ver, los ataques tienden a estar involucrados y difícil, pero que son viables en un momento determinado es algo que cambia rápidamente, y usted necesita estar preparado.

Dicho esto, los vectores que he mencionado arriba (con la posible excepción de la última, en ciertos casos), simplemente no existen en el bare-metal de los entornos. Así que sí, dado que la seguridad es acerca de la protección contra las hazañas que no conocen y que no están en la naturaleza, así como las que han sido divulgada públicamente, usted puede ganar un poco de seguridad mediante la ejecución en metal desnudo o, al menos, en un entorno donde el hipervisor no de host de máquinas virtuales para propios y extraños.

En general, una estrategia efectiva para la aplicación segura de programación sería asumir que un equipo tiene otros procesos que se ejecutan en lo que podría ser el atacante controlados o malintencionado y use exploit-conocimiento de técnicas de programación, incluso si usted piensa que son lo contrario, asegurando que ningún proceso de este tipo que existe en su VM. Sin embargo, particularmente con las dos primeras categorías, recuerde que el que toca el hardware primero gana.

8voto

Ryan Ries Puntos 33449

Edit: pensé que este tema fue hecho con hace meses, pero ha sido renovada y ahora OP está pidiendo más real de los hechos, los citados estudios, etc., así que pensé, ¿qué diablos.

Hazañas de esta naturaleza son:

  1. Raras
  2. Sensible en la naturaleza y por lo tanto no se comparte abiertamente, y cuando lo son, las hazañas serían revisados por el vendedor antes de que alguien en este sitio nunca se sabía acerca de ellos
  3. Complicadas y varían según el proveedor

No podemos decir que es imposible hackear un hipervisor y tener acceso a otras máquinas virtuales. Tampoco podemos cuantificar cuánto riesgo hay, salvo que la experiencia nos muestra que es muy baja, teniendo en cuenta que no vas a encontrar muchas historias de ataques que utilizan hipervisor explota.

Aquí está una especie de interesante artículo al contrario que sugiere que más que un par basada en hipervisor ataques se han llevado a cabo.

Sin embargo, con la tecnología dependiendo de hipervisores ahora más que nunca, explota iba a ser reparado y protegido contra con más urgencia que casi cualquier otro tipo de aprovechamiento.

Aquí es un extracto de la IBM X-Force De 2010 a Mediados de Año la Tendencia y el Informe de Riesgo:

(Favor de abrir una imagen en una nueva pestaña para verla a tamaño completo.)

IBM X-Force 2010 Mid-Year Trend and Risk Report.

Notificación de la medida porcentaje de "Escape a hipervisor" vulnerabilidades, lo cual suena bastante aterrador para mí. Naturalmente, usted querrá leer el resto del informe, como no hay muchos más datos para respaldar las afirmaciones.

Aquí es una historia acerca de un posible explotar llevado a cabo en la Playstation 3 hipervisor, que es divertido. Tal vez no tan impactantes para su negocio, a menos que su negocio es de Sony, en cuyo caso es muy impactante.

Aquí está un maravilloso artículo de Eric Horschman de VMware, en la que él viene a mí suena como un adolescente en plena anti-Micro$oft, pero aún así es un buen artículo. En este artículo, encontrarás cositas como esta:

Los residentes en Microsoft de cristal de la casa había algunas otras piedras para tirar nuestro camino. Microsoft señaló CVE-2009-1244 como un ejemplo de un invitado breakout vulnerabilidad en ESX y ESXi. Un invitado de breakout explotar empresa seria, pero, una vez más, Microsoft está tergiversando la hechos. VMware respondió rápidamente a la revisión que la vulnerabilidad en nuestro productos y ESX fue mucho menos afectada que la de Microsoft llevaría usted para creer:

Argucias entre los competidores. Pero, probablemente, la más lúcida de las cosas que él dice en el artículo completo es este:

La verdad es que, vulnerabilidades y exploits nunca completamente lejos de cualquier software de la empresa.

6voto

kce Puntos 9227

La siempre destacable Theo de Raddt del proyecto OpenBSD:

Usted está absolutamente engañados, no se si es tonto, si usted piensa que un colección mundial de ingenieros de software que no se puede escribir operativo los sistemas o aplicaciones sin agujeros de seguridad, se puede convertir entonces en torno a y de repente escribir la virtualización de las capas sin agujeros de seguridad.


Un poco inflamatoria, pero su punto es bien tomado. En la teoría de la virtualización se supone para proporcionar un aislamiento completo entre las máquinas virtuales y su huésped. Hay en la práctica ocasional de las vulnerabilidades de seguridad que permiten avanzado atacantes para circunnavegar estas protecciones y tener acceso a otras máquinas virtuales o en el peor de su anfitrión (véase Un Estudio Empírico en la Seguridad de la Exposición a los Ejércitos Hostiles Entornos Virtualizados). Como Ryan Ries menciona este tipo de vulnerabilidades son bastante raros (que no significa que no existan) y a menudo no es revelada por los vendedores, pero existen.

Si usted está preocupado sobre el potencial de este tipo de ataques (y creo que hasta cierto punto se debe) os recomiendo que no mezcle las zonas de seguridad en un único host virtual o virtual host del clúster. Por ejemplo - a usted le han dedicado dos host virtual host de clúster para la DMZ máquinas virtuales, un clúster dedicado para middleware y un clúster dedicado para la protección de los activos. De esta manera, en el caso de que una vulnerabilidad es explotada en forma tal que permite a un atacante para subvertir otras máquinas virtuales o peor que el hipervisor sí mismo su modelo de seguridad sigue intacta.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: