Seguridad microarquitectónica de AWS Firecracker VMM: análisis de ataques y defensas microarquitectónicas

Tabla de enlaces

• Resumen e introducción
• Fondo
• Modelos de amenazas
• Análisis de los sistemas de contención de petardos.
• Análisis de ataques y defensas microarquitectónicas en microvms petardos
• Conclusión, agradecimientos y referencias

5. ANÁLISIS DE ATAQUES Y DEFENSAS MICROARQUITECTÓNICAS EN MICROVMAS PETERADOS

En esta sección presentamos nuestro análisis de una serie de PoC de ataque especulativo y de canal lateral de microarquitectura en microVM Firecracker. Probamos estas PoC en instancias bare metal y Firecracker, y probamos defensas de microcódigo relevantes en los distintos escenarios. Realizamos nuestras pruebas en un servidor con una CPU Intel Skylake 4114

que tiene extensiones de hardware de virtualización y SMT habilitado. La CPU funciona con la versión de microcódigo 0x2006b06[2]. El sistema operativo anfitrión es Ubuntu 20.04 con un kernel Linux 5.10. Usamos Firecracker v1.0.0 y v1.4.0, la última versión de julio de 2023, para ejecutar un invitado Ubuntu 18.04 con el kernel de Linux 5.4 que proporciona Amazon al seguir la guía de inicio rápido[3].

En resumen, la configuración de host de producción recomendada proporcionada con AWS Firecracker es insuficiente cuando se trata de proteger a los inquilinos de vecinos maliciosos. Por lo tanto, Firecracker no ofrece las garantías de aislamiento que afirma. Esto es porque

(1) identificamos una variante de Medusa que solo se vuelve explotable cuando se ejecuta en microVM. Además, las contramedidas recomendadas no contienen los pasos necesarios para mitigar el canal lateral ni la mayoría de las otras variantes de Medusa.

(2) demostramos que los inquilinos no están adecuadamente protegidos de las fugas de información inducidas a través de Spectre-PHT o Spectre-BTB al aplicar las contramedidas recomendadas. Las variantes Spectre-PHT siguen siendo un problema incluso cuando se desactiva SMT.

(3) no observamos diferencias en el rendimiento de PoC entre Firecracker v1.0.0 y v1.4.0.

Concluimos que la capa de virtualización proporcionada por Firecracker tiene poco efecto en los ataques de microarquitectura y que las recomendaciones de seguridad del sistema de Firecracker son insuficientes.

5.1 Medusa

Evaluamos las PoC de Moghimi [35] para los canales laterales Medusa [37] (clasificados por Intel como variantes MLPDS de MDS [25]) en el metal desnudo de nuestro sistema de prueba y en máquinas virtuales Firecracker. Hay una prueba de concepto con fugas para cada una de las tres variantes conocidas descritas en la sección 2.4.2. Usamos dos programas víctimas de la biblioteca PoC:

• El programa “Block Write” escribe una gran cantidad de datos consecutivos en un bucle (para que el procesador identifique los almacenamientos repetidos y los combine).

• El programa “REP MOV” realiza una operación similar, pero con la instrucción REP MOV en lugar de muchas instrucciones moviendo bloques más pequeños de datos en un bucle.

5.1.1 Resultados. La Tabla 1 muestra los casos en los que los datos se filtran exitosamente con todas las protecciones de microarquitectura en el kernel deshabilitadas. Las dos columnas de la izquierda muestran las posibles combinaciones de los tres PoC de Medusa y los dos programas de víctimas incluidos. Las columnas de la derecha indican qué configuraciones funcionan sin sistema operativo y con el programa secreto y con fugas ejecutándose en instancias paralelas de Firecracker. En particular, con la variante Cache Indexing, el secreto de escritura en bloque solo funciona con Firecracker. Es probable que esto se deba a la virtualización de la dirección de memoria que proporciona la máquina virtual: el invitado solo ve las regiones de memoria virtual asignadas por KVM, y KVM captura las instrucciones de acceso a la memoria y maneja las transacciones en nombre del invitado.

Probamos la efectividad de las defensas mds y nosmt contra cada combinación de PoC de atacante y víctima en máquinas virtuales bare metal y Firecracker. La Tabla 2 enumera las protecciones necesarias para prevenir ataques de Medusa en escenarios bare metal y Firecracker. De las cuatro vulnerabilidades de Firecracker, solo una se mitiga solo con nosmt, y AWS no recomienda explícitamente habilitar la protección mds, aunque la mayoría de las distribuciones de Linux la incluyen habilitada de forma predeterminada. Es decir, una plataforma en la nube multiinquilino podría utilizar Firecracker de una manera que cumpla con las medidas de seguridad recomendadas por AWS y seguir siendo vulnerable a la mayoría de las variantes de Medusa, incluida una en la que el propio Firecracker VMM filtra los datos del usuario que de lo contrario no se filtrará.

5.2 RIDL y más

En esta sección, presentamos una evaluación de los programas PoC de RIDL [51] proporcionada junto con el artículo de van Schaik et al. de 2019 [50]. RIDL es una clase de ataques MDS que explota cargas especulativas de los buffers dentro de la CPU (no del caché o la memoria). El repositorio RIDL PoC también incluye ejemplos de ataques publicados en adiciones posteriores al documento, así como una variante del ataque Fallout MDS.

5.2.1 Resultados. La Tabla 3 muestra información básica sobre las PoC de RIDL que probamos y la eficacia de las contramedidas relevantes para prevenir los ataques. Comparamos los ataques al metal desnudo y a Firecracker para evaluar las afirmaciones de Amazon sobre la mayor seguridad del hardware del sistema microVM Firecracker. Para las pruebas en el sistema Firecracker, distinguimos entre indicadores de contramedidas habilitados en el sistema host (H) y el kernel invitado de Firecracker (VM). Además de los indicadores del kernel nosmt y mds, probamos otros indicadores relevantes (consulte la sección 2.4.4, [21]), incluidos kaslr, pti y l1tf, pero no encontramos que tuvieran un efecto en ninguno de estos programas. Excluimos la mitigación tsx_async_abort ya que la CPU que probamos incluye mitigación mds, lo que hace que el indicador del kernel tsx_async_abort sea redundante [20].

En general, encontramos que la protección mds no protege adecuadamente contra la mayoría de los ataques RIDL. Sin embargo, deshabilitar SMT mitiga la mayoría de estos exploits. Esto es consistente con las declaraciones de Intel [25] y de los desarrolladores de Linux [21] de que SMT debe desactivarse para evitar ataques MDS a través de hiperprocesos. Los dos valores atípicos entre estos PoC son alineación_write, que requiere tanto nosmt como mds en el host, y pgtable_leak_notsx, que se mitiga únicamente con contramedidas mds. La fuga que depende de alineamiento_write utiliza una falla de alineación en lugar de una fuga de falla de la tabla de páginas para desencadenar especulaciones [50]. El documento RIDL [50] y la documentación de Intel sobre el exploit VRS relacionado [26] no son claros acerca de qué diferencia exactamente este ataque de los ataques MFBDS basados en fallas de página que se encuentran en otros PoC, pero nuestros hallazgos experimentales indican que el mecanismo microarquitectónico de la fuga es distinto. Existe una explicación simple y razonable para el comportamiento de pgtable_leak_notsx, que es único entre estos PoC por una razón clave: es el único exploit que cruza los límites de seguridad (filtrando valores de la tabla de páginas del kernel) dentro de un solo subproceso en lugar de filtrarse desde otro hilo. Es evidente que deshabilitar los subprocesos múltiples tendría poco efecto en este exploit de un solo subproceso. Sin embargo, la contramedida mds vacía los buffers de microarquitectura antes de cambiar de la ejecución con privilegios del kernel a la ejecución con privilegios de usuario dentro del mismo hilo, borrando los datos de la tabla de páginas a los que accede el código del kernel desde el LFB antes de que el código del usuario atacante pueda filtrarlos.

A diferencia de Medusa, la mayoría de estos PoC se ven mitigados por la recomendación de AWS de deshabilitar smt. Sin embargo, al igual que con Medusa, el Firecracker VMM en sí no proporciona protección microarquitectónica contra estos ataques.

5.3 Espectro

A continuación nos centramos en las vulnerabilidades de Spectre. Si bien se han desarrollado muchas contramedidas desde que se descubrieron por primera vez los ataques de Spectre, muchas de ellas conllevan una penalización (significativa) de rendimiento o solo mitigan parcialmente el ataque. Por lo tanto,

Los operadores de sistemas a menudo tienen que decidir entre rendimiento y seguridad. En esta sección evaluamos la superficie de ataque de Spectre disponible para los inquilinos de Firecracker en ambos modelos de amenaza descritos anteriormente. Para evaluar la amplia gama de ataques de Spectre, nos basamos en las pruebas de concepto proporcionadas en [15]. Para Spectre-PHT, Spectre-BTB y SpectreRSB, el repositorio contiene cuatro PoC cada uno. Se diferencian en la forma en que el atacante desvía a la BPU. Las cuatro posibilidades son (1) mismo proceso: el atacante tiene control sobre el proceso de la víctima o sus entradas para desorientar la BPU; (2) proceso cruzado: el atacante ejecuta su propio código en un proceso separado para influir en las predicciones de rama de el proceso de la víctima – (a) en el lugar – el atacante desvía la BPU con instrucciones de rama que residen en la misma dirección virtual que la rama de destino que el atacante quiere que se prediga mal en el proceso de la víctima – (b) fuera de lugar: el atacante desvía la BPU con instrucciones de rama que residen en direcciones que son congruentes con las ramas objetivo en el proceso de la víctima.

(1) mismo proceso: el atacante tiene control sobre el proceso de la víctima o sus entradas para desorientar a la BPU,

(2) proceso cruzado: el atacante ejecuta su propio código en un proceso separado para influir en las predicciones de rama del proceso de la víctima,

(3) en el lugar: el atacante desvía la BPU con instrucciones de rama que residen en la misma dirección virtual que la rama objetivo y que el atacante quiere que se prediga erróneamente en el proceso de la víctima.

(4) fuera de lugar: el atacante desvía la BPU con instrucciones de rama que residen en direcciones que son congruentes con las ramas objetivo en el proceso de la víctima.

Las dos primeras situaciones y las dos últimas son ortogonales, por lo que cada PoC combina dos de ellas. Para Spectre-STL, solo se conocen variantes del mismo proceso, razón por la cual el repositorio solo proporciona dos PoC en este caso. Para experimentos entre máquinas virtuales, deshabilite la aleatorización del diseño del espacio de direcciones para los núcleos host e invitado, así como para el nivel de usuario host e invitado, para facilitar la búsqueda de direcciones congruentes que se utilizan para el entrenamiento incorrecto.

5.3.1 Resultados. Con las contramedidas recomendadas por AWS [8] (las predeterminadas para los kernels de Linux en uso, consulte la Figura 5) habilitadas en el sistema host y dentro de las máquinas virtuales Firecracker, vemos que Spectre-RSB se mitiga con éxito tanto en el host como dentro y entre las máquinas virtuales. (ver Tabla 4). Por otro lado, Spectre-STL, Spectre-BTB y Spectre-PHT permitieron la fuga de información en situaciones particulares.

Las PoC de Spectre-STL muestran fugas. Sin embargo, la fuga sólo ocurre dentro del mismo proceso y el mismo nivel de privilegio. Como no se conocen variantes entre procesos, no probamos el escenario crossVM para Spectre-STL. En nuestro modelo de amenaza de usuario a usuario, Spectre-STL no es un posible vector de ataque, ya que no se conocen variantes entre procesos. Si dos cargas de trabajo de inquilinos se aislaran mediante aislamiento en proceso dentro de la misma VM, Spectre-STL aún podría ser un vector de ataque viable. En el modelo de usuario a host, Spectre-STL se mitiga mediante contramedidas que se incluyen en los kernels de Linux actuales y están habilitadas de forma predeterminada.

Para Spectre-PHT, las contramedidas del kernel incluyen la desinfección de los punteros de usuario y la utilización de barreras (lfence) en los cambios de nivel de privilegios. Por lo tanto, llegamos a la conclusión de que SpectrePHT representa poca o ninguna amenaza para el sistema anfitrión. Sin embargo, estos

Las mitigaciones no protegen dos hiperprocesos entre sí si se ejecutan en el mismo núcleo físico en paralelo. Esta es la razón por la que las cuatro variantes de desentrenamiento de Spectre-PHT son completamente funcionales en el sistema host, así como dentro de las máquinas virtuales Firecracker. Como se puede ver en la Tabla 4, esto sigue siendo cierto incluso si SMT está desactivado[4]. De hecho, fijar ambas máquinas virtuales al mismo subproceso físico permite la versión fuera de lugar de procesos cruzados de Spectre-PHT, mientras que no observamos fugas en el caso de SMT. Esto convierte a Spectre-PHT en una amenaza importante para el usuario.

Las PoC de Spectre-BTB son parcialmente funcionales cuando las contramedidas recomendadas por AWS están habilitadas. La variante original que desalinea el BTB en el mismo proceso y en la misma dirección es completamente funcional, mientras que el desalineamiento fuera de lugar en el mismo proceso es

mitigado con éxito. Además, todos los intentos de filtrar información a través de los límites del proceso mediante un entrenamiento incorrecto fuera de lugar no mostraron ninguna fuga. Sin embargo, con el mal entrenamiento in situ entre procesos, observamos fugas. En el sistema anfitrión, la fuga se produjo independientemente de SMT. Dentro de una VM, la fuga solo se produjo si todos los núcleos de CPU virtuales se asignaron a un subproceso físico separado. En todas las máquinas virtuales, la desactivación de SMT eliminó la fuga.

Además de las contramedidas enumeradas en la Figura 5, el kernel del host tiene contramedidas de Spectre compiladas en los puntos de entrada y salida de la VM[5] para impedir por completo que invitados maliciosos ataquen el kernel del host mientras el kernel maneja una salida de la VM.

En resumen, podemos decir que las contramedidas predeterminadas de Linux, recomendadas por AWS Firecracker, solo mitigan parcialmente Spectre. Precisamente, mostramos:

• Spectre-PHT y Spectre-BTB aún pueden filtrar información entre inquilinos en el escenario de huésped a huésped si se implementan las contramedidas recomendadas por AWS, que incluyen la desactivación de SMT.

• Es probable que el kernel del host esté suficientemente protegido por las precauciones adicionales que se compilan en el kernel de Linux para proteger las entradas y salidas de la VM. Sin embargo, esto es ortogonal a las medidas de seguridad proporcionadas por Firecracker.

Todas las fugas observadas fueron independientes de la versión Firecracker en uso.

5.3.2 Evaluación. Descubrimos que Firecracker no aumenta las mitigaciones contra Spectre, sino que se basa únicamente en recomendaciones de protección generales, que incluyen mitigaciones proporcionadas por los kernels host e invitado y actualizaciones de microcódigo opcionales. Peor aún, las contramedidas recomendadas no protegen suficientemente las aplicaciones sin servidor para que no filtren información a otros inquilinos. Por lo tanto, afirmamos que Firecracker no logra su objetivo de aislamiento a nivel de microarquitectura, aunque los ataques a microarquitectura se consideran dentro del alcance del modelo de amenaza de Firecracker.

El lector alerta podría preguntarse por qué Spectre-BTB sigue siendo un problema con la contramedida STIBP implementada (consulte la Figura 5), ya que este parche de microcódigo fue diseñado para evitar que la predicción de rama utilice información de predicción que se origina en otro hilo. Esto también nos desconcertó por un tiempo hasta que recientemente Google publicó un aviso de seguridad[6] que identifica una falla en Linux 6.2 que seguía deshabilitando la mitigación STIBP cuando IBRS estaba habilitado. Verificamos que la sección de código identificada como responsable del problema también está presente en el código fuente de Linux 5.10. Por lo tanto, suponemos que el mismo problema identificado por Google también ocurre en nuestro sistema.

[2] Actualizar el microcódigo a una versión más reciente deshabilitaría TSX en nuestro sistema, lo que haría imposibles las pruebas con variantes de MDS basadas en TSX.

[3] https://github.com/firecracker-microvm/firecracker/blob/ dbd9a84b11a63b5e5bf201e244fe83f0bc76792a/docs/getting-started.md

[4] Esto se simula fijando el proceso del atacante y de la víctima en el mismo núcleo ((1PT))

[5] https://elixir.bootlin.com/linux/v5.10/source/arch/x86/kvm/vmx/vmenter.S#L191

[6] https://github.com/google/security-research/security/advisories/GHSA-mj4w6495-6crx