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  3. MODELOS DE AMENAZA  Proponemos dos modelos de amenazas aplicables a los sistemas de nube sin servidor basados en Firecracker:  (1) El modelo de usuario a usuario (Figura 3): un usuario malintencionado ejecuta código arbitrario en un espacio aislado dentro de una VM Firecracker e intenta filtrar datos, inyectar datos u obtener información o control sobre la aplicación en un espacio aislado de otro usuario. En este modelo consideramos  (a) el intercambio de hardware en intervalos de tiempo, donde las instancias de los dos usuarios se ejecutan por turnos en el núcleo de la CPU, y  (b) coubicación física, donde el código de dos usuarios se ejecuta simultáneamente en hardware que se comparte de una forma u otra (por ejemplo, dos núcleos en la misma CPU o dos subprocesos en el mismo núcleo si SMT está habilitado).  (2) El modelo de usuario a host (Figura 4): un usuario malintencionado se dirige a algún componente del sistema host: Firecracker VMM, KVM u otra parte del núcleo del sistema host. Para este escenario, solo consideramos el uso compartido de recursos de hardware en intervalos de tiempo. Esto se debe a que el host sólo ejecuta código si la VM del usuario invitado sale, por ejemplo, debido a un error de página que debe ser manejado por el kernel del host o VMM.  Para ambos modelos, asumimos que un usuario malintencionado puede controlar el entorno de ejecución de su aplicación. En nuestros modelos, los usuarios malintencionados no poseen privilegios de kernel invitado. Por lo tanto, ambos modelos otorgan al atacante privilegios ligeramente menores que el modelo asumido por [1] donde el VMM elige y configura el kernel invitado pero se supone que está comprometido en tiempo de ejecución. Más bien, las capacidades del atacante en nuestros modelos coinciden con las capacidades otorgadas a los usuarios en las implementaciones de Firecracker en AWS Lambda y Fargate.  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: modelos de amenazas

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

El modelo Bitcoin UTXO, impulsando un ecosistema único

Telegram: el puente de Crypto Island hacia el continente

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

El modelo Bitcoin UTXO, impulsando un ecosistema único

Telegram: el puente de Crypto Island hacia el continente

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps