Partager via

Problèmes de sécurité liés à la mémoire partagée des machines virtuelles NDIS

  • Article

Cette rubrique décrit les problèmes de sécurité potentiels liés à l’allocation de mémoire partagée à partir d’une machine virtuelle pour les mémoires tampons de réception de file d’attente de machines virtuelles (VMQ). Cette rubrique inclut les sections suivantes :

Note Dans Hyper-V, une partition enfant est également appelée machine virtuelle.

Vue d’ensemble des problèmes de sécurité liés à la mémoire partagée des machines virtuelles

Les machines virtuelles ne sont pas des entités logicielles approuvées. Autrement dit, une machine virtuelle malveillante ne doit pas être en mesure d’interférer avec d’autres machines virtuelles ou le système d’exploitation de gestion qui s’exécute dans la partition parente Hyper-V. Cette section fournit des informations générales et des conditions requises pour s’assurer que les rédacteurs de pilotes comprennent les problèmes de sécurité vmQ et les exigences pour la mémoire partagée. Pour plus d’informations sur la mémoire partagée, consultez la rubrique Allocation de ressources de mémoire partagée dans la section Écriture de pilotes VMQ .

Dans l’environnement virtualisé, la mémoire partagée de la machine virtuelle peut être consultée ou modifiée par la machine virtuelle. Toutefois, l’affichage ou la modification des données associées à d’autres machines virtuelles n’est pas autorisé. Les machines virtuelles ne sont pas non plus autorisées à accéder à l’espace d’adressage d’exploitation de gestion.

La partie d’en-tête des paquets reçus doit être protégée. Une machine virtuelle n’est pas autorisée à affecter le comportement du commutateur extensible Hyper-V dans un fournisseur de services virtuels (VSP) réseau. Par conséquent, le filtrage du réseau local virtuel (VLAN) doit se produire avant que la carte réseau utilise DMA pour transférer les données vers la mémoire partagée de la machine virtuelle. En outre, l’apprentissage de l’adresse de contrôle d’accès multimédia (MAC) du commutateur ne peut pas être affecté.

Si le port de commutateur extensible Hyper-V connecté à une machine virtuelle a un identificateur de réseau local virtuel associé, l’ordinateur hôte doit s’assurer que l’adresse MAC de destination et l’identificateur VLAN du frame entrant correspondent à ces attributs respectifs du port avant que l’hôte transfère le paquet à la carte réseau virtuelle de la machine virtuelle. Si l’identificateur de réseau local virtuel du frame ne correspond pas à l’identificateur de réseau local virtuel du port, le paquet est supprimé. Lorsque les mémoires tampons de réception d’une carte réseau virtuelle sont allouées à partir de la mémoire de l’hôte, l’hôte peut case activée l’identificateur de réseau local virtuel et supprimer l’image si nécessaire avant de rendre le contenu de la trame visible pour la machine virtuelle cible. Si le frame n’est pas copié dans l’espace d’adressage d’une machine virtuelle, cette machine virtuelle ne peut pas y accéder.

Toutefois, lorsque VMQ est configuré pour utiliser la mémoire partagée, la carte réseau utilise DMA pour transférer les trames entrantes directement vers l’espace d’adressage de la machine virtuelle. Ce transfert introduit un problème de sécurité dans lequel une machine virtuelle peut examiner le contenu des trames reçues sans attendre que le commutateur extensible applique le filtrage VLAN requis.

Comment Windows Server 2008 R2 résout le problème de sécurité

Dans Windows Server 2008 R2, avant que le VSP configure une file d’attente de machine virtuelle pour utiliser la mémoire partagée allouée à partir de l’espace d’adressage de la machine virtuelle, il utilise le test de filtrage suivant pour la file d’attente.

(MAC address == x) && (VLAN identifier == n)

Si le matériel de la carte réseau peut prendre en charge ce test avant le transfert DMA vers les mémoires tampons de réception, la carte réseau peut supprimer des trames avec des identificateurs VLAN non valides ou les envoyer à la file d’attente par défaut afin qu’elles puissent être filtrées par le commutateur extensible. Si le pilote miniport réussit dans une demande de définition d’un filtre avec ce test sur une file d’attente, le commutateur extensible peut utiliser la mémoire partagée de la machine virtuelle pour cette file d’attente. Toutefois, si le matériel de la carte réseau n’est pas en mesure de filtrer les trames en fonction de l’adresse MAC de destination et de l’identificateur de réseau local virtuel, le commutateur extensible utilise la mémoire partagée de l’hôte pour cette file d’attente.

Le commutateur extensible inspecte l’adresse MAC source des trames reçues afin de configurer les informations de routage pour les trames de transmission, c’est-à-dire qu’elle est similaire à un commutateur d’apprentissage physique. Il est possible d’installer des pilotes de filtre de pare-feu dans la pile hôte ; par exemple, au-dessus du pilote miniport pour le matériel de la carte réseau et sous le pilote de commutateur extensible. Les pilotes de filtre de pare-feu peuvent accéder aux données d’une trame reçue avant le commutateur extensible. Si l’intégralité de la mémoire tampon de réception pour chaque trame est allouée à partir de l’espace d’adressage de la machine virtuelle, une machine virtuelle malveillante peut accéder à des parties du frame qui seraient examinées par un pilote de filtre ou par le commutateur extensible qui s’exécute dans l’hôte.

Pour résoudre ce problème de sécurité, lors de l’utilisation de la mémoire partagée de machine virtuelle pour une file d’attente de machine virtuelle, la carte réseau doit fractionner le paquet à un décalage d’octets qui correspond au moins à la taille de la tête de regard, qui est une valeur fixe prédéterminée. Toutes les données de lookahead, c’est-à-dire les données qui sont en avance sur le décalage d’octets pour la taille de la tête de lookahead, doivent être transférées avec DMA vers la mémoire partagée qui a été allouée pour les données de lookahead. Les données post-lookahead( le reste de la charge utile du frame) doivent être transférées avec DMA vers la mémoire partagée qui a été allouée pour les données post-lookahead.

L’illustration suivante montre les relations pour les structures de données réseau lorsque les données entrantes sont fractionnées en mémoire tampons partagées post-lookahead et post-lookahead.

Diagramme illustrant des structures de paquets VMQ, montrant des données de lookahead et post-lookahead dans des mémoires tampons partagées distinctes.

Les exigences récapitulatives pour la mémoire partagée VMQ sont les suivantes :

  • Une carte réseau peut fractionner une trame reçue à une limite d’en-tête de réseau supérieure à la taille de la tête de lookahead. Toutefois, à la demande de NDIS, et sans exception, toutes les trames reçues et affectées à un vmQ doivent être fractionnées au-delà de la limite de taille de lookahead demandée par NDIS.

  • Les données de lookahead doivent être transférées avec DMA vers la mémoire partagée allouée par le pilote miniport. Le pilote miniport doit spécifier dans l’appel d’allocation que la mémoire sera utilisée pour les données de recherche.

  • Les données post-lookahead doivent être transférées avec DMA vers la mémoire partagée allouée par le pilote miniport. Le pilote miniport doit spécifier dans l’appel d’allocation que la mémoire sera utilisée pour les données post-lookahead.

  • Les pilotes Miniport ne doivent pas dépendre de l’espace d’adressage que NDIS utilisera pour effectuer la demande d’allocation de mémoire partagée. Autrement dit, l’espace d’adressage de mémoire partagée pour les données de lookahead ou post-lookahead est spécifique à l’implémentation. Dans de nombreux cas, NDIS ou le commutateur extensible peut satisfaire toutes les demandes, y compris celles destinées à une utilisation post-lookahead, provenant de l’espace d’adressage de la mémoire de l’hôte.

  • L’ordre dans lequel les images sont reçues sur une file d’attente de réception VMQ doit être conservé lorsque les images de cette file d’attente sont indiquées dans la pile des pilotes.

  • La carte réseau doit allouer suffisamment d’espace mémoire de remplissage dans chaque mémoire tampon post-lookahead. Cette allocation permet de copier les données de lookahead dans la partie de remplissage de la mémoire tampon post-lookahead, et permet de remettre le frame à la machine virtuelle dans une mémoire tampon contiguë.

S’il n’existe aucun mécanisme dans le matériel pour répondre à ces exigences pour la mémoire partagée VMQ, le matériel qui prend en charge la collecte de points DMA côté réception peut obtenir les mêmes résultats en allouant deux mémoires tampons de réception pour chaque trame reçue. Dans ce cas, la taille de la première mémoire tampon est limitée à la taille de lookahead demandée.

Si la carte réseau ne peut pas répondre à ces exigences pour la mémoire partagée VMQ par une méthode quelconque, le VSP alloue de la mémoire pour les mémoires tampons de réception VMQ à partir de l’espace d’adressage de l’hôte et copie les paquets reçus de la carte réseau dans l’espace d’adressage de la machine virtuelle.

Comment Windows Server 2012 et versions ultérieures résolvent le problème de sécurité

À compter de Windows Server 2012, le VSP n’alloue pas de mémoire partagée à partir de la machine virtuelle pour les mémoires tampons de réception vmQ. Au lieu de cela, le fournisseur de services virtuels alloue de la mémoire pour les mémoires tampons de réception vmQ à partir de l’espace d’adressage de l’hôte, puis copie les paquets reçus de la carte réseau dans l’espace d’adressage de la machine virtuelle.

Les points suivants s’appliquent aux pilotes miniport VMQ qui s’exécutent sur Windows Server 2012 et versions ultérieures de Windows :

  • Pour les pilotes NDIS 6.20 VMQ miniport, aucune modification n’est requise. Toutefois, lorsque le fournisseur de services virtuels alloue une file d’attente de machine virtuelle en émettant une demande de méthode OID (identificateur d’objet) de OID_RECEIVE_FILTER_ALLOCATE_QUEUE, il définit le membre LookaheadSize de la structure NDIS_RECEIVE_QUEUE_PARAMETERS sur zéro. Cela forcera un pilote miniport à ne pas fractionner le paquet en mémoires tampons pré-lookahead et post-lookahead.

  • À compter de NDIS 6.30, les pilotes miniport VMQ ne doivent pas annoncer la prise en charge de la division des données de paquets en mémoires tampons pré-lookahead et post-lookahead. Lorsqu’un pilote miniport inscrit ses fonctionnalités VMQ, il doit suivre ces règles lorsqu’il initialise la structure NDIS_RECEIVE_FILTER_CAPABILITIES :

    • Le pilote miniport ne doit pas définir l’indicateur NDIS_RECEIVE_FILTER_LOOKAHEAD_SPLIT_SUPPORTED dans le membre Flags .

    • Le pilote miniport doit définir les membres MinLookaheadSplitSize et MaxLookaheadSplitSize sur zéro.

    Pour plus d’informations sur l’inscription des fonctionnalités VMQ, consultez Détermination des fonctionnalités VMQ d’une carte réseau.