Auteurs:  (1) Zane Weissman, Worcester Polytechnic Institute Worcester, MA, États-Unis {zweissman@wpi.edu} ;  (2) Thomas Eisenbarth, Université de Lübeck Lübeck, SH, Allemagne {thomas.eisenbarth@uni-luebeck.de} ;  (3) Thore Tiemann, Université de Lübeck Lübeck, SH, Allemagne {t.tiemann@uni-luebeck.de} ;  (4) Berk Sunar, Institut polytechnique de Worcester Worcester, MA, États-Unis {sunar@wpi.edu}.  Tableau des liens   Résumé et introduction   Arrière-plan   Modèles de menaces   Analyse des systèmes de confinement des pétards   Analyse des attaques microarchitecturales et des défenses dans les microvms pétards   Conclusion, remerciements et références  3. MODÈLES DE MENACE  Nous proposons deux modèles de menaces applicables aux systèmes cloud sans serveur basés sur Firecracker :  (1) Le modèle d'utilisateur à utilisateur (Figure 3) : un utilisateur malveillant exécute du code arbitraire en bac à sable dans une machine virtuelle Firecracker et tente de divulguer des données, d'injecter des données ou d'obtenir de toute autre manière des informations sur l'application en bac à sable d'un autre utilisateur ou de contrôler celle-ci. Dans ce modèle, nous considérons  (a) le partage temporel du matériel, où les instances des deux utilisateurs s'exécutent à tour de rôle sur le cœur du processeur, et  (b) la colocalisation physique, où le code des deux utilisateurs s'exécute simultanément sur du matériel partagé d'une manière ou d'une autre (par exemple, deux cœurs sur le même processeur ou deux threads dans le même cœur si SMT est activé).  (2) Le modèle utilisateur-hôte (Figure 4) : un utilisateur malveillant cible un composant du système hôte : le Firecracker VMM, le KVM ou une autre partie du noyau du système hôte. Pour ce scénario, nous considérons uniquement le partage temporel des ressources matérielles. En effet, l'hôte n'exécute le code que si la VM de l'utilisateur invité se ferme, par exemple en raison d'une erreur de page qui doit être gérée par le noyau hôte ou le VMM.  Pour les deux modèles, nous supposons qu’un utilisateur malveillant est capable de contrôler l’environnement d’exécution de son application. Dans nos modèles, les utilisateurs malveillants ne possèdent pas les privilèges du noyau invité. Par conséquent, les deux modèles accordent à l'attaquant légèrement moins de privilèges que le modèle supposé par [1] où le noyau invité est choisi et configuré par le VMM mais supposé être compromis au moment de l'exécution. Les capacités de l'attaquant dans nos modèles correspondent plutôt aux capacités accordées aux utilisateurs dans les déploiements de Firecracker dans AWS Lambda et Fargate.  Cet article est   sous licence CC BY-NC-ND 4.0 DEED. disponible sur 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

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Boost your HackerNoon story @ $159.99! 🚀

Sécurité microarchitecturale d'AWS Firecracker VMM : modèles de menace

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Comment améliorer votre flux de travail par 10 : 17 applications essentielles

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Comment améliorer votre flux de travail par 10 : 17 applications essentielles

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps