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  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.     . 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. KVM    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. Services de métadonnées, d’appareils et d’E/S.  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.    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]. Barrière de geôlier.  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.  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 : analyse des systèmes de confinement de Firecracker

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Appuyez pour gagner : Telegram pourrait intégrer les 10 prochains milliards d'utilisateurs de crypto avant Solana

Télégramme : le pont de Crypto Island vers le continent

Le guide complet pour réussir une migration vers le cloud : stratégies et bonnes pratiques

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

Appuyez pour gagner : Telegram pourrait intégrer les 10 prochains milliards d'utilisateurs de crypto avant Solana

Télégramme : le pont de Crypto Island vers le continent

Le guide complet pour réussir une migration vers le cloud : stratégies et bonnes pratiques

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps