Autores:  (1) Zane Weissman, Instituto Politécnico de Worcester, Worcester, MA, EE. UU. {zweissman@wpi.edu};  (2) Thomas Eisenbarth, Universidad de Lübeck Lübeck, SH, Alemania {thomas.eisenbarth@uni-luebeck.de};  (3) Thore Tiemann, Universidad de Lübeck Lübeck, SH, Alemania {t.tiemann@uni-luebeck.de};  (4) Berk Sunar, Instituto Politécnico de Worcester Worcester, MA, EE. UU. {sunar@wpi.edu}.  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  ABSTRACTO  Firecracker es un administrador de máquinas virtuales (VMM) creado específicamente por Amazon Web Services (AWS) para plataformas en la nube sin servidor: servicios que ejecutan código para los usuarios finales por tarea, administrando automáticamente la infraestructura del servidor. Firecracker proporciona máquinas virtuales rápidas y livianas y promete una combinación de la velocidad de los contenedores, generalmente utilizados para aislar tareas pequeñas, y la seguridad de las máquinas virtuales, que tienden a brindar un mayor aislamiento a costa del rendimiento. Esta combinación de seguridad y eficiencia, afirma AWS, hace que no sólo sea posible, sino también seguro, ejecutar miles de tareas de diferentes usuarios en el mismo hardware, con el sistema host cambiando rápida y frecuentemente entre tareas activas. Aunque AWS afirma que los ataques de microarquitectura están incluidos en su modelo de amenaza, esta clase de ataques depende directamente del hardware compartido, del mismo modo que la escalabilidad de la informática sin servidor depende de compartir hardware entre un número sin precedentes de usuarios.  En este trabajo, investigamos qué tan seguro es Firecracker contra ataques de microarquitectura. Primero, revisamos el modelo de aislamiento declarado de Firecracker y las mejores prácticas recomendadas para la implementación, identificamos modelos de amenazas potenciales para plataformas sin servidor y analizamos posibles puntos débiles. Luego, utilizamos pruebas de conceptos de ataques de microarquitectura para probar el aislamiento proporcionado por Firecracker y descubrimos que ofrece poca protección contra ataques Spectre o MDS. Descubrimos dos casos particularmente preocupantes: 1) una variante de Medusa que amenaza las máquinas virtuales Firecracker pero no los procesos que se ejecutan fuera de ellas, y no está mitigada por las defensas recomendadas por AWS, y 2) una variante Spectre-PHT que sigue siendo explotable incluso si se aplican las contramedidas recomendadas. lugar y SMT está deshabilitado en el sistema. En resumen, mostramos que AWS exagera la seguridad inherente a Firecracker VMM y proporciona una guía incompleta para proteger adecuadamente los sistemas en la nube que utilizan Firecracker.   CONCEPTOS DE CCS   • Seguridad y privacidad → Virtualización y seguridad; Análisis de canal lateral y contramedidas.   PALABRAS CLAVE  seguridad del sistema, seguridad microarquitectónica, máquinas virtuales, hipervisor, sin servidor, sistemas en la nube  1. INTRODUCCIÓN  La computación sin servidor es una tendencia emergente en la computación en la nube donde los proveedores de servicios en la nube (CSP) ofrecen entornos de ejecución a sus clientes. De esta manera, los clientes pueden concentrarse en mantener su código de función mientras dejan el trabajo administrativo relacionado con el hardware, el sistema operativo (SO) y, a veces, el tiempo de ejecución a los CSP. Los modelos comunes de plataformas sin servidor incluyen función como servicio (FaaS) y contenedor como servicio (CaaS). Dado que las funciones individuales suelen ser pequeñas, pero las aplicaciones de los clientes pueden ejecutar entre una y miles de funciones, los CSP apuntan a instalar tantas funciones en un solo servidor como sea posible para minimizar los tiempos de inactividad y, a su vez, maximizar las ganancias. Un enfoque bastante liviano para servir entornos de ejecución es ejecutar contenedores, que encapsulan un proceso con sus dependencias de modo que solo los archivos necesarios para cada proceso se cargan en sistemas de archivos virtuales en la parte superior de un núcleo compartido. Esto reduce un cambio entre contenedores a poco más que un cambio de contexto entre procesos. Por otro lado, la virtualización completa proporciona un buen aislamiento entre máquinas virtuales (VM) y, por lo tanto, seguridad entre inquilinos, aunque es bastante pesada ya que cada VM viene con su propio kernel.  Ninguno de estos enfoques, contenedor o VM, es ideal para su uso en entornos sin servidor, donde idealmente muchas funciones de corta duración propiedad de muchos usuarios se ejecutarán simultáneamente y cambiarán con frecuencia, por lo que se han desarrollado nuevos mecanismos de aislamiento para este caso de uso. Por ejemplo, los mecanismos para el aislamiento en proceso [38, 45, 49] se proponen mejorar la seguridad de los contenedores al reducir la superficie de ataque del tiempo de ejecución y del kernel subyacente. Proteger el kernel es importante, ya que un kernel comprometido conduce directamente a un sistema completamente comprometido en el caso del contenedor. Sin embargo, ciertas protecciones poderosas, como limitar las llamadas al sistema, también limitan la funcionalidad disponible para el contenedor e incluso rompen la compatibilidad con algunas aplicaciones. En la investigación de VM, los desarrolladores crearon VM cada vez más pequeñas y más eficientes, lo que finalmente condujo a las llamadas microVM. Las MicroVM ofrecen las mismas garantías de aislamiento que las máquinas virtuales habituales, pero tienen capacidades muy limitadas en lo que respecta a la compatibilidad con dispositivos o sistemas operativos, lo que las hace más livianas en comparación con las máquinas virtuales habituales y, por lo tanto, más adecuadas para la informática sin servidor.  Firecracker [1] es un administrador de máquinas virtuales (VMM) diseñado para ejecutar microVM mientras proporciona sobrecarga de memoria y tiempos de inicio comparables a los de los sistemas de contenedores comunes. Firecracker es desarrollado activamente por Amazon Web Services (AWS) y se ha utilizado en la producción de servicios informáticos sin servidor AWS Lambda [5] y AWS Fargate [4] desde 2018 [1]. El documento de diseño de AWS [1] describe las características de Firecracker, en qué se diferencia de las máquinas virtuales más tradicionales y el modelo de aislamiento previsto que proporciona: seguridad para “múltiples funciones que se ejecutan en el mismo hardware, protección contra escalada de privilegios, información divulgación, canales encubiertos y otros riesgos” [1]. Además, AWS proporciona recomendaciones de configuración del host de producción [8] para proteger partes de la CPU y el kernel con las que interactúa una VM Firecracker. En este artículo, cuestionamos la afirmación de que Firecracker protege funciones de canales laterales y encubiertos en microVM. Mostramos que Firecracker en sí no se suma a las contramedidas de ataque de microarquitectura, sino que depende completamente de los kernels de Linux host e invitado y de las actualizaciones de firmware/microcódigo de la CPU.  Los ataques de microarquitectura como las diversas variantes de Spectre [10, 13, 22, 30, 31, 33, 52] y muestreo de datos de microarquitectura (MDS) [14, 37, 46, 50] representan una amenaza para los sistemas multiinquilino, ya que a menudo son capaz de superar los límites de aislamiento arquitectónico y de software, incluidos los de las máquinas virtuales. Spectre y MDS amenazan a los inquilinos que comparten recursos centrales de la CPU, como la unidad de predicción de rama (BPU) o el búfer de llenado de línea (LFB). Los CSP que brindan servicios más tradicionales pueden mitigar el problema de los recursos de hardware compartidos al fijar los inquilinos de las máquinas virtuales de larga duración en núcleos de CPU separados, lo que divide efectivamente los recursos entre los inquilinos y garantiza que el estado de la microarquitectura solo lo efectúe un único inquilino a la vez. .  Sin embargo, en entornos sin servidor, la amenaza de ataques a la microarquitectura es mayor. La razón de esto es la corta duración de las funciones que desempeñan los distintos inquilinos. Se espera que los recursos del servidor en entornos sin servidor estén comprometidos en exceso, lo que lleva a que las funciones de los inquilinos compitan por los recursos informáticos en el mismo hardware. Deshabilitar el subproceso múltiple simultáneo (SMT), que deshabilitaría el uso simultáneo de recursos de la CPU por parte de dos subprocesos hermanos, reduce la potencia de cálculo de una CPU hasta en un 30% [34]. Si los clientes alquilan núcleos de CPU específicos, esta penalización en el rendimiento puede ser aceptable, o ambos subprocesos de un núcleo de CPU pueden alquilarse juntos. Pero para los servicios sin servidor, la penalización en el rendimiento se traduce directamente en un 30% menos de clientes que pueden ser atendidos en un período de tiempo determinado. Es por eso que se debe asumir que la mayoría de los CSP sin servidor mantienen SMT habilitado en sus sistemas a menos que indiquen lo contrario. La superficie de ataque de la microarquitectura es mayor si SMT está habilitado y el hilo malicioso tiene acceso simultáneo a un núcleo compartido. Pero también hay variantes de ataque que funcionan igual de bien si el subproceso atacante prepara la microarquitectura antes de ceder el núcleo de la CPU al subproceso víctima o se ejecuta justo después de que el subproceso víctima haya pausado la ejecución. E incluso si el CSP deshabilita SMT (como es el caso de AWS Lambda), los inquilinos aún comparten CPU con muchos otros en esta forma de intervalos de tiempo.  AWS afirma que Firecracker que se ejecuta en un sistema con defensas de microarquitectura actualizadas proporcionará suficiente protección contra ataques de microarquitectura [1]. La documentación de Firecracker también contiene recomendaciones específicas para medidas de seguridad de microarquitectura que deben habilitarse. En este trabajo, examinamos las afirmaciones y recomendaciones de seguridad de Firecracker y revelamos descuidos en sus directrices, así como amenazas totalmente no mitigadas.  En resumen, nuestras principales aportaciones son:  • Proporcionamos un análisis de seguridad integral del aislamiento entre inquilinos y inquilino-hipervisor de la computación sin servidor cuando se basa en Firecracker VM.  • Probamos las capacidades de defensa de Firecracker contra pruebas de concepto (PoC) de ataques de microarquitectura, empleando protecciones disponibles a través de actualizaciones de microcódigo y el kernel de Linux. Mostramos que la máquina virtual en sí proporciona una protección insignificante contra las principales clases de ataques de microarquitectura.  • Identificamos una variante del ataque Medusa MDS que se vuelve explotable desde las máquinas virtuales Firecracker aunque no esté presente en el host. La mitigación del kernel que protege contra este exploit y la mayoría de las variantes conocidas de Medusa no se menciona en las recomendaciones de configuración del host Firecracker de AWS. Además, mostramos que deshabilitar SMT proporciona una protección insuficiente contra la variante Medusa identificada, lo que impulsa la necesidad de mitigación del kernel.  • Identificamos variantes de Spectre-PHT y Spectre-BTB que filtran datos incluso con las contramedidas recomendadas implementadas. Las variantes de Spectre-PHT incluso siguen siendo un problema cuando SMT está deshabilitado si el atacante y la víctima comparten un núcleo de CPU en un intervalo de tiempo.  1.1 Divulgación responsable  Informamos al equipo de seguridad de AWS sobre nuestros hallazgos y discutimos los detalles técnicos. El equipo de seguridad de AWS afirma que los servicios de AWS no se ven afectados por nuestros hallazgos debido a medidas de seguridad adicionales. AWS acordó que Firecracker no proporciona seguridad de microarquitectura por sí solo, sino solo en combinación con actualizaciones de microcódigo y sistemas operativos host e invitados seguros, y planea actualizar sus recomendaciones de configuración de host para las instalaciones de Firecracker.  Este documento está   bajo licencia CC BY-NC-ND 4.0 DEED. disponible en arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

AutoEncoder.tech

Research & publications on Auto Encoders, revolutionizing data compression and feature learning techniques.

Auto Encoder's blog

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Boost your HackerNoon story @ $159.99! 🚀

Seguridad microarquitectónica de AWS Firecracker VMM: resumen e introducción

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps