paint-brush
Seguridad microarquitectónica de AWS Firecracker VMM: análisis de los sistemas de contención de Firecrackerpor@autoencoder
463 lecturas
463 lecturas

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

Demasiado Largo; Para Leer

Este artículo de investigación investiga qué tan seguro es Firecracker contra ataques de microarquitectura.
featured image - Seguridad microarquitectónica de AWS Firecracker VMM: análisis de los sistemas de contención de Firecracker
Auto Encoder: How to Ignore the Signal Noise HackerNoon profile picture
0-item

Autores:

(1) Zane Weissman, Instituto Politécnico de Worcester, Worcester, MA, EE. UU. {[email protected]};

(2) Thomas Eisenbarth, Universidad de Lübeck Lübeck, SH, Alemania {[email protected]};

(3) Thore Tiemann, Universidad de Lübeck Lübeck, SH, Alemania {[email protected]};

(4) Berk Sunar, Instituto Politécnico de Worcester Worcester, MA, EE. UU. {[email protected]}.

Tabla de enlaces

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.


Figura 3: En el modelo de amenaza de usuario a usuario, asumimos que un inquilino de servicio en la nube malicioso intenta filtrar información de otro inquilino. Asumimos que el atacante tiene control sobre la aplicación y el tiempo de ejecución de su VM mientras el CSP proporciona el kernel invitado.


Figura 4: En el modelo de amenaza de usuario a host, el inquilino malicioso busca filtrar información desde el sistema host, e. gramo. el administrador de la máquina virtual o el kernel del host. El atacante tiene control sobre el tiempo de ejecución y la aplicación en su máquina virtual, mientras que el CSP proporciona el kernel invitado.


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.


Este documento está disponible en arxiv bajo licencia CC BY-NC-ND 4.0 DEED.