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

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.