¿Puedo asumir de forma segura que otro usuario no puede acceder a mi RAM, por ejemplo? EC2 o Digital Ocean, si suponemos que confío en mi proveedor y no consideramos posibles errores (como Heartbleed) en mi entorno.
tl; dr: La RAM de la máquina virtual es razonablemente privada, dadas las suposiciones establecidas.
No soy un experto en seguridad de máquinas virtuales (expertos reales, corrija los errores en esta publicación), pero esta pregunta me pareció lo suficientemente interesante como para buscar en Google. Esto es lo que encontré.
De una publicación del NIST titulada Recomendaciones de seguridad para Despliegue del hipervisor :
Una de las amenazas comunes en las plataformas de virtualización es un malicioso VM accediendo a áreas de memoria pertenecientes a otras VMs. Esto se llama un Ataque VM Escape. Los procesadores con extensiones de virtualización proporcionan Seguridad contra esto a través de características tales como acceso directo a la memoria. (DMA) la reasignación limita el acceso a DMA a lo que es válido para la VM (es decir, evitar que una máquina virtual realice DMA más allá de su área asignada).
Este párrafo dice que la virtualización acelerada por hardware (que es prácticamente la virtualización de todas que encontrará en 2015) puede imponer restricciones de acceso a la memoria bastante bien, al menos mejor que la virtualización solo de software.
El documento del NIST continúa sugiriendo lo siguiente:
Recomendación de seguridad HY-SR-6: La relación de la configuración combinada La memoria de todas las máquinas virtuales a la memoria RAM del host virtualizado no debe ser muy alto Una proporción típica adoptada es 1.5: 1. En otras palabras, si un El host virtualizado tiene 64 GB de RAM, luego la memoria configurada combinada de todas las máquinas virtuales que se ejecutan en él no debe superar los 96 GB.
Recomendación de seguridad HY-SR-7: el hipervisor debería tener Opciones de configuración disponibles para especificar una RAM física garantizada. para cada VM (que lo requiera) junto con un límite a este valor, y para especificar un valor de prioridad para obtener el recurso de RAM requerido en situaciones de disputa entre múltiples máquinas virtuales.
Es probable que los hosts virtuales populares, como EC2 y DigitalOcean, sigan estas pautas por motivos de seguridad y . Sus máquinas virtuales se ejecutarán con bastante lentitud si sobrevenden la memoria RAM. Sin embargo, para un host de VM menos popular, no sabría si siguieran las pautas o no. Dependiendo de la carga de trabajo de los invitados, el anfitrión puede encontrar rentable vender en exceso.
Ahora recuerde que el host definitivamente puede almacenar el estado de su RAM, y cualquier tipo de vulnerabilidad que permita la ejecución de código arbitrario en el host puede resultar en la lectura de Contenidos de RAM RAM arbitrarios.
El documento NIST también sugiere una vulnerabilidad en la que las imágenes utilizadas para crear máquinas virtuales se ven comprometidas, lo que hace que los usuarios de máquinas virtuales enciendan instancias que ya están comprometidas. Es probable que Amazon y DigitalOcean sigan las recomendaciones de NIST aquí también: que las imágenes de VM deben tener firmas digitales válidas y que las imágenes para instancias de new no se pueden modificar desde una máquina que ejecuta existente instancias. Una vez más, es posible que un hipervisor en la nube fuera de algún dormitorio de la universidad no tenga una seguridad equivalente en las imágenes.
Vale la pena leer todo el documento del NIST, no es muy largo, y también lo son las siguientes preguntas sobre el intercambio de pila:
tl: dr; En este momento de la redacción, los contenedores estilo Docker no son tan seguros como los hipervisores de máquinas virtuales aceleradas por hardware.
En respuesta a @grawity en mi otra respuesta, esta respuesta cubre contenedores como Docker, que se utilizan para ejecutar aplicaciones de forma similar a las máquinas virtuales, pero los contenedores son definitivamente no máquinas virtuales .
¿Cuál es la diferencia entre un contenedor y una máquina virtual? Este artículo de Smartbear explica (el énfasis es mío):
Entonces, ¿por qué debería preocuparse por los hipervisores frente a los contenedores? Bottomley explica que los hipervisores, como Hyper-V, KVM y Xen, todos tienen uno cosa en común: "Se basan en emular hardware virtual". Eso significa que son gordos en términos de requisitos del sistema.
[...]
Los contenedores, por otro lado, están basados en sistemas operativos compartidos. Son mucho más disimulados y más eficientes que los hipervisores. En lugar de Virtualizando hardware, los contenedores descansan sobre un solo Linux. instancia. Esto significa que puede "dejar atrás la basura inútil del 99.9% de VM, dejándole con una cápsula pequeña y limpia que contiene su aplicación " dice Bottomley.
Como lo explica la cita de NIST en mi otra respuesta, la virtualización de hardware tiene beneficios de seguridad. Las plataformas de contenedores eliminan esos beneficios a cambio de mejoras en el rendimiento.
Solomon Hykes, el creador del proyecto Docker, escribió en Hacker News en el verano de 2014 que Docker no garantiza la seguridad contra los huéspedes que no son de confianza:
Recuerde que en este momento, no reclamamos Docker out-of-the-box es adecuado para contener programas no confiables con root privilegios [...] Cuando nos sentimos cómodos. diciendo que Docker out-of-the-box puede contener de forma segura uid0 no confiable programas, lo diremos con claridad.
Se pueden configurar varias configuraciones de refuerzo de seguridad, según las Pautas de seguridad de Docker , pero la seguridad aún se está aplicando. por software . Como indica el documento NIST en mi otra respuesta, un hipervisor acelerado por hardware usa hardware para evitar ataques de escape de VM, lo que reduce drásticamente la superficie de ataque de un huésped malicioso. Aunque Docker puede tener características de seguridad completas, simplemente tiene una superficie de ataque más grande.
En el momento de redactar este documento, recomendaría a los usuarios conscientes de la seguridad que no compartan hosts físicos con contenedores que no sean de confianza, ni que ejecuten contenedores que no sean de confianza en su máquina física. Quizás esto cambie en el futuro.
tl; dr: Son posibles los ataques basados en caché para filtrar RAM. Tendría cuidado de tener una máquina virtual que dedique el 100% de su tiempo de CPU a realizar criptografía con claves secretas. Un atacante también puede ralentizar su VM, lo que podría ayudar a un posible ataque de pérdida de RAM. Además, tenga cuidado con las instantáneas de VM que capturan su RAM en ejecución (aunque la mayoría de los servicios en la nube no lo hacen).
(Sé que tener tres respuestas separadas para la misma pregunta es un poco ridículo, pero representan tres formas distintas de pensamiento que estoy luchando para combinar en una respuesta).
Acabo de encontrar la revisión de Thomas H. Ptacek de Cryptography Engineering , y Menciona brevemente los ataques de canal lateral en las nubes de computación virtualizadas como Amazon EC2. El Sr. Ptacek no enumeró ninguna fuente ni dio ejemplos, pero esto es lo que he aprendido de una tarde (adicional) en Google:
Un documento de abril de 2014 del Instituto de Investigación Móvil de China que demuestra la creación de un canal encubierto entre malware en dos máquinas virtuales. Una de las máquinas virtuales es activada por el atacante, y la otra es tuya. Esto requiere que su máquina virtual ya esté comprometida , pero permite un método muy difícil de detectar la exfiltración de datos. Es posible que esté monitoreando su máquina virtual para detectar tráfico de red saliente malicioso ... pero buscaría en el lugar equivocado, ya que este malware estaría utilizando contención del bus de memoria para transmitir hasta cientos de kilobytes por segundo a La máquina virtual del atacante.
Un artículo de 2014 del Instituto Politécnico de Worcester describe un ataque de sincronización entre máquinas virtuales en AES . Los autores del artículo hicieron grandes esfuerzos para asegurarse de que su ataque funcionara en un entorno de computación en la nube realista, lo que hace que sus resultados sean bastante aterradores. Los autores señalan que la vulnerabilidad es posible gracias a deduplicación de memoria , que es una característica de hipervisor que reduce el uso de memoria al detectar páginas duplicadas. Esto es excelente para el rendimiento, pero la deduplicación es una forma inteligente de violar las pautas de NIST mencionado en mi otra respuesta y exagerar su memoria.
Matthew Green tiene un excelente análisis de un artículo de 2012 que describe los ataques de canales laterales de máquinas virtuales cruzadas. El ataque es más teórico, más difícil de lograr en la práctica y es probable que Amazon haya mitigado las vulnerabilidades involucradas desde entonces.
Un documento de 2010 describe que realizar copias de seguridad y restaurar instantáneas de máquinas virtuales puede debilitar un generador de números aleatorios y causar fuga de datos. En este caso, solo se aplica a los invitados de máquinas virtuales con instantáneas completas , que incluye memoria activa. El documento indica que los servicios en la nube se basan en instantáneas de volumen, que solo incluyen el contenido del disco y no tienen generadores de números aleatorios debilitados en una restauración de instantánea.
Este documento de 2009 de UCSD y MIT CSAIL es uno de los estudios anteriores sobre ataques de canal lateral en cloud computing. Supongo (pero no estoy seguro) que la mayoría de los ataques reales ya están conectados, pero el documento es una lectura notable simplemente porque introduce vívidamente la mentalidad del atacante.
Con respecto a su pregunta original, ninguno de estos ataques directamente filtra datos . La idea detrás de estos ataques es que el atacante simplemente ralentice el VM de la víctima. Sin embargo, tengo la sospecha de que un adversario avanzado podría usar un ataque de desaceleración de E / S como parte de un ataque de robo de RAM más amplio. Por eso, elijo mencionarlo aquí. Tengo algunas ideas sobre cómo usar un ataque de desaceleración de E / S para ayudar, pero no quiero especular de manera incorrecta.
Los dos documentos más relevantes que encontré fueron un documento de diciembre de 2012 que propone vExplorer , un "marco de análisis y medición del rendimiento de E / S de VM distribuido" que se puede utilizar para realizar ataques basados en E / S "y un documento similar de George Washington University describe un marco denominado Swiper .
Lea otras preguntas en las etiquetas shared-hosting memory