Seguridad microarquitectónica de AWS Firecracker VMM: análisis de los sistemas de contención de Firecracker

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

4. ANÁLISIS DE LOS SISTEMAS DE CONTENCIÓN DE PETEROS

La Figura 2 muestra la contención ofrecida por Firecracker, tal como la presenta AWS. En esta sección, analizamos cada componente representado y sus defensas y vulnerabilidades ante ataques de microarquitectura.

KVM . La máquina virtual basada en el kernel de Linux (KVM) es el hipervisor implementado en los kernels de Linux modernos y, por lo tanto, forma parte del código base de Linux. Virtualiza los modos de supervisor y usuario del hardware subyacente, gestiona cambios de contexto entre máquinas virtuales y maneja la mayoría de los motivos de salida de máquinas virtuales, a menos que estén relacionados con operaciones de E/S. Además de estos mecanismos de aislamiento arquitectónico, KVM también implementa mitigaciones contra los ataques de Spectre en una salida de VM para proteger el sistema operativo host o el hipervisor de invitados maliciosos. Firecracker depende en gran medida de KVM como hipervisor. Sin embargo, dado que KVM es parte del código fuente de Linux y es desarrollado por la comunidad de Linux, definimos que KVM no sea parte de Firecracker. Por lo tanto, las contramedidas contra ataques de microarquitectura que se implementan en KVM no pueden atribuirse al sistema de contención de Firecracker.

Metadatos, dispositivos y servicios de E/S. Los metadatos, el dispositivo y los servicios de E/S son las partes de Firecracker VMM y API que interactúan directamente con una VM, recopilando y administrando métricas y proporcionando conectividad. AWS promociona la simplicidad de estas interfaces (para una superficie de ataque reducida) y que están escritas desde cero para Firecracker en Rust, un lenguaje de programación conocido por sus características de seguridad [9]. Sin embargo, Rust proporciona principalmente protección durante el proceso contra accesos a memoria no válidos y fuera de los límites, pero los ataques de microarquitectura como los ataques de caché, Spectre y MDS pueden filtrar información entre procesos en lugar de secuestrar directamente el proceso de una víctima.

Otra diferencia notable entre Firecracker y muchos otros VMM es que todos estos servicios se ejecutan dentro del mismo proceso de host que la propia VM, aunque en otro subproceso. Si bien la virtualización de direcciones de memoria dentro de la VM proporciona cierta confusión entre el código del huésped y los servicios de E/S, algunos ataques de Spectre funcionan específicamente dentro de un solo proceso. Sin embargo, los ataques intraproceso pueden representar una amenaza menor para los sistemas del mundo real, ya que dos invitados que se ejecutan en el mismo hardware tienen cada uno su propia copia de estos servicios esenciales.

Barrera de carcelero. En caso de que la API o VMM se vean comprometidos, el carcelero proporciona una última barrera de defensa alrededor de una instancia de Firecracker. Protege los archivos y recursos del sistema host con espacios de nombres y grupos de control (cgroups), respectivamente [7]. Los ataques a la microarquitectura no amenazan directamente los archivos, que por definición están fuera del estado de microarquitectura. Los Cgroups permiten a un administrador del sistema asignar procesos a grupos y luego asignar, restringir y monitorear el uso de recursos del sistema por grupo [17]. Es posible que las limitaciones aplicadas a los cgroups puedan impedir la capacidad de un atacante para llevar a cabo ciertos ataques de microarquitectura. Por ejemplo, las limitaciones de memoria podrían dificultar la realización de ataques de caché basados en desalojo, o las limitaciones de tiempo de CPU podrían impedir que un atacante haga un uso eficaz de una herramienta de denegación de servicio de CPU como HyperDegrade [2], que puede ralentizar a una víctima. proceso, simplificando el tiempo de una exfiltración o inyección de canal lateral microarquitectónico. En la práctica, Firecracker no se distribuye con ninguna regla de grupo particular [7]; de hecho, está diseñado específicamente para el funcionamiento eficiente de muchas máquinas virtuales Firecracker con la asignación de recursos predeterminada de Linux [6].

Ninguno de los sistemas de aislamiento y contención de Firecracker parece proteger directamente contra ataques de usuario a usuario o de usuario a host. Por lo tanto, procedimos a probar varias pruebas de conceptos de ataques de microarquitectura dentro y fuera de las máquinas virtuales Firecracker.