la vulnérabilité de sécurité du spectre peut-elle être dans une machine virtuelle?

Est-il possible qu'une machine virtuelle telle que VirtualBox ait la vulnérabilité de sécurité "spectre"? Je pense que la VM exécute peut-être dans le désordre, mais à mon avis, il n'est pas possible de jeter un coup d'œil à la mémoire cache pour lire le résultat.

Existe-t-il une explication quant à la possibilité de lire le cache d'un processeur virtuel?

Oui, un peu de recherche aurait confirmé que VMWare a publié des correctifs pour résoudre les problèmes de Spectre et de Meltdown. Le système d'exploitation invité doit être corrigé, en plus de l'hyperviseur réel (les deux types)

— Ramhound

Cela dépend du niveau de virtualisation, je dirais. Si vous simulez un processeur virtuel, vous êtes probablement en sécurité. Mais ce n'est pas ce que font les machines virtuelles modernes.

— Bergi

Existe-t-il une explication quant à la possibilité de lire le cache d'un processeur virtuel?

Les détails de @jms se trouvent dans le billet canonique que j'ai lié dans ma réponse:

Spectre works on a different level ... In this attack, the attacker tricks the speculative execution to predictively execute instructions erroneously. In a nutshell, the predictor is coerced to predict a specific branch result that results in asking for an out-of-bound memory access that the victim process would not normally have requested resulting in incorrect speculative execution. Then by the side-channel, retrieves the value of this memory. In this way memory belonging to the victim process is leaked to the malicious process.

— Mokubai

@jms La virtualisation n’est rapide que parce qu’elle utilise le processeur physique avec le moins d’abstractions possible et s’appuie sur le matériel de celui-ci pour assurer l’isolation et l’abstraction. Des choses comme l’ qemuémulation peuvent être plus sûres car ce n’est pas un processeur matériel , mais c’est beaucoup plus lent et différent de la virtualisation.

— Mokubai

Oui Spectre peut franchir les limites hôte / invité, invité / hôte et invité / invité car il s’agit d’une faille au niveau du processeur, ce qui signifie que des informations potentiellement sensibles peuvent être divulguées sur tout ce qui s’exécute sur un cœur de processeur.

La plupart des reportages sur Internet parlent des fournisseurs de cloud computing les plus touchés, car ils disposent d'énormes grappes de systèmes virtualisés qui pourraient potentiellement être utilisés pour divulguer des informations sensibles.

La plupart des grands fournisseurs auraient déjà dû être corrigés contre les failles, du mieux qu'ils peuvent être, mais ce problème persistera pendant un certain temps.

Security.SE a une question canonique à ce sujet et mentionne les ordinateurs virtuels:

J'utilise une machine virtuelle / des conteneurs, dans quelle mesure suis-je vulnérable?

Selon la réponse de Steffen Ullrich

Les attaques de fusion ne traversent pas les machines virtuelles, seulement la mémoire du noyau est perdue vers les processus locaux.

Spectre peut fonctionner sur plusieurs ordinateurs virtuels.

De plus, depuis Steffen , Meltdown et Specter fonctionnent avec des conteneurs, car ceux-ci reposent sur le noyau hôte.

Les ordinateurs virtuels utilisent le processeur réel de votre système avec des instructions privilégiées piégées pouvant être redirigées. Il utilise les mêmes caches et instructions que l'hôte. Il ne s'agit essentiellement que d'une couche supplémentaire au sein de la CPU physique de votre système.

La virtualisation est rapide car elle utilise le processeur physique avec le moins d'abstraction possible et utilise le matériel du processeur pour assurer l'isolation. Des choses comme qemu peuvent faire une émulation qui serait plus sûre car ce n'est pas un processeur matériel, mais c'est beaucoup plus lent et différent de la virtualisation.

De la publication canonique Security.se à nouveau:

Spectre fonctionne à un niveau différent et n'autorise pas l'accès aux données de l'espace noyau à partir de l'espace utilisateur. Dans cette attaque, l'attaquant trompe l'exécution spéculative pour exécuter de manière prédictive des instructions erronées. En un mot, le prédicteur est contraint de prédire un résultat de branche spécifique (si -> true), ce qui conduit à demander un accès mémoire en dehors de la limite que le processus victime n'aurait normalement pas demandé, entraînant une exécution spéculative incorrecte. Ensuite, par le canal latéral, récupère la valeur de cette mémoire. De cette manière, la mémoire appartenant au processus victime est filtrée vers le processus malveillant.

Donc, comme la VM s'exécute dans le matériel de la CPU et qu'il ne lui reste plus qu'à exécuter une boucle particulière pour "entraîner" le moteur d'exécution spéculatif. Ensuite, il peut utiliser un minutage précis pour examiner les caches pour des modèles d'accès particuliers indiquant le processus hôte ou invité (ou autre machine virtuelle) qu'il cherche à exploiter.

De cette façon, cela signifie qu'une machine est exploitable dans toutes les directions. D'hôte à machine virtuelle, de machine virtuelle à hôte et de machine virtuelle à machine virtuelle.

Oui, ce n'est pas facile et c'est difficile à retirer, car le cœur de la machine virtuelle peut changer à la guise de l'hôte et celui-ci peut également planifier des tâches sur différents cœurs, mais sur une longue période, suffisamment d'informations peut être divulgué pour donner une clé secrète à un système ou à un compte important. Si on dispose de suffisamment de temps et de logiciels suffisamment furtifs, tout est potentiellement ouvert.

Si vous voulez une machine virtuelle "sécurisée", vous devez vous assurer que ses cœurs sont isolés. Le seul moyen réel de bloquer cette attaque serait de "forcer" l'hôte et les ordinateurs virtuels à n'utiliser que certains cœurs afin qu'ils ne s'exécutent jamais sur le même matériel, ce qui entraînerait une augmentation effective des coûts, car vous ne pourriez pas avoir autant de VM sur un hôte donné. Vous ne seriez jamais en mesure d'exécuter plus de machines virtuelles que de cœurs disponibles, ce que je m'attendrais à faire sur des serveurs «à faible charge», car de nombreux systèmes restent inactifs pendant 90% de leur durée de vie.

— Mokubai
source

Je pense que vous avez interprété la question comme suit: "Si la CPU hôte est affectée, la VM sera-t-elle également affectée?" Si je comprends bien la question, il demande "si le processeur hôte n'est pas affecté, la VM peut-elle encore être affectée?" Pourriez-vous éclaircir cela?

— AndreKR

@AndreKR: actuellement, tous les processeurs d'exécution dans le désordre sont affectés par Spectre; vous ne pouvez sécuriser un système qu'avec des solutions de contournement logicielles (la VM devrait donc s'en préoccuper, même si un hyperviseur peut isoler les invités les uns des autres si le processeur le permet, par exemple Intel IBRS). Mais sur un processeur en ordre sans exécution spéculative, aucune vulnérabilité de Spectre ne peut exister entre deux logiciels. L'essence de Spectre provoque l'exécution spéculative de quelque chose qui place les données secrètes dans un état microarchitectural; les processeurs en ordre ne le font pas.

— Peter Cordes

La chose la plus intéressante n’est pas l’exécution spéculative. La chose la plus intéressante est de savoir comment un processus peut découvrir ce qu'il y a dans le cache, même dans un ordinateur virtuel.

@jms les attaques par canaux auxiliaires disponibles sont facilitées et rendues utiles par l'exécution spéculative. Le processus peut ne pas être en mesure de lire directement les lignes de cache, mais l'exécution spéculative peut laisser échapper des informations en effectuant des calculs qui mettent des valeurs dans le cache qui peuvent être détectées ou déduites par des attaques temporelles. La section 4 du livre blanc spectre a une bonne explication: spectreattack.com/spectre.pdf

— Mokubai

Gem 5

Si vous souhaitez étudier / reproduire des vulnérabilités uniquement avec une émulation, sans utiliser le processeur hôte, je ne pense pas que QEMU est suffisamment détaillé pour pouvoir les observer car il ne simule pas le pipeline de processeur.

Cependant, gem5 est utilisé pour estimer les performances du système en recherche et développement et simule suffisamment d'internes de processeur pour vous permettre d'observer Specter dans un environnement entièrement propre et contrôlé.

Une démo x86_64 avec visualisation a été publiée sur: http://www.lowepower.com/jason/visualizing-spectre-with-gem5.html

L'inconvénient de gem5 est qu'il est beaucoup plus lent que QEMU et que la simulation est plus détaillée.

— Ciro Santilli 改造中心 996ICU 事件
source