Mientras una máquina virtual no ejecute un código no confiable, no .
Tenga en cuenta que "ejecutar código no confiable" incluye tomar fragmentos de código de Github, StackOverflow o cualquier otro lugar y ejecutarlos en una caja de arena de cualquier tipo, como: a chroot , un contenedor aislado o un virtual máquina (pero excepto un entorno limitado del navegador, como Brython o Emscripten, una vez que las mitigaciones del navegador estén en su lugar).
Si una VM puede en cualquier circunstancia ejecutar un código no confiable, la respuesta es: depende . Todavía es posible que no necesite todas o algunas de las mitigaciones de un JS El motor ahora presenta , pero su modelo de amenaza se vuelve mucho más complicado.
A partir de ahora, se deben cumplir algunos requisitos para que su VM esté expuesta teóricamente a Meltdown o los efectos de Spectre:
-
La máquina virtual ejecuta un código no confiable que puede, al menos, enviar mensajes al mundo exterior.
Incluyendo, entre otros, acceso a Internet o permisos para mostrar o escribir datos en una ubicación a la que un atacante podría acceder posteriormente en algún momento.
-
La máquina virtual permite el uso de temporizadores o herramientas de alta precisión que podrían usarse para medir el tiempo de ejecución relativo de las instrucciones del lenguaje de programación respectivo.
Incluyendo, pero no limitado a, búferes compartidos entre subprocesos concurrentes.
-
La VM presenta técnicas de optimización que, al menos en teoría, podrían permitir que el código no confiable se ejecute con aproximadamente la eficiencia del código compilado.
Incluyendo, pero no limitado a, compilación Just-in-time (JIT) o generación de bytecode optimizada.
Se cree [ citation needed ] , que al menos en el caso de CVE-2017-5715, bajo ciertas circunstancias (por ejemplo, presencia de secuencias de instrucciones binarias particulares en el sistema bibliotecas y una serie de eventos desafortunados), este requisito en particular podría ser más relajado o mejorado.
-
Se cumple cualquiera de las siguientes condiciones:
- No se aplican las mitigaciones de SO para Meltdown
- La máquina virtual carga una información confidencial en el mismo proceso donde podría ejecutarse el fragmento de código no confiable
- Un atacante puede proporcionar algo de entrada en cualquier otro proceso (que tiene una información confidencial en su memoria y se ejecuta en el mismo sistema físico en el que se ejecuta el código no confiable) mientras se ejecuta el código no confiable, desde el código no confiable a sí mismo o por cualquier otro medio, directa o indirectamente
Si las cuatro condiciones anteriores son verdaderas, entonces, en teoría, su máquina virtual podría usarse para extraer una información confidencial de su sistema, basada en los efectos de Spectre y / o Meltdown.
Un ejemplo simple de una máquina virtual que, si bien con frecuencia ejecuta un código de terceros, no está expuesto a Specter es el VM de lenguaje de sugerencias de glifos TrueType que no permite la sincronización de subprocesos o instrucciones de ninguna manera, por lo tanto, al menos, el requisito # 2.
Una nota importante sobre las actualizaciones del sistema.
En el caso de Javascript PoC, Meltdown o Spectre no se utilizan para leer la memoria del kernel o la memoria de otros procesos. Pueden serlo, pero el problema principal con Specter en Javascript VM es que la VM se ejecuta en un recinto de seguridad (destinado a ser aislado y seguro antes) dentro de un proceso de navegador que contiene datos confidenciales (contraseñas de sitios web, cookies, etc.). / p>
Las actualizaciones del SO (por ejemplo, KPTI para Linux) no ayudarán a mitigar el problema por completo, porque:
- Se dirigen a Meltdown mientras que el problema principal es Specter;
- Lo único que garantiza KPTI es que un proceso no podría leer la memoria del kernel (y la memoria de otros procesos asignados al espacio del kernel, solo a través de Meltdown). KPTI no prohíbe que un hilo en un proceso lea una memoria que, desde el punto de vista del sistema operativo, esté disponible para que lea todo el proceso, como es el caso de las contraseñas y las cookies almacenadas en el mismo navegador. corre en.
Además, para ser cien por cien exactos, ha preguntado si se necesitan "mitigaciones similares" (para las máquinas virtuales de JS) en máquinas virtuales para otros idiomas. Tenga en cuenta que una máquina virtual contemporánea de JS en el navegador ya cuenta con una caja de arena bien diseñada que tiene acceso limitado al sistema de archivos, IPC, lenguaje ensamblador y otros recursos del sistema. En caso de que su máquina virtual (por ejemplo, una máquina virtual V8 JS que se envía con la plataforma Node.js) tenga más permisos o capacidades que la que tiene una máquina virtual JS en el navegador, es posible que no requiera similar , sino más allá y mitigaciones más estrictas.
A partir del 14 de enero de 2018, esto es en teoría; Pero tu pregunta también es teórica.