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

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?

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.

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