Meltdown & Spectre: ¿parchear el kernel invitado de un hipervisor no parcheado evita pérdidas de memoria entre máquinas virtuales?

12

24 horas después del lanzamiento a gran escala de las vulnerabilidades, Rackspace guarda silencio sobre Specter y Meltdown. No tienen un plan para parchar todos sus hipervisores Xen. Todos sus servidores de plataforma más nuevos son servidores HVM, que son vulnerables. Los servidores fotovoltaicos más antiguos no son vulnerables.

He actualizado el kernel de Linux de mis invitados HVM, pero Rackspace no ha actualizado ninguno de sus hipervisores. ¿La actualización del kernel invitado en un hipervisor no parcheado impedirá que las máquinas virtuales "malvadas" accedan a la memoria filtrada de mi host parcheado?

linux xen cloud-computing rackspace vulnerabilities Danny F
fuente
1
Consulte también security.stackexchange.com/q/176709/11291
Michael Hampton

Respuestas:

12

Por lo que entiendo de las vulnerabilidades, no, los ataques especulativos de almacenamiento en caché omiten todas las protecciones de la CPU contra un proceso que toma memoria de cualquier dirección arbitraria.

Creo que esto incluiría las máquinas virtuales vecinas (incluso aquellas parcheadas para protegerse contra el ataque), así como el espacio de memoria del núcleo del hipervisor, pero incluso si hay algo que me falta que proteja contra la divulgación directa de memoria, también hay potencial que el atacante podría usar su acceso a la memoria del núcleo para obtener un acceso más completo al hipervisor.

Definitivamente no desea arriesgarse a ejecutar una carga de trabajo sensible en un hipervisor sin parches de ningún tipo si no confía en todas las máquinas virtuales que se ejecutan en él.

Shane Madden
fuente
66
En pocas palabras: tener un kernel invitado parcheado puede evitar que su VM acceda al hipervisor u otras VM, ¡pero no evitará que otras VM accedan al suyo!
Michael Hampton
Hola Shane, esa es mi creencia también. ¿Tiene alguna documentación que respalde eso? El punto específicamente sobre la memoria de un invitado parcheado es vulnerable a otros invitados en el mismo hardware. Gracias.
Danny F
2
@DannyF La referencia más directa a esto que pude encontrar fue en el documento de fusión : "memoria física de otros procesos, el kernel y, en el caso de soluciones de sandbox para compartir kernel (por ejemplo, Docker, LXC) o Xen en modo de paravirtualización, memoria del kernel (o hipervisor) y otras instancias de ubicación conjunta "
Shane Madden
-4

Espectro y deshielo.

¿Donde empezamos? un mal, quiero decir muy mal comunicado de prensa de algo que puede o no afectar su computadora, estación de trabajo, servidor o servidor en la nube. Sí, lo es totalmente, pero debe tener acceso local a la CPU asociada, que puede ser una PC o un teléfono, parece que Apple se ha convertido en un ejemplo, pero pensemos en su CPU ARM, por lo que cada plataforma móvil que admite la (función / exposición de microcódigo / demasiado control sobre la CPU desde el sistema operativo / etc / etc)

La aplicación debe ejecutarse en la CPU del dispositivo, por lo que creo que el acceso a la consola, o al menos el usuario remoto que accede al sistema, ingresa el acceso al dispositivo ...

En este momento, la única forma conocida de explotar estas vulnerabilidades es desde el acceso local / directo a la CPU (nuevamente puede ser remoto una vez que tenga SSH / VNC, etc.)

A continuación se encuentran los parches que he encontrado hasta ahora. 

VMWare has released a security advisory for their ESXi, Workstation and Fusion products: VMSA-2018-0002
[https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html][1]

RedHat has released a security advisory for their qemu product:  [https://access.redhat.com/errata/RHSA-2018:0024][1]

Amazon has released a security advisory for their Amazon Linux AMI product: ALAS-2018-939

https://alas.aws.amazon.com/ALAS-2018-939.htm l

Ahora, esta tiene que ser la mejor respuesta al problema en este momento.

¿Qué dijeron nuestros amigos BSD?

Google malo; (

una comprobación de Powershell para lo mismo;)

El kernel de Linux Ok, tuvimos una semana interesante, y ahora todos saben por qué fusionamos todos esos parches de aislamiento de tablas de páginas x86 impares sin seguir todas las reglas de tiempo de lanzamiento normales.

Puedo / volveré y editaré esta publicación. Estoy seguro de que el problema (hasta en la naturaleza) no será un problema real a largo plazo. ¡Google realmente debería haber seguido las fechas de lanzamiento de divulgación aquí! -1 para Google

Andrew Smalley
fuente
"Amazon Linux (AMI)" es la distribución Linux de Amazon, que se ve afectada de la misma manera que todos los demás sistemas operativos invitados. Más relevante en este contexto es aws.amazon.com/de/security/security-bulletins/AWS-2018-013 (sección inicial) para el anuncio de EC2 (su plataforma de virtualización), ya que parecía estar tratando de enumerar las soluciones de virtualización.
Håkan Lindqvist
1
Al leer y releer esto, ¿no creo que realmente aborde la pregunta? ¿Es sobre todo una queja sobre el proceso de divulgación?
Håkan Lindqvist
Agradezco el editorial y los enlaces para las soluciones, pero esta respuesta es engañosa o al menos confusa. Creo que indica que el escenario que describí requeriría acceso local al hipervisor xenserver, lo cual no es cierto. El único requisito es que el malo tenga su propia VM en el mismo hipervisor que la VM de la víctima.
Danny F