paint-brush
Sécurité microarchitecturale d'AWS Firecracker VMM : modèles de menacepar@autoencoder
379 lectures
379 lectures

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

Trop long; Pour lire

Ce document de recherche étudie à quel point Firecracker est sécurisé contre les attaques microarchitecturales.
featured image - Sécurité microarchitecturale d'AWS Firecracker VMM : modèles de menace
Auto Encoder: How to Ignore the Signal Noise HackerNoon profile picture
0-item

Auteurs:

(1) Zane Weissman, Worcester Polytechnic Institute Worcester, MA, États-Unis {[email protected]} ;

(2) Thomas Eisenbarth, Université de Lübeck Lübeck, SH, Allemagne {[email protected]} ;

(3) Thore Tiemann, Université de Lübeck Lübeck, SH, Allemagne {[email protected]} ;

(4) Berk Sunar, Institut polytechnique de Worcester Worcester, MA, États-Unis {[email protected]}.

Tableau des liens

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 disponible sur arxiv sous licence CC BY-NC-ND 4.0 DEED.