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  ABSTRAIT  Firecracker est un gestionnaire de machines virtuelles (VMM) spécialement conçu par Amazon Web Services (AWS) pour les plates-formes cloud sans serveur : des services qui exécutent du code pour les utilisateurs finaux tâche par tâche, gérant automatiquement l'infrastructure du serveur. Firecracker fournit des machines virtuelles rapides et légères et promet une combinaison de la vitesse des conteneurs, généralement utilisés pour isoler de petites tâches, et de la sécurité des machines virtuelles, qui tendent à fournir une plus grande isolation au détriment des performances. Selon AWS, cette combinaison de sécurité et d'efficacité permet non seulement d'exécuter des milliers de tâches utilisateur provenant de différents utilisateurs sur le même matériel, mais également en toute sécurité, le système hôte basculant rapidement et fréquemment entre les tâches actives. Même si AWS déclare que les attaques microarchitecturales sont incluses dans leur modèle de menace, cette classe d'attaques repose directement sur du matériel partagé, tout comme l'évolutivité de l'informatique sans serveur repose sur le partage de matériel entre un nombre sans précédent d'utilisateurs.  Dans ce travail, nous étudions à quel point Firecracker est sécurisé contre les attaques microarchitecturales. Tout d'abord, nous examinons le modèle d'isolation déclaré par Firecracker et les meilleures pratiques de déploiement recommandées, identifions les modèles de menaces potentiels pour les plates-formes sans serveur et analysons les points faibles potentiels. Ensuite, nous utilisons des preuves de concept d'attaque microarchitecturale pour tester l'isolation fournie par Firecracker et constatons qu'elle offre peu de protection contre les attaques Spectre ou MDS. Nous découvrons deux cas particulièrement préoccupants : 1) une variante Medusa qui menace les machines virtuelles Firecracker mais pas les processus exécutés en dehors d'elles, et n'est pas atténuée par les défenses recommandées par AWS, et 2) une variante Spectre-PHT qui reste exploitable même si les contre-mesures recommandées sont en place. place et SMT est désactivé dans le système. En résumé, nous montrons qu'AWS surestime la sécurité inhérente au Firecracker VMM et fournit des conseils incomplets pour sécuriser correctement les systèmes cloud qui utilisent Firecracker.   CONCEPTS CSC   • Sécurité et confidentialité → Virtualisation et sécurité ; Analyse des canaux secondaires et contre-mesures.   MOTS CLÉS  sécurité du système, sécurité microarchitecturale, machines virtuelles, hyperviseur, sans serveur, systèmes cloud  1. INTRODUCTION  L'informatique sans serveur est une tendance émergente dans le cloud computing où les fournisseurs de services cloud (CSP) proposent des environnements d'exécution à leurs clients. De cette façon, les clients peuvent se concentrer sur la maintenance de leur code de fonction tout en laissant le travail administratif lié au matériel, au système d'exploitation (OS) et parfois au runtime aux CSP. Les modèles courants de plate-forme sans serveur incluent la fonction en tant que service (FaaS) et le conteneur en tant que service (CaaS). Étant donné que les fonctions individuelles sont généralement petites, mais que les applications des clients peuvent chacune exécuter entre une et des milliers de fonctions, les CSP visent à installer autant de fonctions que possible sur un seul serveur afin de minimiser les temps d'inactivité et, par conséquent, de maximiser les profits. Une approche plutôt légère pour servir les environnements d'exécution consiste à exécuter des conteneurs, qui encapsulent un processus avec ses dépendances afin que seuls les fichiers nécessaires à chaque processus soient chargés dans des systèmes de fichiers virtuels au-dessus d'un noyau partagé. Cela réduit un basculement entre conteneurs à un peu plus qu’un changement de contexte entre processus. En revanche, la virtualisation complète assure une bonne isolation entre machines virtuelles (VM) et donc une sécurité entre locataires, tout en étant plutôt lourde puisque chaque VM est livrée avec son propre noyau.  Aucune de ces approches, conteneur ou VM, n'est idéale pour une utilisation dans des environnements sans serveur, où idéalement de nombreuses fonctions éphémères appartenant à de nombreux utilisateurs s'exécuteront simultanément et basculeront souvent. De nouveaux mécanismes d'isolation ont donc été développés pour ce cas d'utilisation. Par exemple, les mécanismes d'isolation en cours de processus [38, 45, 49] visent à améliorer la sécurité des conteneurs en réduisant la surface d'attaque du moteur d'exécution et du noyau sous-jacent. La protection du noyau est importante, car un noyau compromis conduit directement à un système entièrement compromis dans le boîtier du conteneur. Cependant, certaines protections puissantes, comme la limitation des appels système, limitent également les fonctionnalités disponibles pour le conteneur et interrompent même la compatibilité avec certaines applications. Dans le cadre de la recherche sur les VM, les développeurs ont créé des VM toujours plus petites et plus efficaces, pour finalement aboutir à ce que l'on appelle les microVM. Les MicroVM offrent les mêmes garanties d'isolation que les machines virtuelles habituelles, mais sont très limitées dans leurs capacités en termes de prise en charge des appareils ou des systèmes d'exploitation, ce qui les rend plus légères par rapport aux machines virtuelles habituelles et donc mieux adaptées à l'informatique sans serveur.  Firecracker [1] est un gestionnaire de machines virtuelles (VMM) conçu pour exécuter des microVM tout en fournissant une surcharge de mémoire et des temps de démarrage comparables à ceux des systèmes de conteneurs courants. Firecracker est activement développé par Amazon Web Services (AWS) et est utilisé en production pour les services de calcul sans serveur AWS Lambda [5] et AWS Fargate [4] depuis 2018 [1]. Le document de conception d'AWS [1] décrit les fonctionnalités de Firecracker, en quoi il s'écarte des machines virtuelles plus traditionnelles et le modèle d'isolation prévu qu'il fournit : sécurité pour « plusieurs fonctions exécutées sur le même matériel, protégées contre l'élévation de privilèges, les informations » divulgation, canaux secrets et autres risques »[1]. De plus, AWS fournit des recommandations de configuration d'hôte de production [8] pour sécuriser les parties du processeur et du noyau avec lesquelles une VM Firecracker interagit. Dans cet article, nous contestons l’affirmation selon laquelle Firecracker protège les fonctions des canaux secrets et secondaires sur les microVM. Nous montrons que Firecracker lui-même n’ajoute rien aux contre-mesures contre les attaques microarchitecturales mais s’appuie entièrement sur les noyaux Linux hôtes et invités et sur les mises à jour du micrologiciel/microcode du processeur.  Les attaques microarchitecturales telles que les différentes variantes de Spectre [10, 13, 22, 30, 31, 33, 52] et d'échantillonnage de données microarchitecturales (MDS) [14, 37, 46, 50] constituent une menace pour les systèmes multi-locataires car elles sont souvent capable de contourner les limites d'isolation logicielle et architecturale, y compris celles des machines virtuelles. Spectre et MDS menacent les locataires qui partagent les ressources de base du processeur, comme l'unité de prédiction de branche (BPU) ou le tampon de remplissage de ligne (LFB). Les CSP fournissant des services plus traditionnels peuvent atténuer le problème des ressources matérielles partagées en épinglant les locataires de VM de longue durée sur des cœurs de processeur séparés, ce qui divise efficacement les ressources entre les locataires et garantit que l'état microarchitectural n'est affecté que par un seul locataire à la fois. .  Toutefois, dans les environnements sans serveur, la menace d’attaques microarchitecturales est plus grande. La raison en est la courte durée des fonctions assurées par les différents locataires. Les ressources serveur dans les environnements sans serveur devraient être surchargées, ce qui conduit les fonctions locataires à se disputer les ressources de calcul sur le même matériel. La désactivation du multithreading simultané (SMT), qui désactiverait l'utilisation simultanée des ressources du processeur par deux threads frères, réduit la puissance de calcul d'un processeur jusqu'à 30 % [34]. Si les clients louent des cœurs de processeur spécifiques, cette pénalité de performances peut être acceptable, ou les deux threads d'un cœur de processeur peuvent être loués ensemble. Mais pour les services sans serveur, la dégradation des performances se traduit directement par 30 % de clients en moins pouvant être servis dans un laps de temps donné. C'est pourquoi il faut supposer que la plupart des CSP sans serveur maintiennent SMT activé dans leurs systèmes, sauf indication contraire. La surface d'attaque microarchitecturale est la plus grande si SMT est activé et que le thread malveillant dispose d'un accès simultané à un cœur partagé. Mais il existe également des variantes d'attaque qui fonctionnent tout aussi bien si le thread attaquant prépare la microarchitecture avant de céder le cœur du processeur au thread victime ou s'exécute juste après que le thread victime ait suspendu son exécution. Et même si SMT est désactivé par le CSP (comme c'est le cas pour AWS Lambda), les locataires partagent toujours les processeurs avec plusieurs autres de cette manière découpée dans le temps.  AWS affirme que Firecracker fonctionnant sur un système doté de défenses microarchitecturales à jour fournira un renforcement suffisant contre les attaques microarchitecturales [1]. La documentation Firecracker contient également des recommandations spécifiques sur les mesures de sécurité microarchitecturales qui doivent être activées. Dans ce travail, nous examinons les affirmations et recommandations de sécurité de Firecracker et révélons des oublis dans ses directives ainsi que des menaces totalement non atténuées.  En résumé, nos principales contributions sont :  • Nous fournissons une analyse de sécurité complète de l'isolation entre locataires et hyperviseur du calcul sans serveur lorsqu'il est basé sur la VM Firecracker.  • Nous testons les capacités de défense de Firecracker contre les preuves de concept (PoC) d'attaques microarchitecturales, en utilisant les protections disponibles via les mises à jour du microcode et le noyau Linux. Nous montrons que la machine virtuelle elle-même offre une protection négligeable contre les principales classes d'attaques microarchitecturales.  • Nous identifions une variante de l'attaque Medusa MDS qui devient exploitable depuis les machines virtuelles Firecracker même si elle n'est pas présente sur l'hôte. L'atténuation du noyau qui protège contre cet exploit, ainsi que les variantes les plus connues de Medusa, n'est pas mentionnée dans les recommandations de configuration de l'hôte Firecracker d'AWS. De plus, nous montrons que la désactivation de SMT offre une protection insuffisante contre la variante Medusa identifiée, ce qui nécessite une atténuation du noyau.  • Nous identifions les variantes Spectre-PHT et Spectre-BTB qui fuient des données même avec les contre-mesures recommandées en place. Les variantes Spectre-PHT restent même un problème lorsque SMT est désactivé si l'attaquant et la victime partagent un cœur de processeur de manière découpée dans le temps.  1.1 Divulgation responsable  Nous avons informé l'équipe de sécurité AWS de nos découvertes et discuté des détails techniques. L'équipe de sécurité AWS affirme que les services AWS ne sont pas affectés par nos conclusions en raison de mesures de sécurité supplémentaires. AWS a convenu que Firecracker ne fournit pas de sécurité micro-architecturale à lui seul, mais uniquement en combinaison avec des mises à jour de microcode et des systèmes d'exploitation hôtes et invités sécurisés, et prévoit de mettre à jour ses recommandations de configuration d'hôte pour les installations 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 : résumé et introduction

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Croissance des crypto-monnaies : créer des profils d'utilisateurs efficaces

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

Valhalla de Floki se joint en tant que sponsor associé de la tournée indienne au Sri Lanka

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

Croissance des crypto-monnaies : créer des profils d'utilisateurs efficaces

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

Valhalla de Floki se joint en tant que sponsor associé de la tournée indienne au Sri Lanka

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

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps