Échec de la validation des handles d’objet

Certains pilotes doivent manipuler les objets qui leur sont transmis par les appelants ou doivent gérer deux objets de fichier en même temps. Par exemple, un pilote de modem peut recevoir un handle pour un objet d’événement, ou un pilote réseau peut recevoir des handles pour deux objets de fichier différents. Le pilote doit valider ces handles. Étant donné qu’elles sont transmises par un appelant et non par le biais du gestionnaire d’E/S, le gestionnaire d’E/S ne peut pas effectuer de vérification de validation.

Par exemple, dans l’extrait de code suivant, le pilote a reçu le handle AscInfo-AddressHandle>, mais ne l’a pas validé avant d’appeler ObReferenceObjectByHandle :

   //
   // This handle is embedded in a buffered request.
   //
   status = ObReferenceObjectByHandle(
                      AscInfo->AddressHandle,
                      0,
                      NULL,
                      KernelMode,
                      &fileObject,
                      NULL);

   if (NT_SUCCESS(status)) {
       if ( (fileObject->DeviceObject == DeviceObject) &&
            (fileObject->FsContext2 == TRANSPORT_SOCK) ) {

Bien que l’appel à ObReferenceObjectByHandle réussisse, le code ne parvient pas à garantir que le pointeur retourné fait référence à un objet de fichier ; il fait confiance à l’appelant pour transmettre les informations correctes.

Même si tous les paramètres de l’appel à ObReferenceObjectByHandle sont corrects et que l’appel réussit, un pilote peut toujours obtenir des résultats inattendus si l’objet fichier n’est pas destiné à son pilote. Dans le fragment de code suivant, le pilote suppose qu’un appel réussi retourne un pointeur vers l’objet de fichier qu’il attendait :

   status = ObReferenceObjectByHandle (
                             AcpInfo->Handle,
                             0L,
                             DesiredAccess,
                             *IoFileObjectType,
                             Irp->RequestorMode,
                             (PVOID *)&AcpEndpointFileObject,
                             NULL);

   if ( !NT_SUCCESS(status) ) {
      goto complete;
   }
   AcpEndpoint = AcpEndpointFileObject->FsContext;

   if ( AcpEndpoint->Type != BlockTypeEndpoint ) 

Bien qu’ObReferenceObjectByHandle retourne un pointeur vers un objet fichier, le pilote n’a aucune garantie que le pointeur référence l’objet de fichier attendu. Dans ce cas, le pilote doit valider le pointeur avant d’accéder aux données spécifiques au pilote sur AcpEndpointFileObject-FsContext>.

Pour éviter de tels problèmes, un pilote doit case activée pour les données valides, comme suit :

• Vérifiez le type d’objet pour vous assurer qu’il correspond à ce que le pilote attend.

• Vérifiez que l’accès demandé est approprié pour le type d’objet et les tâches requises. Si votre pilote effectue une copie de fichier rapide, pour instance, assurez-vous que le handle dispose d’un accès en lecture.

• Veillez à spécifier le mode d’accès correct (UserMode ou KernelMode) et que le mode d’accès est compatible avec l’accès demandé.

• Si le pilote attend un handle pour un objet de fichier que le pilote lui-même a créé, validez le handle par rapport à l’objet d’appareil ou au pilote. Toutefois, veillez à ne pas interrompre les filtres qui envoient des demandes d’E/S pour des appareils étranges.

• Si votre pilote prend en charge plusieurs types d’objets de fichiers (tels que les canaux de contrôle, les objets d’adresse et les connexions des pilotes TDI ou les objets Volume, Répertoire et Fichier des systèmes de fichiers), vérifiez que vous disposez d’un moyen de les différencier.