Meltdown & Specter - L'application de correctifs au noyau invité d'un hyperviseur non corrigé empêche-t-elle les fuites de mémoire entre plusieurs machines virtuelles?


12

24 heures après la publication à grande échelle des vulnérabilités, Rackspace est silencieux sur Spectre et Meltdown. Ils n'ont pas de plan pour patcher tous leurs hyperviseurs Xen. Tous leurs serveurs de plate-forme plus récents sont des serveurs HVM, qui sont vulnérables. Les serveurs PV plus anciens ne sont pas vulnérables.

J'ai mis à jour le noyau Linux de mes invités HVM, mais Rackspace n'a mis à jour aucun de leurs hyperviseurs. La mise à jour du noyau invité sur un hyperviseur non corrigé empêchera-t-elle les machines virtuelles «malveillantes» d'accéder à la mémoire qui a fui de mon hôte corrigé?


Réponses:


12

D'après ce que je comprends des vulnérabilités, non - les attaques de mise en cache spéculative contournent toutes les protections du processeur contre un processus accaparant la mémoire à partir de n'importe quelle adresse arbitraire.

Je pense que cela inclurait les machines virtuelles voisines (même celles corrigées pour se protéger contre l'attaque elles-mêmes) ainsi que l'espace mémoire du noyau de l'hyperviseur - mais même s'il y a quelque chose qui me manque qui protégerait contre la divulgation directe de la mémoire, il y a aussi un potentiel que l'attaquant pourrait utiliser leur accès à la mémoire du noyau pour obtenir un accès plus complet à l'hyperviseur.

Vous ne voulez certainement pas risquer d'exécuter une charge de travail sensible sur un hyperviseur non corrigé de quelque nature que ce soit si vous ne faites pas confiance à toutes les machines virtuelles qui s'exécutent dessus.


6
Pour le dire clairement: avoir un noyau invité corrigé peut empêcher votre machine virtuelle d'accéder à l'hyperviseur ou à d'autres machines virtuelles, mais cela n'empêchera pas d'autres machines virtuelles d'accéder au vôtre!
Michael Hampton

Salut Shane, c'est aussi ma conviction. Avez-vous des documents à l'appui de cela? Le point spécifiquement sur la mémoire d'un invité corrigé étant vulnérable aux autres invités sur le même matériel. Merci.
Danny F

2
@DannyF La référence la plus directe à cela que j'ai pu trouver était dans le document de fusion - "la mémoire physique d'autres processus, le noyau, et dans le cas de solutions sandbox partageant le noyau (par exemple, Docker, LXC) ou Xen en mode de paravirtualisation, mémoire du noyau (ou hyperviseur) et d'autres instances colocalisées "
Shane Madden

-4

Spectre et fusion.

Où allons-nous commencer? un mauvais, je veux dire un très mauvais communiqué de presse de quelque chose qui peut ou non affecter votre ordinateur, poste de travail, serveur ou serveur dans le cloud. Oui, tout à fait, mais vous devez avoir un accès local au processeur associé, qui peut être un PC ou un téléphone, semble-t-il, Apple a été un exemple mais laisse penser son processeur ARM, donc c'est chaque plate-forme mobile qui prend en charge la (fonctionnalité / exposition au microcode / trop de contrôle sur le CPU à partir du système d'exploitation / etc / etc)

L'application doit être exécutée sur le processeur de l'appareil, donc je pense que l'accès à la console, ou au moins l'utilisateur distant qui accède au système, l'accès au périphérique d'entrée ....

À l'heure actuelle, la seule façon connue d'exploiter ces vulnérabilités est d'accéder localement / directement au processeur (encore une fois, vous pouvez être distant une fois que vous avez SSH / VNC, etc.)

Voici les correctifs que j'ai trouvés jusqu'à présent.

VMWare has released a security advisory for their ESXi, Workstation and Fusion products: VMSA-2018-0002
[https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html][1]

RedHat has released a security advisory for their qemu product:  [https://access.redhat.com/errata/RHSA-2018:0024][1]

Amazon has released a security advisory for their Amazon Linux AMI product: ALAS-2018-939

https://alas.aws.amazon.com/ALAS-2018-939.htm l

Maintenant, cela doit être la meilleure réponse au problème en ce moment

Qu'ont dit nos amis BSD?

Mauvais google; (

un chèque Powershell pour la même chose;)

Le noyau Linux D'accord, nous avons eu une semaine intéressante, et maintenant tout le monde sait pourquoi nous avons fusionné tous ces correctifs d'isolement des tables de pages x86 sans suivre toutes les règles normales de calendrier de publication.

Je pourrai / reviendrai et modifierai ce message. Je suis sûr que le non-problème (jusque dans la nature) ne sera pas un vrai problème à long terme. Google aurait vraiment dû suivre les dates de publication des divulgations ici! -1 pour Google


"Amazon Linux (AMI)" est la distribution Linux d'Amazon, qui est affectée de la même manière que tous les autres systèmes d'exploitation invités. Plus pertinent dans ce contexte est aws.amazon.com/de/security/security-bulletins/AWS-2018-013 (section initiale) pour l'annonce EC2 (leur plateforme de virtualisation), car vous sembliez essayer de lister les solutions de virtualisation.
Håkan Lindqvist

1
En lisant et en relisant ceci, je ne pense pas que cela réponde réellement à la question? C'est surtout une diatribe sur le processus de divulgation?
Håkan Lindqvist

J'apprécie l'éditorial et les liens pour les correctifs, mais cette réponse est trompeuse ou du moins déroutante. Je crois que cela indique que le scénario que j'ai décrit nécessiterait un accès local à l'hyperviseur xenserver, ce qui n'est pas vrai. La seule exigence est que le méchant ait sa propre VM sur le même hyperviseur que la VM victime.
Danny F
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.