Sécurité microarchitecturale d'AWS Firecracker VMM : analyse des attaques et des défenses microarchitecturales

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

5. ANALYSE DES ATTAQUES ET DES DÉFENSES MICROARCHITECTURALES DANS LES MICROVMS PÉTARDS

Dans cette section, nous présentons notre analyse d’un certain nombre de PoC microarchitecturaux d’attaques spéculatives et de canaux secondaires sur les microVM Firecracker. Nous testons ces PoC sur du bare metal et dans des instances Firecracker, et testons les défenses de microcode pertinentes dans les différents scénarios. Nous effectuons nos tests sur un serveur équipé d'un processeur Intel Skylake 4114

qui a des extensions matérielles de virtualisation et SMT activé. Le processeur fonctionne sur la version de microcode 0x2006b06[2]. Le système d'exploitation hôte est Ubuntu 20.04 avec un noyau Linux 5.10. Nous avons utilisé Firecracker v1.0.0 et v1.4.0, la dernière version en juillet 2023, pour exécuter un invité Ubuntu 18.04 avec le noyau Linux 5.4 fourni par Amazon en suivant le guide de démarrage rapide[3].

En résumé, la configuration d'hôte de production recommandée fournie avec AWS Firecracker est insuffisante pour protéger les locataires contre les voisins malveillants. Firecracker ne parvient donc pas à fournir ses garanties d’isolation revendiquées. Ceci est dû au fait

(1) nous identifions une variante de Medusa qui ne devient exploitable que lorsqu'elle est exécutée sur des microVM. De plus, les contre-mesures recommandées ne contiennent pas les étapes nécessaires pour atténuer le canal secondaire, ou la plupart des autres variantes de Medusa.

(2) nous montrons que les locataires ne sont pas correctement protégés contre les fuites d'informations induites par Spectre-PHT ou Spectre-BTB lors de l'application des contre-mesures recommandées. Les variantes Spectre-PHT restent un problème même en désactivant SMT.

(3) nous n'avons observé aucune différence dans les performances PoC entre Firecracker v1.0.0 et v1.4.0.

Nous concluons que la couche de virtualisation fournie par Firecracker a peu d'effet sur les attaques microarchitecturales et que les recommandations de sécurité du système de Firecracker sont insuffisantes.

5.1 Méduse

Nous avons évalué les PoC de Moghimi [35] pour les canaux latéraux Medusa [37] (classés par Intel comme variantes MLPDS de MDS [25]) sur le métal nu de notre système de test et dans les machines virtuelles Firecracker. Il existe un PoC de fuite pour chacune des trois variantes connues décrites dans la section 2.4.2. Nous avons utilisé deux programmes victimes de la bibliothèque PoC :

• Le programme « Block Write » écrit une grande quantité de données consécutives en boucle (afin que le processeur identifie les stockages répétés et les combine).

• Le programme « REP MOV » effectue une opération similaire, mais avec l'instruction REP MOV au lieu de nombreuses instructions déplaçant des blocs de données plus petits dans une boucle.

5.1.1 Résultats. Le tableau 1 montre les cas dans lesquels des données ont été divulguées avec succès avec toutes les protections microarchitecturales du noyau désactivées. Les deux colonnes de gauche montrent les combinaisons possibles des trois PoC Medusa et des deux programmes destinés aux victimes inclus. Les colonnes de droite indiquent quelles configurations fonctionnent sur du métal nu et avec le programme secret et fuyant s'exécutant dans des instances Firecracker parallèles. Plus particulièrement, avec la variante Cache Indexing, le secret Block Write ne fonctionne qu'avec Firecracker. Cela est probablement dû à la virtualisation des adresses mémoire fournie par la machine virtuelle : l'invité ne voit que les régions de mémoire virtuelle mappées par KVM, et KVM intercepte les instructions d'accès à la mémoire et gère les transactions au nom de l'invité.

Nous avons testé l'efficacité des défenses mds et nosmt contre chaque combinaison de PoC d'attaquant et de victime sur du bare metal et dans des machines virtuelles Firecracker. Le tableau 2 répertorie les protections nécessaires pour empêcher les attaques Medusa dans les scénarios Bare Metal et Firecracker. Sur les quatre vulnérabilités de Firecracker, une seule est atténuée par nosmt seul, et AWS ne recommande pas explicitement d'activer la protection mds, bien que la plupart des distributions Linux soient livrées avec cette fonctionnalité activée par défaut. Autrement dit, une plate-forme cloud multi-tenant pourrait utiliser Firecracker d'une manière conforme aux mesures de sécurité recommandées par AWS tout en restant vulnérable à la majorité des variantes de Medusa, y compris une où le VMM Firecracker lui-même divulgue les données de l'utilisateur. ne risquerait pas de fuir autrement.

5.2 RIDL et plus

Dans cette section, nous présentons une évaluation des programmes RIDL PoC [51] fournies parallèlement à l'article de van Schaik et al. 2019 [50]. RIDL est une classe d'attaques MDS qui exploite les charges spéculatives des tampons à l'intérieur du processeur (et non du cache ou de la mémoire). Le référentiel RIDL PoC comprend également des exemples d'attaques publiées dans des addenda ultérieurs au document ainsi qu'une variante de l'attaque Fallout MDS.

5.2.1 Résultats. Le tableau 3 présente quelques informations de base sur les PoC RIDL que nous avons testés et sur l'efficacité des contre-mesures pertinentes pour prévenir les attaques. Nous avons comparé les attaques sur bare metal et dans Firecracker pour évaluer les affirmations d'Amazon concernant la sécurité matérielle accrue du système microVM Firecracker. Pour les tests sur le système Firecracker, nous distinguons les indicateurs de contre-mesure activés sur le système hôte (H) et le noyau invité (VM) de Firecracker. Outre les options du noyau nosmt et mds, nous avons testé d'autres options pertinentes (cf. section 2.4.4, [21]), notamment kaslr, pti et l1tf, mais nous n'avons trouvé aucun effet sur aucun de ces programmes. Nous avons exclu l'atténuation tsx_async_abort puisque le processeur sur lequel nous avons testé inclut l'atténuation mds qui rend l'indicateur du noyau tsx_async_abort redondant [20].

En général, nous avons constaté que la protection mds ne protège pas adéquatement contre la majorité des attaques RIDL. Cependant, la désactivation de SMT atténue la majorité de ces exploits. Ceci est cohérent avec les déclarations d'Intel [25] et des développeurs Linux [21] selon lesquelles SMT doit être désactivé pour empêcher les attaques MDS à travers les hyperthreads. Les deux valeurs aberrantes parmi ces PoC sont aligning_write, qui nécessite à la fois nosmt et mds sur l'hôte, et pgtable_leak_notsx, qui n'est atténué que par des contre-mesures mds. La fuite s'appuyant sur l'alignement_write utilise une faute d'alignement plutôt qu'une fuite de faute de table de pages pour déclencher la spéculation [50]. L'article RIDL [50] et la documentation d'Intel sur l'exploit VRS associé [26] ne savent pas exactement ce qui différencie cette attaque des attaques MFBDS basées sur des défauts de page trouvées dans d'autres PoC, mais nos résultats expérimentaux indiquent que le mécanisme microarchitectural de la fuite est distinct. Il existe une explication simple et raisonnable au comportement de pgtable_leak_notsx, qui est unique parmi ces PoC pour une raison clé : c'est le seul exploit qui franchit les limites de sécurité (fuite des valeurs de la table de pages du noyau) au sein d'un seul thread plutôt que de fuite depuis un autre fil. Il va de soi que la désactivation du multithreading aurait peu d’effet sur cet exploit monothread. Cependant, la contre-mesure mds vide les tampons microarchitecturaux avant de passer de l'exécution avec privilèges noyau à l'exécution avec privilèges utilisateur au sein du même thread, effaçant ainsi les données de la table de pages accessibles par le code noyau du LFB avant que le code utilisateur attaquant ne puisse les divulguer.

Contrairement à Medusa, la plupart de ces PoC sont atténués par la recommandation d'AWS de désactiver smt. Cependant, comme pour Medusa, le Firecracker VMM lui-même n'offre aucune protection microarchitecturale contre ces attaques.

5.3 Spectre

Nous nous concentrons ensuite sur les vulnérabilités Spectre. Bien que de nombreuses contre-mesures aient été développées depuis la découverte des attaques Spectre, beaucoup d'entre elles s'accompagnent d'une pénalité (importante) en termes de performances ou n'atténuent que partiellement l'attaque. Donc,

Les opérateurs de systèmes doivent souvent faire un compromis entre performances et sécurité. Dans cette section, nous évaluons la surface d'attaque Spectre disponible pour les locataires Firecracker dans les deux modèles de menace décrits précédemment. Pour évaluer le large éventail d’attaques Spectre, nous nous appuyons sur les PoC fournis dans [15]. Pour Spectre-PHT, Spectre-BTB et SpectreRSB, le référentiel contient chacun quatre PoC. Ils diffèrent par la manière dont l'attaquant manipule mal le BPU. Les quatre possibilités sont (1) le même processus : l'attaquant contrôle le processus victime ou ses entrées pour mal entraîner le BPU – (2) le processus croisé : l'attaquant exécute son propre code dans un processus séparé pour influencer les prédictions de branche de le processus victime – (a) sur place – l'attaquant entraîne mal le BPU avec des instructions de branche qui résident à la même adresse virtuelle que la branche cible que l'attaquant souhaite voir mal prédite dans le processus victime – (b) hors- lieu : l'attaquant malmène le BPU avec des instructions de branchement qui résident à des adresses congruentes aux branches cibles dans le processus victime.

(1) même processus : l'attaquant a le contrôle du processus victime ou de ses entrées pour mal entraîner le BPU,

(2) inter-processus : l'attaquant exécute son propre code dans un processus distinct pour influencer les prédictions de branche du processus victime,

(3) sur place : l'attaquant malmène le BPU avec l'instruction de branche qui réside à la même adresse virtuelle que la branche cible que l'attaquant veut voir mal prédite dans le processus victime

(4) déplacé : l'attaquant entraîne mal le BPU avec des instructions de branchement qui résident à des adresses congruentes aux branches cibles dans le processus victime.

Les deux premières et les deux dernières situations sont orthogonales, donc chaque PoC en combine deux. Pour Spectre-STL, seules les variantes du même processus sont connues, c'est pourquoi le référentiel ne fournit que deux PoC dans ce cas. Pour les expériences inter-VM, désactivation de la randomisation de la disposition de l'espace d'adressage pour les noyaux hôte et invité ainsi que pour le niveau utilisateur hôte et invité afin de faciliter la recherche d'adresses congruentes utilisées pour une mauvaise formation.

5.3.1 Résultats. Avec les contre-mesures recommandées par AWS [8] (par défaut pour les noyaux Linux utilisés, cf. Figure 5) activées sur le système hôte et à l'intérieur des VM Firecracker, nous voyons que Spectre-RSB est atténué avec succès à la fois sur l'hôte et à l'intérieur et entre les VM. (cf. tableau 4). D'un autre côté, Spectre-STL, Spectre-BTB et Spectre-PHT ont permis des fuites d'informations dans des situations particulières.

Les PoC pour Spectre-STL montrent des fuites. Cependant, la fuite ne se produit qu’au sein du même processus et du même niveau de privilèges. Puisqu'aucune variante inter-processus n'est connue, nous n'avons pas testé le scénario crossVM pour Spectre-STL. Dans notre modèle de menace d'utilisateur à utilisateur, Spectre-STL n'est pas un vecteur d'attaque possible, car aucune variante inter-processus n'est connue. Si deux charges de travail locataires étaient isolées par une isolation en cours au sein de la même VM, Spectre-STL pourrait toujours être un vecteur d'attaque viable. Dans le modèle utilisateur-hôte, Spectre-STL est atténué par des contre-mesures incluses dans les noyaux Linux actuels et activées par défaut.

Pour Spectre-PHT, les contre-mesures du noyau incluent la désinfection des pointeurs utilisateur et l'utilisation de barrières (lfence) sur les commutateurs de niveau de privilège. Nous concluons donc que SpectrePHT ne représente que peu ou pas de menace pour le système hôte. Cependant, ces

les atténuations ne protègent pas deux hyperthreads l’un de l’autre s’ils s’exécutent en parallèle sur le même cœur physique. C'est pourquoi les quatre variantes de mauvaise formation Spectre-PHT sont entièrement fonctionnelles sur le système hôte ainsi qu'à l'intérieur des machines virtuelles Firecracker. Comme on peut le voir dans le tableau 4, cela reste vrai même si SMT est désactivé[4]. En fait, épingler les deux machines virtuelles sur le même thread physique permet la version inter-processus déplacée de Spectre-PHT alors que nous n'avons pas observé de fuite dans le cas SMT. Cela fait de Spectre-PHT une menace importante pour l’utilisateur.

Les PoC Spectre-BTB sont partiellement fonctionnels lorsque les contre-mesures recommandées par AWS sont activées. La variante originale qui entraîne une erreur de BTB dans le même processus et à la même adresse est entièrement fonctionnelle, tandis qu'une erreur de formation déplacée dans le même processus est

atténuée avec succès. De plus, toutes les tentatives de fuite d’informations au-delà des limites du processus via une mauvaise formation déplacée n’ont montré aucune fuite. Cependant, avec un mauvais entraînement sur place entre processus, nous avons observé des fuites. Sur le système hôte, la fuite s'est produite indépendamment du SMT. À l’intérieur d’une VM, la fuite ne se produisait que si tous les cœurs de processeur virtuels étaient attribués à un thread physique distinct. Sur les machines virtuelles, la désactivation de SMT a supprimé la fuite.

Outre les contre-mesures répertoriées dans la figure 5, le noyau hôte dispose de contre-mesures Spectre compilées dans les points d'entrée et de sortie de la VM[5] pour empêcher complètement les invités malveillants d'attaquer le noyau hôte pendant que le noyau gère une sortie de VM.

En résumé, nous pouvons dire que les contre-mesures par défaut de Linux, recommandées par AWS Firecracker, n'atténuent que partiellement Spectre. Précisément, nous montrons :

• Spectre-PHT et Spectre-BTB peuvent toujours divulguer des informations entre locataires dans le scénario d'invité à invité avec les contre-mesures recommandées par AWS, qui incluent la désactivation de SMT.

• Le noyau hôte est probablement suffisamment protégé par les précautions supplémentaires compilées dans le noyau Linux pour protéger les entrées et sorties de la machine virtuelle. Ceci est cependant orthogonal aux mesures de sécurité fournies par Firecracker.

Toutes les fuites observées étaient indépendantes de la version Firecracker utilisée.

5.3.2 Évaluation. Nous constatons que Firecracker n'ajoute rien aux atténuations contre Spectre mais s'appuie uniquement sur des recommandations générales de protection, qui incluent des atténuations fournies par les noyaux hôte et invité et des mises à jour facultatives du microcode. Pire encore, les contre-mesures recommandées ne protègent pas suffisamment les applications sans serveur contre les fuites d'informations vers d'autres locataires. Nous affirmons donc que Firecracker n’atteint pas son objectif d’isolement au niveau microarchitectural, même si les attaques microarchitecturales sont considérées comme entrant dans le champ d’application du modèle de menace Firecracker.

Le lecteur averti pourrait se demander pourquoi Spectre-BTB reste un problème avec la contre-mesure STIBP en place (cf. Figure 5), car ce correctif de microcode a été conçu pour empêcher la prédiction de branche d'utiliser des informations de prédiction provenant d'un autre thread. Cela nous a également intrigués pendant un certain temps jusqu'à ce que Google publie récemment un avis de sécurité[6] qui identifie une faille dans Linux 6.2 qui désactivait l'atténuation STIBP lorsque IBRS était activé. Nous avons vérifié que la section de code identifiée comme étant responsable du problème est également présente dans le code source de Linux 5.10. Nous supposons donc que le même problème identifié par Google se produit également sur notre système.

[2] La mise à jour du microcode vers une version plus récente désactiverait TSX sur notre système, ce qui rendrait impossible les tests avec les variantes MDS basées sur TSX.

[3] https://github.com/firecracker-microvm/firecracker/blob/dbd9a84b11a63b5e5bf201e244fe83f0bc76792a/docs/getting-started.md

[4] Ceci est simulé en épinglant les processus de l'attaquant et de la victime sur le même noyau ((1PT))

[5] https://elixir.bootlin.com/linux/v5.10/source/arch/x86/kvm/vmx/vmenter.S#L191

[6] https://github.com/google/security-research/security/advisories/GHSA-mj4w6495-6crx