Freigeben über

Behandeln des Clientidentitätswechsels in UMDF-Treibern

  • Artikel

In diesem Thema wird beschrieben, wie ein UMDF-Treiber (User-Mode Driver Framework) ab UMDF-Version 2 auf geschützte Ressourcen zugreift.

UMDF-Treiber werden normalerweise unter dem LocalService-Konto ausgeführt und können nicht auf Dateien oder Ressourcen zugreifen, die Benutzeranmeldeinformationen erfordern, z. B. geschützte Dateien oder andere geschützte Ressourcen. Ein UMDF-Treiber funktioniert in der Regel für Befehle und Daten, die zwischen einer Clientanwendung und einem Gerät fließen. Daher greifen die meisten UMDF-Treiber nicht auf geschützte Ressourcen zu.

Einige Treiber erfordern jedoch möglicherweise Zugriff auf eine geschützte Ressource. Ein UMDF-Treiber kann beispielsweise Firmware aus einer Datei, die eine Clientanwendung bereitstellt, in ein Gerät laden. Die Datei kann über eine Zugriffssteuerungsliste (Access Control List, ACL) verfügen, die verhindert, dass nicht autorisierte Benutzer die Datei ändern und die Kontrolle über das Gerät übernehmen. Leider verhindert diese ACL auch den Zugriff des UMDF-Treibers auf die Datei.

Das Framework bietet eine Identitätswechselfunktion, die es Treibern ermöglicht, die Identität des Treiberclients zu imitieren und die Zugriffsrechte des Clients auf geschützte Ressourcen abzurufen.

Aktivieren des Identitätswechsels

Sowohl das Installationspaket des UMDF-Treibers als auch die Clientanwendung müssen die Identitätswechselfunktion des Frameworks wie folgt aktivieren:

  • Die INF-Datei des Installationspakets des UMDF-Treibers muss die UmdfImpersonationLevel-Direktive enthalten und die maximal zulässige Identitätswechselebene festlegen. Der Identitätswechsel ist nur aktiviert, wenn die INF-Datei die UmdfImpersonationLevel-Direktive enthält. Weitere Informationen zum Festlegen der Identitätswechselebene finden Sie unter Angeben von WDF-Direktiven in INF-Dateien.

  • Die Clientanwendung muss die zulässige Identitätswechselebene für jedes Dateihandle festlegen. Die Anwendung verwendet die QoS-Einstellungen (Quality of Service) in der Microsoft Win32 CreateFile-Funktion , um die zulässige Identitätswechselebene festzulegen. Weitere Informationen zu diesen Einstellungen finden Sie im DwFlagsAndAttributes-Parameter von CreateFile in der Windows SDK-Dokumentation.

Behandeln des Identitätswechsels für eine E/A-Anforderung

Der UMDF-Treiber und das Framework behandeln den Identitätswechsel für eine E/A-Anforderung in der folgenden Sequenz:

  1. Der Treiber ruft die WdfRequestImpersonate-Methode auf, um die erforderliche Identitätswechselebene und eine EvtRequestImpersonate-Rückruffunktion anzugeben.

  2. Das Framework überprüft die angeforderte Identitätswechselebene. Wenn die angeforderte Ebene größer als die Ebene ist, die das Installationspaket des UMDF-Treibers und die Clientanwendung zulassen, schlägt die Identitätswechselanforderung fehl. Andernfalls gibt das Framework die Identität des Clients an und ruft sofort die Rückruffunktion EvtRequestImpersonate auf .

Die Rückruffunktion EvtRequestImpersonate darf nur die Vorgänge ausführen, die die angeforderte Identitätswechselebene erfordern, z. B. das Öffnen einer geschützten Datei.

Das Framework erlaubt es der EvtRequestImpersonate-Rückruffunktion eines Treibers nicht, eine der Objektmethoden des Frameworks aufzurufen. Dadurch wird sichergestellt, dass der Treiber die Identitätswechselebene nicht für andere Treiberrückruffunktionen oder andere Treiber verfügbar macht.

Als bewährte Methode sollte Ihr Treiber das Abbrechen einer E/A-Anforderung vor dem Aufrufen von WdfRequestImpersonate für diese Anforderung nicht aktivieren.

Die WdfRequestImpersonate-Methode gewährt nur die Identitätswechselebene, die der Treiber anfordert.

Übergeben von Anmeldeinformationen im Treiberstapel

Wenn Ihr Treiber eine WdfRequestTypeCreate-typisierte E/A-Anforderung empfängt, leitet der Treiber die E/A-Anforderung möglicherweise im Treiberstapel an einen Kernelmodustreiber weiter. Kernelmodustreiber verfügen nicht über die Identitätswechselfunktion, die WdfRequestImpersonate für UMDF-Treiber bereitstellt.

Wenn sie also möchten, dass ein Kernelmodustreiber die Benutzeranmeldeinformationen des Clients (eher die Anmeldeinformationen des Treiberhostprozesses) empfängt, muss der Treiber das WDF_REQUEST_SEND_OPTION_IMPERSONATE_CLIENT-Flag festlegen, wenn er WdfRequestSend aufruft, um die Erstellungsanforderung an das E/A-Ziel zu senden. Die Send-Methode gibt einen Fehlercode zurück, wenn der Identitätswechselversuch fehlschlägt, es sei denn, der Treiber legt auch das WDF_REQUEST_SEND_OPTION_IMPERSONATION_IGNORE_FAILURE-Flag fest.

Das folgende Beispiel zeigt, wie ein UMDF-Treiber das WDF_REQUEST_SEND_OPTION_IMPERSONATE_CLIENT-Flag verwenden kann, um eine Dateierstellungsanforderung an ein E/A-Ziel zu senden. Die INF-Datei des Treibers muss auch die UmdfImpersonationLevel-Anweisung enthalten, wie oben beschrieben.

WDFIOTARGET iotarget;
WDF_REQUEST_SEND_OPTIONS options;
NTSTATUS status;
WDF_REQUEST_PARAMETERS params;
ULONG sendFlags;  
 
WDF_REQUEST_PARAMETERS_INIT(&params);
WdfRequestGetParameters(Request, &params);
   
sendFlags = WDF_REQUEST_SEND_OPTION_SYNCHRONOUS;
if (params.Type == WdfRequestTypeCreate) {
    sendFlags |= WDF_REQUEST_SEND_OPTION_IMPERSONATE_CLIENT;
}
   
WDF_REQUEST_SEND_OPTIONS_INIT(&options, sendFlags);
if (WdfRequestSend(Request,
                   iotarget,
                   &options
                   ) == FALSE) {
    status = WdfRequestGetStatus(Request);
}

Der Treiber muss WdfRequestImpersonate nicht aufrufen, bevor er die Anforderung an das E/A-Ziel sendet.

Wenn Treiber der unteren Ebene auch die Anforderung weiterleiten, wird die Identitätswechselebene des Clients den Treiberstapel hinuntergestreift.

Reduzieren von Sicherheitsbedrohungen

Um die Wahrscheinlichkeit eines Angriffs auf Rechteerweiterungen zu verringern, sollten Sie Folgendes ausführen:

  • Versuchen Sie, den Identitätswechsel zu vermeiden.

    Um beispielsweise den Identitätswechsel zum Öffnen einer Datei zu vermeiden, die der Treiber verwenden muss, kann die Clientanwendung die Datei öffnen und E/A-Vorgänge verwenden, um Dateiinhalte an den Treiber zu senden.

  • Verwenden Sie die niedrigste Identitätswechselebene, die Ihr Treiber erfordert.

    Legen Sie die Identitätswechselebene in der INF-Datei Ihres Treibers so niedrig wie möglich fest. Wenn Ihr Treiber keinen Identitätswechsel erfordert, schließen Sie die UmdfImpersonationLevel-Direktive nicht in die INF-Datei ein.

  • Minimieren Sie die Möglichkeiten eines Angreifers, Ihren Treiber auszunutzen.

    Ihre EvtRequestImpersonate-Rückruffunktion sollte einen kleinen Codeabschnitt enthalten, der nur den Vorgang ausführt, der einen Identitätswechsel erfordert. Wenn Ihr Treiber beispielsweise auf eine geschützte Datei zugreift, ist ein Identitätswechsel nur erforderlich, wenn das Dateihandle geöffnet wird. Es ist kein Identitätswechsel erforderlich, um aus der Datei zu lesen oder in diese zu schreiben.