Sécurité microarchitecturale d'AWS Firecracker VMM : analyse des systèmes de confinement de Firecracker

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

4. ANALYSE DES SYSTÈMES DE CONFINEMENT DES PÉTARDS

La figure 2 montre le confinement offert par Firecracker, tel que présenté par AWS. Dans cette section, nous analysons chaque composant représenté ainsi que leurs défenses et vulnérabilités aux attaques microarchitecturales.

KVM . La machine virtuelle basée sur le noyau Linux (KVM) est l'hyperviseur implémenté dans les noyaux Linux modernes et fait donc partie de la base de code Linux. Il virtualise les modes superviseur et utilisateur du matériel sous-jacent, gère les changements de contexte entre les machines virtuelles et gère la plupart des raisons de sortie de machine virtuelle, sauf si elles sont liées aux opérations d'E/S. Outre ces mécanismes d'isolation architecturale, KVM met également en œuvre des mesures d'atténuation contre les attaques Spectre sur une sortie de VM afin de protéger le système d'exploitation hôte ou l'hyperviseur des invités malveillants. Firecracker s'appuie fortement sur KVM comme hyperviseur. Cependant, comme KVM fait partie du code source Linux et est développé par la communauté Linux, nous définissons KVM comme ne faisant pas partie de Firecracker. Par conséquent, les contre-mesures contre les attaques microarchitecturales mises en œuvre dans KVM ne peuvent pas être attribuées au système de confinement de Firecracker.

Services de métadonnées, d’appareils et d’E/S. Les services de métadonnées, de périphériques et d'E/S sont les parties du VMM et de l'API Firecracker qui interagissent directement avec une VM, collectant et gérant les métriques et fournissant la connectivité. AWS vante la simplicité de ces interfaces (pour une surface d'attaque réduite) et qu'elles sont écrites de toutes pièces pour Firecracker dans Rust, un langage de programmation connu pour ses fonctionnalités de sécurité [9]. Cependant, Rust fournit notamment une protection en cours de processus contre les accès mémoire non valides et hors limites, mais les attaques microarchitecturales telles que les attaques de cache, Spectre et MDS peuvent divulguer des informations entre les processus plutôt que de détourner directement le processus d'une victime.

Une autre différence notable entre Firecracker et de nombreux autres VMM est que tous ces services sont exécutés au sein du même processus hôte que la VM elle-même, bien que dans un autre thread. Bien que la virtualisation des adresses mémoire au sein de la VM fournisse une certaine confusion entre le code de l'invité et les services d'E/S, certaines attaques Spectre fonctionnent spécifiquement au sein d'un seul processus. Les attaques intraprocessus peuvent toutefois constituer une menace moindre pour les systèmes du monde réel, puisque deux invités exécutés sur le même matériel disposent chacun de leur propre copie de ces services essentiels.

Barrière de geôlier. Dans le cas où l'API ou le VMM seraient compromis, le jailer fournit une dernière barrière de défense autour d'une instance Firecracker. Il protège les fichiers et les ressources du système hôte avec des espaces de noms et des groupes de contrôle (cgroups), respectivement [7]. Les attaques microarchitecturales ne menacent pas directement les fichiers, qui sont par définition en dehors de l’état microarchitectural. Les groupes de contrôle permettent à un administrateur système d'attribuer des processus à des groupes, puis d'allouer, de contraindre et de surveiller l'utilisation des ressources système par groupe [17]. Il est plausible que les limitations appliquées aux groupes de contrôle puissent entraver la capacité d'un attaquant à mener certaines attaques microarchitecturales. Par exemple, les limitations de mémoire pourraient rendre difficile la réalisation d'attaques de cache basées sur l'éviction, ou les limitations de temps CPU pourraient empêcher un attaquant d'utiliser efficacement un outil de déni de service CPU comme HyperDegrade [2] qui peut ralentir une victime. processus, simplifiant le timing d’une exfiltration ou d’une injection microarchitecturale de canal latéral. En pratique, Firecracker n'est distribué avec aucune règle de groupe de contrôle particulière [7] ; en fait, il est spécifiquement conçu pour le fonctionnement efficace de nombreuses machines virtuelles Firecracker sous l'allocation de ressources Linux par défaut [6].

Aucun des systèmes d'isolation et de confinement de Firecracker ne semble protéger directement contre les attaques d'utilisateur à utilisateur ou d'utilisateur à hôte. Par conséquent, nous avons procédé à des tests de diverses preuves de concepts d’attaques microarchitecturales à l’intérieur et à l’extérieur des machines virtuelles Firecracker.