Falha em validar manipuladores de objeto

Alguns drivers devem manipular objetos passados a eles por chamadores ou devem manipular dois objetos de arquivo ao mesmo tempo. Por exemplo, um driver de modem pode receber um identificador para um objeto de evento ou um driver de rede pode receber identificadores para dois objetos de arquivo diferentes. O condutor deve validar estas pegas. Como eles são passados por um chamador, e não pelo gerenciador de E/S, o gerente de E/S não pode executar nenhuma verificação de validação.

Por exemplo, no trecho de código a seguir, o driver recebeu o identificador AscInfo-AddressHandle>, mas não o validou antes de chamar 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) ) {

Embora a chamada para ObReferenceObjectByHandle seja bem-sucedida, o código falha ao garantir que o ponteiro retornado faça referência a um objeto de arquivo; Ele confia no chamador para passar as informações corretas.

Mesmo se todos os parâmetros para a chamada para ObReferenceObjectByHandle estiverem corretos e a chamada for bem-sucedida, um driver ainda pode obter resultados inesperados se o objeto de arquivo não for destinado ao seu driver. No fragmento de código a seguir, o driver assume que uma chamada bem-sucedida retorna um ponteiro para o objeto de arquivo esperado:

   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 ) 

Embora ObReferenceObjectByHandle retorne um ponteiro para um objeto de arquivo, o driver não tem garantia de que o ponteiro faça referência ao objeto de arquivo esperado. Nesse caso, o driver deve validar o ponteiro antes de acessar os dados específicos do driver em AcpEndpointFileObject-FsContext>.

Para evitar tais problemas, um motorista deve verificar se há dados válidos, da seguinte forma:

• Verifique o tipo de objeto para se certificar de que é o que o driver espera.

• Verifique se o acesso solicitado é apropriado para o tipo de objeto e as tarefas necessárias. Se o driver executar uma cópia rápida do arquivo, por exemplo, verifique se o manipulador tem acesso de leitura.

• Certifique-se de especificar o modo de acesso correto (UserMode ou KernelMode) e que o modo de acesso é compatível com o acesso solicitado.

• Se o driver espera um identificador para um objeto de arquivo que o próprio driver criou, valide o identificador em relação ao objeto de dispositivo ou driver. No entanto, tenha cuidado para não quebrar filtros que enviam solicitações de E/S para dispositivos estranhos.

• Se o driver oferecer suporte a vários tipos de objetos de arquivo (como canais de controle, objetos de endereço e conexões de drivers TDI ou objetos de volume, diretório e arquivo de sistemas de arquivos), verifique se você tem uma maneira de diferenciá-los.