Sécurité microarchitecturale d'AWS Firecracker VMM : contexte

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 et des défenses microarchitecturales dans les microvms pétards
• Conclusion, remerciements et références

2. ARRIÈRE PLAN

2.1 KVM

La machine virtuelle basée sur le noyau Linux (KVM) [29] fournit une abstraction des fonctionnalités de virtualisation assistée par matériel comme Intel VT-x ou AMD-V qui sont disponibles dans les processeurs modernes. Pour prendre en charge une exécution quasi native, un mode invité est ajouté au noyau Linux en plus du mode noyau et du mode utilisateur existants. En mode invité Linux, KVM fait entrer le matériel dans le mode de virtualisation matérielle qui réplique les privilèges de l'anneau 0 et de l'anneau 3.[1]

Avec KVM, la virtualisation des E/S est effectuée principalement dans l'espace utilisateur par le processus qui a créé la VM, appelé VMM ou hyperviseur, contrairement aux hyperviseurs antérieurs qui nécessitaient généralement un processus d'hyperviseur distinct [41]. Un hyperviseur KVM fournit à chaque invité VM sa propre région de mémoire distincte de la région de mémoire du processus qui a créé l'invité. Cela est vrai pour les invités créés à partir de l'espace noyau ainsi que de l'espace utilisateur. Chaque machine virtuelle est mappée à un processus sur l'hôte Linux et chaque processeur virtuel attribué à l'invité est un thread dans ce processus hôte. Le processus d'hyperviseur de l'espace utilisateur de la VM effectue des appels système vers KVM uniquement lorsqu'une exécution privilégiée est requise, minimisant ainsi le changement de contexte et réduisant la VM à la surface d'attaque du noyau. En plus d'améliorer les performances de toutes sortes d'applications, cette conception a permis le développement d'hyperviseurs légers qui sont particulièrement utiles pour le sandboxing de programmes individuels et la prise en charge d'environnements cloud dans lesquels de nombreuses machines virtuelles s'exécutent en même temps.

2.2 Cloud computing sans serveur

Un modèle de plus en plus populaire pour le cloud computing est l'informatique sans serveur, dans lequel le CSP gère l'évolutivité et la disponibilité des serveurs qui exécutent le code de l'utilisateur. Une implémentation de l'informatique sans serveur est appelée fonction en tant que service (FaaS). Dans ce modèle, un utilisateur du cloud définit des fonctions qui sont appelées si nécessaire via l'interface de programmation d'application (API) du fournisseur de services (d'où le nom « function-as-a-service ») et le CSP gère l'allocation des ressources sur le serveur qui exécute le fonction de l'utilisateur (d'où le nom « informatique sans serveur » : l'utilisateur ne gère pas le serveur). De même, l’informatique conteneur en tant que service (CaaS) exécute des conteneurs, des packages d’exécution portables, à la demande. La gestion centralisée des serveurs de FaaS et CaaS est économiquement intéressante tant pour les CSP que pour les utilisateurs. Le CSP peut gérer les charges de travail de ses utilisateurs comme bon lui semble, les optimiser pour minimiser les coûts d'exploitation et mettre en œuvre une tarification flexible où les utilisateurs paient pour le temps d'exécution qu'ils utilisent. L'utilisateur n'a pas à se soucier de la conception ou de la gestion de l'infrastructure du serveur, ce qui réduit les coûts de développement et externalise les coûts de maintenance vers le CSP à un rythme relativement faible et prévisible.

2.3 MicroVM et AWS Firecracker

Les fournisseurs FaaS et CaaS utilisent divers systèmes pour gérer les fonctions et les conteneurs en cours d'exécution. Les systèmes de conteneurs tels que Docker, Podman et LXD offrent un moyen pratique et léger de packager et d'exécuter des applications en bac à sable dans n'importe quel environnement. Cependant, comparés aux machines virtuelles utilisées pour de nombreuses formes plus traditionnelles de cloud computing, les conteneurs offrent moins d'isolation et donc moins de sécurité. Ces dernières années, les principaux CSP ont introduit des microVM qui soutiennent les conteneurs traditionnels avec une virtualisation légère pour une sécurité supplémentaire. [1, 55] L'efficacité de la virtualisation matérielle avec KVM et la conception légère des microVM signifient que le code dans les systèmes virtualisés, conteneurisés ou de type conteneur peut s'exécuter presque aussi rapidement que le code non virtualisé et avec une surcharge comparable à celle d'un conteneur traditionnel.

Firecracker [1] est une microVM développée par AWS pour isoler chacune des charges de travail AWS Lambda FaaS et AWS Fargate CaaS dans une VM distincte. Il prend uniquement en charge les invités Linux sur les hôtes x86 ou ARM Linux-KVM et fournit un nombre limité de périphériques disponibles pour les systèmes invités. Ces limitations permettent à Firecracker d'être très léger en termes de taille de base de code et de surcharge de mémoire pour une VM en cours d'exécution, ainsi que d'être très rapide à démarrer ou à arrêter. De plus, l'utilisation de KVM allège les exigences de Firecracker, puisque certaines fonctions de virtualisation sont gérées par les appels système du noyau et que le système d'exploitation hôte gère les machines virtuelles comme des processus standard. En raison de sa petite base de code écrite en Rust, Firecracker est considéré comme très sécurisé, même si des failles de sécurité ont été identifiées dans des versions antérieures (voir CVE-2019-18960). Il est intéressant de noter que le livre blanc Firecracker déclare que les attaques microarchitecturales entrent dans le champ d'application de son modèle d'attaquant [1] mais manque d'une analyse de sécurité détaillée ou de contre-mesures spéciales contre les attaques microarchitecturales au-delà des recommandations courantes de configuration de système sécurisé pour le noyau invité et hôte. La documentation de Firecracker fournit des recommandations de sécurité du système [8] qui incluent une liste spécifique de contre-mesures, que nous abordons dans la section 2.6.1.

2.4 Fusion et MDS

En 2018, l’attaque Meltdown [32] a montré que les données accessibles de manière spéculative pouvaient être exfiltrées au-delà des frontières de sécurité en les codant dans un canal latéral de cache. Cela a rapidement conduit à toute une classe d'attaques similaires, connues sous le nom d'échantillonnage de données microarchitecturales (MDS), notamment Fallout [14], Rogue In-flight Data Load (RIDL) [50], TSX Asynchronous Abort (TAA) [50] et Chargement de zombies [46]. Ces attaques suivent toutes le même schéma général pour exploiter l’exécution spéculative :

(1) La victime exécute un programme qui gère des données secrètes et les données secrètes transitent par un cache ou un tampon CPU.

(2) L'attaquant exécute une instruction spécifiquement choisie qui amènera le processeur à prédire par erreur que les données secrètes seront nécessaires. Le CPU transmet les données secrètes à l'instruction de l'attaquant.

(3) Les données secrètes transmises sont utilisées comme index d'une mémoire lue dans un tableau auquel l'attaquant est autorisé à accéder, provoquant la mise en cache d'une ligne particulière de ce tableau.

(4) Le processeur termine la vérification des données et décide que les données secrètes ont été transmises de manière incorrecte et rétablit l'état d'exécution tel qu'il était avant leur transfert, mais l'état du cache n'est pas rétabli. (5) L'attaquant sonde l'ensemble du tableau pour voir quelle ligne a été mise en cache ; l'index de cette ligne est la valeur des données secrètes.

La vulnérabilité Meltdown d'origine ciblait le transfert de cache et permettait l'extraction de données de cette manière à partir de n'importe quelle adresse mémoire présente dans le cache. Les attaques MDS ciblent des tampons plus petits et plus spécifiques dans la microarchitecture centrale et constituent ainsi une classe d'attaques connexe mais distincte qui sont atténuées de manière significativement différente. Alors que Meltdown cible la mémoire principale qui est mise à jour relativement rarement et partagée entre tous les cœurs, threads et processus, les attaques MDS ont tendance à cibler les tampons locaux aux cœurs (bien que parfois partagés entre les threads) et mis à jour plus fréquemment pendant l'exécution.

2.4.1 Variantes MDS de base . La figure 1 présente les principales voies d'attaque MDS connues sur les processeurs Intel et les noms donnés aux différentes variantes par Intel et par les chercheurs qui les ont signalés. De manière plus générale, Intel classe les vulnérabilités MDS de ses processeurs en fonction du tampon spécifique à partir duquel les données sont transmises de manière spéculative, car ces tampons ont tendance à être utilisés pour un certain nombre d'opérations différentes. Les vulnérabilités RIDL MDS peuvent être classées en deux catégories : Microarchitectural Load Port Data Sampling (MLPDS), pour les variantes qui fuient du port de chargement du processeur, et Microarchitectural Fill Buffer Data Sampling (MFBDS), pour les variantes qui fuient du LFB du CPU. Dans le même esprit, Intel appelle la vulnérabilité Fallout Microarchitectural Store Buffer Data Sampling (MSBDS), car elle implique une fuite du tampon de magasin. Vector Register Sampling (VRS) est une variante de MSBDS qui cible les données traitées par des opérations vectorielles lors de leur passage dans le tampon de stockage. Le contournement VERW exploite un bug dans le

correctifs de microcode pour MFBDS qui chargent des données obsolètes et potentiellement secrètes dans le LFB. Le mécanisme de base de la fuite est le même et le contournement VERW peut être considéré comme un cas particulier de MFBDS. L1 Data Eviction Sampling (L1DES) est un autre cas particulier de MFBDS, dans lequel les données expulsées du cache de données L1 passent par le LFB et deviennent vulnérables à une attaque MDS. Notamment, L1DES est un cas où l'attaquant peut réellement déclencher la présence des données secrètes dans le CPU (en les expulsant), alors que d'autres attaques MDS s'appuient directement sur l'accès du processus victime aux données secrètes pour les amener dans le bon tampon du CPU.

2.4.2 Méduse. Medusa [37] est une catégorie d'attaques MDS classées par Intel comme variantes MLPDS [25]. Les vulnérabilités Medusa exploitent les algorithmes imparfaits de correspondance de modèles utilisés pour combiner de manière spéculative les magasins dans le tampon d'écriture-combine (WC) des processeurs Intel. Intel considère que le tampon WC fait partie du port de chargement, Intel classe donc cette vulnérabilité comme un cas de MLPDS. Il existe trois variantes connues de Medusa qui exploitent chacune une fonctionnalité différente du tampon de combinaison d'écriture pour provoquer une fuite spéculative :

Indexation du cache : une charge défaillante est combinée de manière spéculative avec une charge antérieure avec un décalage de ligne de cache correspondant.

Transfert de stockage à chargement non aligné : un stockage valide suivi d'une charge dépendante qui déclenche une erreur de mémoire mal alignée entraîne le transfert de données aléatoires du WC.

Shadow REP MOV : une instruction REP MOV défaillante suivie d'une charge dépendante fait fuir les données d'un REP MOV différent.

2.4.3 Abandon asynchrone du TSX. La vulnérabilité matérielle TSX Asynchronous Abort (TAA) [24] fournit un mécanisme de spéculation différent pour mener une attaque MDS. Alors que les attaques MDS standard accèdent à des données restreintes avec une exécution spéculée standard, TAA utilise une transaction de mémoire atomique telle qu'implémentée par TSX. Lorsqu'une transaction de mémoire atomique rencontre un abandon asynchrone, par exemple parce qu'un autre processus lit une ligne de cache marquée pour être utilisée par la transaction ou parce que la transaction rencontre une erreur, toutes les opérations de la transaction sont ramenées à l'état architectural avant le démarrage de la transaction. Cependant, pendant cette restauration, les instructions à l'intérieur de la transaction dont l'exécution a déjà commencé peuvent continuer l'exécution spéculative, comme dans les étapes (2) et (3) d'autres attaques MDS. TAA affecte tous les processeurs Intel qui prennent en charge TSX, et dans le cas de certains processeurs plus récents qui ne sont pas affectés par d'autres attaques MDS, les atténuations MDS ou spécifiques à TAA (telles que la désactivation de TSX) doivent être implémentées dans le logiciel pour se protéger contre TAA [24].

2.4.4 Atténuations. Bien que les vulnérabilités Meltdown et MDS exploitent des opérations microarchitecturales de bas niveau , elles peuvent être atténuées avec des correctifs de microcode sur les processeurs les plus vulnérables.

Isolement des tables de pages. Historiquement, les tables de pages du noyau ont été incluses dans les tables de pages de processus au niveau utilisateur afin qu'un processus au niveau utilisateur puisse effectuer un appel système au noyau avec une surcharge minimale. L'isolation de la table de pages (proposée pour la première fois par Gruss et al. sous le nom de KAISER [19]) mappe uniquement le strict minimum de mémoire nécessaire du noyau dans la table des pages utilisateur et introduit une deuxième table de pages accessible uniquement par le noyau. Le processus utilisateur étant incapable d'accéder à la table des pages du noyau, les accès à la totalité de la mémoire du noyau, sauf une petite fraction spécifiquement choisie, sont arrêtés avant d'atteindre les caches de niveau inférieur où commence une attaque Meltdown.

Écrasement du tampon. Les attaques MDS qui ciblent les tampons du processeur sur le cœur nécessitent une défense de niveau inférieur et plus ciblée. Intel a introduit une mise à jour du microcode qui écrase les tampons vulnérables lorsque le cache de données de premier niveau (L1d) (une cible courante des attaques par canal secondaire de synchronisation du cache) est vidé ou que l'instruction VERW est exécutée [25]. Le noyau peut alors se protéger contre les attaques MDS en déclenchant un écrasement du tampon lors du passage à un processus non fiable.

L’atténuation par écrasement du tampon cible les attaques MDS à leur source, mais est pour le moins imparfaite. Les processus restent vulnérables aux attaques de threads exécutés simultanément sur le même cœur lorsque SMT est activé (puisque les deux threads partagent des tampons vulnérables sans que le processus actif ne change réellement sur l'un ou l'autre thread). De plus, peu de temps après la mise à jour du microcode d'écrasement du tampon d'origine, l'équipe RIDL a découvert que sur certains processeurs Skylake, les tampons étaient écrasés par des données obsolètes et potentiellement sensibles [50], et restaient vulnérables même avec les atténuations activées et SMT désactivé. D'autres processeurs encore sont vulnérables aux attaques MDS TAA mais pas non TAA, et n'ont pas reçu de mise à jour du microcode d'écrasement du tampon et nécessitent donc que TSX soit complètement désactivé pour empêcher les attaques MDS [20, 24].

2.5 Spectre

En 2018, Jan Horn et Paul Kocher [30] ont signalé indépendamment les premières variantes de Spectre. Depuis lors, de nombreuses variantes et sous-variantes de Spectre [22, 30, 31, 33] [10, 13, 16, 28, 52] ont été découvertes. Les attaques Spectre obligent le processeur à accéder de manière spéculative à une mémoire inaccessible sur le plan architectural et à divulguer les données dans l'état architectural. Par conséquent, toutes les variantes de Spectre se composent de trois composants [27] :

Le premier composant est le gadget Spectre qui est exécuté de manière spéculative. Les variantes de Spectre sont généralement séparées par la source de l’erreur de prédiction qu’elles exploitent. Le résultat d'un branchement direct conditionnel, par exemple, est prédit par la table d'historique de modèles (PHT). Des prédictions erronées du PHT peuvent conduire à un contournement de la vérification des limites spéculatives pour les instructions de chargement et de stockage [13, 28, 30]. La cible de branchement d'un saut indirect est prédite par le Branch Target Buffer (BTB). Si un attaquant peut influencer le résultat d'une prédiction erronée du BTB, alors des attaques spéculatives par programmation orientées retour sont possibles [10, 13, 16, 30]. Il en va de même pour les prédictions servies par le Return Stack Buffer (RSB) qui prédit les adresses de retour lors de l'exécution des instructions de retour [13, 31, 33]. Des résultats récents ont montré que certains processeurs modernes utilisent le BTB pour leurs prédictions d'adresse de retour en cas de dépassement insuffisant du RSB [52]. Une autre source d'attaques Spectre est la prédiction des dépendances entre le stockage et le chargement. Si un chargement est mal prédit comme ne dépendant pas d'un magasin précédent, il s'exécute de manière spéculative sur des données périmées, ce qui peut conduire à un contournement spéculatif du magasin [22]. Tous ces gadgets ne sont pas exploitables par défaut mais dépendent des deux autres composants évoqués maintenant.

Le deuxième élément concerne la manière dont un attaquant contrôle les entrées des gadgets susmentionnés. Les attaquants peuvent être en mesure de définir les valeurs d'entrée du gadget directement via les entrées de l'utilisateur, le contenu des fichiers, les paquets réseau ou d'autres mécanismes architecturaux. D'un autre côté, les attaquants peuvent être capables d'injecter des données dans le gadget de manière transitoire via une injection de valeur de charge [12] ou une injection de valeur à virgule flottante [42]. Les attaquants sont capables de contrôler avec succès les entrées des gadgets s'ils peuvent influencer les données ou les instructions qui sont accédées ou exécutées pendant la fenêtre de spéculation.

Le troisième composant est le canal secret utilisé pour transférer l’état microarchitectural spéculatif dans un état architectural et donc exfiltrer les données consultées de manière spéculative dans un environnement persistant. Les canaux secrets du cache [39, 40, 54] sont applicables si le code de la victime effectue un accès mémoire transitoire en fonction de données secrètes accédées de manière spéculative [30]. Si un secret est accédé de manière spéculative et chargé dans un tampon sur le cœur, un attaquant peut s'appuyer sur un canal basé sur MDS [14, 46, 50] pour transférer de manière transitoire les données exfiltrées vers le thread de l'attaquant où les données sont transférées vers l'architecture. état via, par exemple, un canal caché de cache. Enfin et surtout, si la victime exécute du code en fonction de données secrètes, l'attaquant peut apprendre le secret en observant les conflits de ports [3, 11, 18, 43, 44].

2.5.1 Atténuations. De nombreuses contre-mesures ont été développées pour atténuer les différentes variantes de Spectre. Une variante spécifique de Spectre est effectivement désactivée si l'un des trois composants requis est supprimé. Il est peu probable qu’un attaquant sans contrôle sur les entrées des gadgets Spectre réussisse à lancer une attaque. Il en va de même si aucun canal secret permettant de transformer l’État spéculatif en un État architectural n’est disponible. Mais comme cela est généralement difficile à garantir, les contre-mesures Spectre se concentrent principalement sur l’arrêt des prédictions erronées. L'insertion d'instructions lfence avant les sections de code critiques désactive l'exécution spéculative au-delà de ce point et peut donc être utilisée comme contre-mesure générique. Mais en raison de ses performances élevées, des contre-mesures plus spécifiques ont été développées. Les contre-mesures Spectre-BTB incluent Retpoline [48] et des mises à jour de microcodes comme IBRS, STIBP ou IBPB [23]. Spectre-RSB et Spectre-BTB-via-RSB peuvent être atténués en remplissant le RSB avec des valeurs pour écraser les entrées malveillantes et empêcher le RSB de déborder ou en installant des mises à jour du microcode IBRS. Spectre-STL peut être atténué par la mise à jour du microcode SSBD [23]. Une autre option radicale pour empêcher un attaquant de falsifier les tampons de prédiction de branche partagés consiste à désactiver SMT. La désactivation de SMT partitionne efficacement les ressources matérielles de prédiction de branche entre les locataires simultanés au prix d'une perte de performances significative.

2.6 Modèle d'isolation d'AWS

Firecracker est spécialement conçu pour les applications sans serveur et de conteneurs [1] et est actuellement utilisé par Fargate CaaS et Lambda FaaS d'AWS. Dans ces deux modèles de service, Firecracker est le principal système d'isolation qui prend en charge chaque tâche Fargate ou événement Lambda individuel. Ces deux modèles de service sont également conçus pour exécuter un très grand nombre de tâches relativement petites et de courte durée. AWS détaille les exigences de conception pour le système d'isolation qui est finalement devenu Firecracker comme suit :

Isolation : il doit être sûr que plusieurs fonctions s'exécutent sur le même matériel, protégées contre l'élévation de privilèges, la divulgation d'informations, les canaux secrets et autres risques.

Frais généraux et densité : il doit être possible d'exécuter des milliers de fonctions sur une seule machine, avec un minimum de gaspillage.

Performances : les fonctions doivent fonctionner de la même manière que si elles étaient exécutées en mode natif. Les performances doivent également être cohérentes et isolées du comportement des voisins sur le même matériel.

Compatibilité : Lambda permet aux fonctions de contenir des binaires et des bibliothèques Linux arbitraires. Ceux-ci doivent être pris en charge sans modification de code ni recompilation.

Commutation rapide : il doit être possible de démarrer de nouvelles fonctions et de nettoyer rapidement les anciennes fonctions.

Allocation logicielle : il doit être possible de surcharger le processeur, la mémoire et les autres ressources, chaque fonction consommant uniquement les ressources dont elle a besoin, et non celles auxquelles elle a droit. [1]

Nous sommes particulièrement intéressés par l’exigence d’isolement et soulignons que les attaques microarchitecturales sont déclarées comme entrant dans le champ d’application du modèle de menace Firecracker. La page « conception » du référentiel Git Firecracker public d'AWS développe le modèle d'isolation et fournit un diagramme utile que nous reproduisons dans la figure 2. Ce diagramme concerne principalement la protection contre l'élévation de privilèges. La couche de protection la plus externe est le jailer, qui utilise des techniques d'isolation de conteneur pour limiter l'accès du Firecracker au noyau hôte lors de l'exécution du VMM et d'autres composants de gestion.

de Firecracker en tant que threads d'un processus unique dans l'espace utilisateur hôte. Dans le processus Firecracker, la charge de travail de l'utilisateur est exécutée sur d'autres threads. Les threads de charge de travail exécutent le système d'exploitation invité de la machine virtuelle et tous les programmes exécutés sur l'invité. L'exécution du code de l'utilisateur dans l'invité de la machine virtuelle limite son interaction directe avec l'hôte à des interactions pré-arrangées avec KVM et certaines parties des threads de gestion Firecracker. Ainsi, du point de vue du noyau hôte, le VMM et la VM incluant le code de l'utilisateur sont exécutés dans le même processus. C'est la raison pour laquelle AWS déclare que chaque VM réside dans un seul processus. Mais comme la VM est isolée via des techniques de virtualisation matérielle, le code de l'utilisateur, le noyau invité et le VMM fonctionnent dans des espaces d'adressage distincts. Par conséquent, le code de l'invité ne peut pas accéder de manière architecturale ou transitoire aux adresses mémoire du VMM ou du noyau invité car elles ne sont pas mappées dans l'espace d'adressage de l'invité. La surface d'attaque microarchitecturale restante est limitée aux attaques MDS qui fuient des informations des tampons internes du processeur en ignorant les limites de l'espace d'adressage et aux attaques Spectre où un attaquant manipule la prédiction de branchement d'autres processus pour divulguer automatiquement des informations.

L' isolement des fonctions les unes par rapport aux autres lorsque le matériel est partagé, en particulier à la lumière de l'exigence d'allocation souple , n'est pas illustré dans la figure 2, mais tout aussi important pour le modèle de menace d'AWS. Outre le fait que la compromission du noyau hôte pourrait compromettre la sécurité de tous les invités, les attaques microarchitecturales ciblant le matériel hôte peuvent également menacer directement le code utilisateur. Puisqu'un seul processus Firecracker contient tous les threads nécessaires pour exécuter une machine virtuelle avec une fonction utilisateur, l'allocation logicielle peut simplement être effectuée par le système d'exploitation hôte [1]. Cela signifie que des systèmes d'isolation de processus Linux standard sont en place en plus de l'isolation des machines virtuelles.

2.6.1 Recommandations de sécurité des pétards. La documentation Firecracker recommande également les précautions suivantes pour se protéger contre les canaux latéraux microarchitecturaux [8] :

• Désactiver SMT

• Activer l'isolation de la table de pages du noyau

• Désactiver la fusion des pages kame du noyau

• Utilisez un noyau compilé avec l'atténuation Spectre-BTB (par exemple, IBRS et IBPB sur x86)

• Vérifier l'atténuation Spectre-PHT

• Activer l'atténuation L1TF • Activer l'atténuation Spectre-STL

• Utiliser la mémoire avec l'atténuation Rowhammer

• Désactivez l'échange ou utilisez l'échange sécurisé.

[1] Les anneaux virtualisés 0 et 3 sont l'une des principales raisons pour lesquelles l'exécution de code quasi natif est obtenue.