Sicherheitsprobleme mit NDIS Virtual Machine (VM) Shared Memory
In diesem Thema werden die potenziellen Sicherheitsprobleme erläutert, die mit der Zuweisung von freigegebenem Arbeitsspeicher von einem virtuellen Computer (VM) für VM-Empfangspuffer (VMQ) verbunden sind. Das Thema enthält die folgenden Abschnitte:
Übersicht über die Sicherheitsprobleme mit freigegebenem VM-Arbeitsspeicher
Beheben des Sicherheitsproblems durch Windows Server 2012 und höhere Versionen
Hinweis In Hyper-V wird eine untergeordnete Partition auch als VM bezeichnet.
Übersicht über die Sicherheitsprobleme mit freigegebenem VM-Arbeitsspeicher
VMs sind keine vertrauenswürdigen Softwareentitäten. Das heißt, eine böswillige VM darf nicht in der Lage sein, andere VMs oder das Verwaltungsbetriebssystem zu beeinträchtigen, das in der übergeordneten Hyper-V-Partition ausgeführt wird. Dieser Abschnitt enthält Hintergrundinformationen und Anforderungen, um sicherzustellen, dass Treiberautoren vmQ-Sicherheitsprobleme und -anforderungen für gemeinsam genutzten Arbeitsspeicher verstehen. Weitere Informationen zum freigegebenen Arbeitsspeicher finden Sie im Abschnitt Schreiben von VMQ-Treibern im Thema Ressourcenzuweisung für gemeinsam genutzten Arbeitsspeicher.
In der virtualisierten Umgebung kann der freigegebene VM-Arbeitsspeicher von der VM angezeigt oder geändert werden. Das Anzeigen oder Ändern von Daten, die anderen VMs zugeordnet sind, ist jedoch nicht zulässig. VMs dürfen auch nicht auf den Verwaltungsadressraum zugreifen.
Der Headerteil der empfangenen Pakete muss geschützt werden. Eine VM darf sich nicht auf das Verhalten des erweiterbaren Hyper-V-Switches in einem virtuellen Netzwerkdienstanbieter (VSP) auswirken. Daher muss die VLAN-Filterung (Virtual LAN) erfolgen, bevor der Netzwerkadapter DMA verwendet, um die Daten in den freigegebenen VM-Arbeitsspeicher zu übertragen. Außerdem kann die Mac-Adressverwaltung (Media Access Control) nicht beeinträchtigt werden.
Wenn der erweiterbare Hyper-V-Switchport, der mit einer VM verbunden ist, über einen zugeordneten VLAN-Bezeichner verfügt, muss der Hostcomputer sicherstellen, dass die MAC-Zieladresse und der VLAN-Bezeichner des eingehenden Frames mit den entsprechenden Attributen des Ports übereinstimmen, bevor der Host das Paket an den virtuellen Netzwerkadapter des virtuellen Computers weiterleitet. Wenn der VLAN-Bezeichner des Frames nicht mit dem VLAN-Bezeichner des Ports übereinstimmt, wird das Paket gelöscht. Wenn die Empfangspuffer für einen virtuellen Netzwerkadapter aus dem Hostspeicher zugeordnet werden, kann der Host den VLAN-Bezeichner überprüfen und den Frame bei Bedarf löschen, bevor er den Inhalt des Frames für die Ziel-VM sichtbar macht. Wenn der Frame nicht in den Adressraum einer VM kopiert wird, kann von diesem virtuellen Computer nicht darauf zugegriffen werden.
Wenn VMQ jedoch für die Verwendung von freigegebenem Arbeitsspeicher konfiguriert ist, verwendet der Netzwerkadapter DMA, um eingehende Frames direkt an den VM-Adressraum zu übertragen. Diese Übertragung führt zu einem Sicherheitsproblem, bei dem ein virtueller Computer den Inhalt der empfangenen Frames untersuchen kann, ohne auf den erweiterbaren Switch zu warten, um die erforderliche VLAN-Filterung anzuwenden.
Wie Windows Server 2008 R2 das Sicherheitsproblem behebt
In Windows Server 2008 R2 wird der folgende Filtertest für die Warteschlange des virtuellen Computers für die Verwendung des freigegebenen Arbeitsspeichers konfiguriert, der aus dem Adressraum des virtuellen Computers zugewiesen wird.
(MAC address == x) && (VLAN identifier == n)
Wenn die Netzwerkadapterhardware diesen Test vor der DMA-Übertragung an die Empfangspuffer unterstützen kann, kann der Netzwerkadapter Entweder Frames mit ungültigen VLAN-Bezeichnern löschen oder sie an die Standardwarteschlange senden, sodass sie vom erweiterbaren Switch herausgefiltert werden können. Wenn dem Miniporttreiber eine Anforderung zum Festlegen eines Filters mit diesem Test für eine Warteschlange erfolgreich ist, kann der erweiterbare Switch freigegebenen VM-Arbeitsspeicher für diese Warteschlange verwenden. Wenn die Netzwerkadapterhardware jedoch nicht in der Lage ist, die Frames basierend auf der MAC-Zieladresse und dem VLAN-Bezeichner zu filtern, verwendet der erweiterbare Switch den freigegebenen Hostspeicher für diese Warteschlange.
Der erweiterbare Switch überprüft die Quell-MAC-Adresse empfangener Frames, um die Routinginformationen für Sendeframes zu konfigurieren– das heißt, er ähnelt einem Physische Learning-Switch. Es ist möglich, Firewallfiltertreiber im Hoststapel zu installieren. beispielsweise oberhalb des Miniporttreibers für die Netzwerkadapterhardware und unterhalb des erweiterbaren Switchtreibers. Firewallfiltertreiber können vor dem erweiterbaren Switch auf Daten in einem empfangenen Frame zugreifen. Wenn der gesamte Empfangspuffer für jeden Frame aus dem VM-Adressraum zugewiesen wird, könnte eine böswillige VM auf Teile des Frames zugreifen, die entweder von einem Filtertreiber oder dem erweiterbaren Switch, der auf dem Host ausgeführt wird, untersucht würden.
Um dieses Sicherheitsproblem zu beheben, muss der Netzwerkadapter das Paket bei Verwendung des freigegebenen VM-Arbeitsspeichers für eine VM-Warteschlange mit einem Byteoffset teilen, der mindestens der Lookaheadgröße entspricht. Dies ist ein vordefinierter fester Wert. Alle Lookaheaddaten – d. h. Daten, die dem Byteoffset für die Lookaheadgröße voraus sind – müssen mit DMA in den freigegebenen Arbeitsspeicher übertragen werden, der für Lookahead-Daten zugewiesen wurde. Die Post-Lookahead-Daten – der Rest der Framenutzlast – sollten mit DMA in den freigegebenen Arbeitsspeicher übertragen werden, der für die Daten nach dem Lookahead zugewiesen wurde.
Die folgende Abbildung zeigt die Beziehungen für die Netzwerkdatenstrukturen, wenn die eingehenden Daten in Lookahead- und Post-Lookahead-Shared Memory-Puffer aufgeteilt werden.
Die Zusammenfassungsanforderungen für den freigegebenen VMQ-Arbeitsspeicher sind wie folgt:
Ein Netzwerkadapter kann einen empfangenen Frame an einer Netzwerkheadergrenze teilen, die größer als die Lookaheadgröße ist. Bei Anforderung durch NDIS müssen jedoch ausnahmslos alle Frames, die empfangen und einem VMQ zugewiesen werden, mit oder über die von NDIS angeforderte Lookahead-Größengrenze aufgeteilt werden.
Die Lookaheaddaten müssen mit DMA in den freigegebenen Arbeitsspeicher übertragen werden, der vom Miniporttreiber zugewiesen wird. Der Miniporttreiber muss im Zuordnungsaufruf angeben, dass der Arbeitsspeicher für Lookahead-Daten verwendet wird.
Die Post-Lookahead-Daten müssen mit DMA in den freigegebenen Speicher übertragen werden, der vom Miniporttreiber zugeordnet wird. Der Miniporttreiber muss im Zuordnungsaufruf angeben, dass der Speicher für Post-Lookahead-Daten verwendet wird.
Miniporttreiber dürfen nicht davon abhängig sein, welcher Adressraum NDIS zum Abschließen der Anforderung zur Freigabespeicherzuweisung verwendet. Das heißt, der Shared Memory-Adressraum für Lookahead- oder Post-Lookahead-Daten ist implementierungsspezifisch. In vielen Fällen kann NDIS oder der erweiterbare Switch alle Anforderungen erfüllen, einschließlich der Anforderungen für die Verwendung nach dem Lookahead, aus dem Hostspeicheradressraum.
Die Reihenfolge, in der Frames in einer VMQ-Empfangswarteschlange empfangen werden, muss beibehalten werden, wenn die Frames in dieser Warteschlange im Treiberstapel angezeigt werden.
Der Netzwerkadapter muss in jedem Nachschlagepuffer genügend Speicherplatz auffüllen. Durch diese Zuordnung können die Lookaheaddaten in den Nachfüllbereich des Puffers nach dem Lookahead kopiert werden, und der Frame kann in einem zusammenhängenden Puffer an den virtuellen Computer übermittelt werden.
Wenn es keinen Mechanismus in der Hardware gibt, um diese Anforderungen für den freigegebenen VMQ-Arbeitsspeicher zu erfüllen, kann die Hardware, die scatter-gather-DMA auf der Empfangsseite unterstützt, die gleichen Ergebnisse erzielen, indem zwei Empfangspuffer für jeden empfangenen Frame zugewiesen werden. In diesem Fall ist die Größe des ersten Puffers auf die angeforderte Lookaheadgröße beschränkt.
Wenn der Netzwerkadapter diese Anforderungen für den freigegebenen VMQ-Arbeitsspeicher mit einer beliebigen Methode nicht erfüllen kann, ordnet der VSP Arbeitsspeicher für die VMQ-Empfangspuffer aus dem Hostadressraum zu und kopiert die empfangenen Pakete vom Netzwerkadapter empfängt Puffer in den VM-Adressraum.
Beheben des Sicherheitsproblems durch Windows Server 2012 und höhere Versionen
Ab Windows Server 2012 weist der VSP keinen freigegebenen Arbeitsspeicher von der VM für die VMQ-Empfangspuffer zu. Stattdessen weist der VSP Arbeitsspeicher für den VMQ-Empfangspuffer aus dem Hostadressraum zu und kopiert dann die empfangenen Pakete aus dem Netzwerkadapter-Empfangspuffer in den VM-Adressraum.
Die folgenden Punkte gelten für VMQ-Miniporttreiber, die unter Windows Server 2012 und höheren Versionen von Windows ausgeführt werden:
Für NDIS 6.20 VMQ-Miniporttreiber ist keine Änderung erforderlich. Wenn der VSP jedoch eine VM-Warteschlange ordnet, indem er eine OID-Methode (Objektbezeichner)-Methodenanforderung von OID_RECEIVE_FILTER_ALLOCATE_QUEUE ausgibt, legt er das LookaheadSize-Element der NDIS_RECEIVE_QUEUE_PARAMETERS-Struktur auf 0 fest. Dadurch wird erzwungen, dass ein Miniporttreiber das Paket nicht in Pre-Lookahead- und Post-Lookahead-Puffer aufteilt.
Ab NDIS 6.30 dürfen VMQ-Miniporttreiber keine Unterstützung für das Aufteilen von Paketdaten in Pre-Lookahead- und Post-Lookahead-Puffer ankündigen. Wenn ein Miniporttreiber seine VMQ-Funktionen registriert, muss er die folgenden Regeln befolgen, wenn er die NDIS_RECEIVE_FILTER_CAPABILITIES-Struktur initialisiert:
Der Miniporttreiber darf das NDIS_RECEIVE_FILTER_LOOKAHEAD_SPLIT_SUPPORTED-Flag im Flags-Element nicht festlegen.
Der Miniporttreiber muss die Elemente MinLookaheadSplitSize und MaxLookaheadSplitSize auf 0 festlegen.
Weitere Informationen zum Registrieren von VMQ-Funktionen finden Sie unter Bestimmen der VMQ-Funktionen eines Netzwerkadapters.