Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Os testes de penetração de fundamentos do dispositivo executam várias formas de ataques de entrada, que são um componente crítico dos testes de segurança. Os testes de ataque e penetração podem ajudar a identificar vulnerabilidades nas interfaces de software.
Penetração
Os testes de penetração incluem duas categorias de testes: testes do Fuzz e testes de E/S Spy e ataque de E/S . Os testes do Fuzz também foram um recurso da ferramenta de teste Exceriser de Caminho do Dispositivo .
| Teste | Descrição |
|---|---|
Desabilitar o Espião de E/S |
Desativar Monitor de E/S em 1 ou mais dispositivos. Teste binário: Devfund_IOSpy_DisableSupport.wsc Método de teste: DisableIoSpy Parâmetros: - consulte Parâmetros do Teste de Fundamentos do Dispositivo DQ |
Exibir dispositivo com I/O Spy habilitado |
Exibir dispositivos que têm o Espião de E/S habilitado neles. Teste de binário: Devfund_IOSpy_DisplayEnabledDevices.wsc Método de teste: DisplayIoSpyDevices |
Habilitar o Espião de E/S |
Habilite o Espião de E/S em um ou mais dispositivos. Binário de teste: Devfund_IOSpy_EnableSupport.wsc Método de teste: EnableIoSpy Parâmetros: - consulte Parâmetros do Teste de Fundamentos do Dispositivo DQ DFD – especifica o caminho para o arquivo de dados IoSpy. O local padrão é %SystemDrive%\DriverTest\IoSpy |
Teste de API do Fuzz Misc |
Os testes de API do Fuzz Misc são testes que determinam se o driver pode lidar com uma variedade de chamadas comuns de drivers de modo kernel. Os testes incluem os seguintes testes:
Binário de teste: Devfund_DevicePathExerciser.dll Método de teste: DoMiscAPITest Parâmetros: - consulte Parâmetros do Teste de Fundamentos do Dispositivo DoPoolCheck DQ TestCycles AlterarFlagsDeProteçãoDoBuffer Personificar FillZeroPageWithNull |
API do Fuzz Misc com teste de consulta de comprimento zero |
Esse teste executa os mesmos testes que o teste de API do Fuzz Misc e, desta vez, passa uma consulta em branco (comprimento zero) e um endereço de buffer inválido para o driver ao tentar recuperar os atributos estendidos de um arquivo. Binário de teste: Devfund_DevicePathExerciser.dll Método de teste: DoMiscAPIWithZeroLengthTest Parâmetros: - consulte Parâmetros do Teste de Fundamentos do Dispositivo DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Personificar FillZeroPageWithNull |
Teste de abertura e fechamento do Fuzz |
Este teste executa milhares de sequências create-open-close. Para obter informações detalhadas sobre esse teste, consulte Sobre o teste de abertura e fechamento do Fuzz. Binário de teste: Devfund_DevicePathExerciser.dll Método de teste: DoOpenCloseTest Parâmetros: - consulte Parâmetros do Teste de Fundamentos do Dispositivo DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Personificar FillZeroPageWithNull |
Teste de Consulta Fuzz e Definir Informações de Arquivo |
Esse teste emite chamadas para recuperar e alterar as informações de objeto, arquivo e volume de dispositivos. Durante o Teste de Informações de Arquivo de Consulta e Definição, o teste Fuzz emite chamadas para recuperar e alterar as informações de objeto, arquivo e volume de dispositivos abertos pelas Operações Abertas Básicas e outras operações abertas, incluindo as operações executadas pelas Sub-aberturas do Fuzz. O teste Fuzz realiza cada consulta ou chamada de conjunto pelo menos 1024 vezes com um buffer válido e uma variedade de comprimentos de buffer e classes de informações de arquivo. Uma solicitação de cada tipo também é enviada com um ponteiro de buffer inválido e um comprimento de buffer igual a zero. Se você usar o parâmetro ChangeBufferProtectionFlags, que define a opção de proteção, o teste Fuzz varia a configuração de segurança no buffer em cada consulta e chamada de configuração. Esse teste também executa o teste de sub-abertura do Fuzz. Este teste usa as funções ZwQueryInformationFile, ZwSetInformationFile, ZwQueryVolumeInformationFile e ZwSetVolumeInformationFile . Binário de teste: Devfund_DevicePathExerciser.dll Método de teste: DoQueryAndSetFileInformationTest Parâmetros: - consulte Parâmetros do Teste de Fundamentos do Dispositivo DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Personificar FillZeroPageWithNull |
Teste de Consulta Fuzz e Configuração de Segurança |
Esse teste emite chamadas para recuperar o descritor de segurança e alterar o estado de segurança dos dispositivos. Durante o Teste de Consulta e Definição de Segurança, o teste Fuzz faz chamadas para recuperar o descritor de segurança e alterar o estado de segurança dos dispositivos abertos pelas Operações Básicas de Abertura e outras operações abertas, incluindo aquelas realizadas pelo teste de Sub-opens do Fuzz. o teste do Fuzz emite cada consulta ou defina a chamada pelo menos 1024 vezes com um buffer válido e uma variedade de tamanhos de buffer e tipos de informações de segurança (OWNER_SECURITY_INFORMATION, GROUP_SECURITY_INFORMATION, DACL_SECURITY_INFORMATION, SACL_SECURITY_INFORMATION e nenhum tipo de informação). Uma solicitação de cada tipo também é enviada com um ponteiro de buffer inválido e um comprimento de buffer igual a zero. Se você usar o parâmetro ChangeBufferProtectionFlags, que define a opção de proteção, o teste Fuzz varia a configuração de segurança no buffer em cada consulta e chamada de configuração. Binário de teste: Devfund_DevicePathExerciser.dll Método de teste: DoQueryAndSetSecurityTest Parâmetros: - consulte Parâmetros do Teste de Fundamentos do Dispositivo DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Personificar FillZeroPageWithNull |
Teste de Fuzz Aleatório FSCTL / Teste de Fuzz Aleatório IOCTL |
Esse teste emite uma série de chamadas para a função DeviceIoControl com códigos de função, tipos de dispositivo, métodos de transferência de dados e requisitos de acesso selecionados aleatoriamente de um intervalo de valores especificado. As chamadas incluem buffers de entrada e saída com ponteiros e comprimentos de buffer válidos e inválidos e conteúdo gerado aleatoriamente. Durante testes aleatórios, o teste do Fuzz emite uma série de chamadas para a função DeviceIoControl com códigos de função, tipos de dispositivo, métodos de transferência de dados e requisitos de acesso selecionados aleatoriamente de um intervalo de valores especificado. As chamadas incluem buffers de entrada e saída com ponteiros e comprimentos de buffer válidos e inválidos e conteúdo gerado aleatoriamente. O teste do Fuzz executa os testes aleatórios em todos os dispositivos abertos durante as Operações Abertas Básicas e testes abertos adicionais. Você pode personalizar esse teste usando os seguintes parâmetros:
A função que o teste do Fuzz usa para gerar números aleatórios para o teste usa um número de semente, um número inicial para o algoritmo de geração de número aleatório. Para reproduzir as condições de teste, use o parâmetro de número de semente para especificar o número de semente usado na avaliação de teste original. Um teste aleatório personalizado é incluído como parte do teste aleatório. O teste aleatório personalizado usa os resultados do teste aleatório para examinar a resposta dos drivers às solicitações IOCTL ou FSCTL com mais detalhes. O teste aleatório personalizado investiga as áreas que o teste aleatório perdeu e aquelas nas quais o driver não respondeu conforme o esperado com base no status retornado pelas chamadas de teste aleatórias. Binário de teste: Devfund_DevicePathExerciser.dll Métodos de teste: DoRandomIOCTLTest, DoRandomFSCTLTest Parâmetros: - consulte Parâmetros do Teste de Fundamentos do Dispositivo MinInBuffer MaxInBuffer MinOutBuffer MaxOutBuffer MaxRandomCalls MaxTailoredCalls SeedNumber MinDeviceType TipoDispositivoMáximo MinFunctionCode MaxFunctionCode DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Personificar FillZeroPageWithNull |
Teste de sub-abertura do Fuzz |
O teste executa uma série rápida de chamadas para abrir objetos no namespace do dispositivo. Nessas chamadas, ele passa por um caminho que começa com o dispositivo e inclui nomes arbitrários e cadeias de caracteres sem sentido de comprimento e conteúdo variados. Durante um teste aberto relativo, (também conhecido como um teste de sub-abertura), o teste do Fuzz tenta abrir objetos no namespace do dispositivo. Durante esse teste, o teste do Fuzz executa uma série rápida de chamadas para abrir objetos no namespace dos dispositivos abertos usando Operações Abertas Básicas e outras operações abertas. Nessas chamadas, o teste do Fuzz passa por um caminho que começa com o dispositivo e inclui nomes arbitrários e cadeias de caracteres sem sentido de comprimento e conteúdo variados. Este teste determina como o driver ou o sistema de arquivos gerencia solicitações abertas em seu namespace. Em particular, se o driver não der suporte a solicitações abertas em seu namespace, ele deverá impedir o acesso não autorizado, falhando nas solicitações ou definindo a característica do dispositivo FILE_DEVICE_SECURE_OPEN quando ele usa IoCreateDevice ou IoCreateDeviceSecure para criar o objeto do dispositivo. Para obter mais informações sobre o namespace de um dispositivo, consulte Controlando o acesso ao namespace do dispositivo. Binário de teste: Devfund_DevicePathExerciser.dll Método de teste: DoSubOpensTest Parâmetros: - consulte Parâmetros do Teste de Fundamentos do Dispositivo DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Personificar FillZeroPageWithNull |
Fuzz Sub-opens com testes de Streams |
Esse teste tenta abrir uma variedade de fluxos de dados nomeados no dispositivo. O teste usa uma série de nomes de fluxo arbitrários com conteúdo e caracteres que podem ser válidos para outros usos em alguns dispositivos. Durante o Teste de Fluxos, o teste do Fuzz tenta abrir uma variedade de fluxos de dados nomeados no dispositivo. Os testes usam uma série de nomes de fluxo arbitrários com conteúdo e caracteres que podem ser válidos para outros usos em alguns dispositivos. Este teste determina se o driver pode lidar corretamente com solicitações de fluxo de dados, especialmente se exportar um dispositivo que não dá suporte ou não antecipa fluxos de dados. Um fluxo de dados nomeado é um atributo de um objeto de arquivo. Para especificar um fluxo de dados nomeado, escreva o nome do arquivo, um dois-pontos e o nome do fluxo de dados. Por exemplo, "File01.txt:AccessDate", onde AccessDate é um fluxo de dados nomeado, ou seja, um atributo do arquivo File01.txt. O teste Fuzz registra os nomes dos fluxos usados no teste. Binário de teste: Devfund_DevicePathExerciser.dll Método de teste: DoSubOpensWithStreamsTest Parâmetros: - consulte Parâmetros do Teste de Fundamentos do Dispositivo DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Personificar FillZeroPageWithNull |
Teste do Buffer Fuzz Zero-Length FSCTL / Teste do Buffer Fuzz Zero-Length IOCTL |
Esse teste emite uma série de chamadas para a função DeviceIoControl com comprimentos de buffer de entrada e/ou saída de 0. O teste gera diferentes códigos de controle do sistema de arquivos usando diferentes códigos de função, tipos de dispositivo, métodos de transferência de dados e requisitos de acesso. Durante o Teste de Buffer Zero-Length, o teste Fuzz emite uma série de chamadas para a função DeviceIoControl com comprimentos de buffer de entrada e/ou saída de 0. O teste gera diferentes códigos de controle de E/S usando diferentes códigos de função, tipos de dispositivo, métodos de transferência de dados e requisitos de acesso. Para obter informações sobre o conteúdo dos códigos de controle de E/S, consulte Definindo códigos de controle de E/S. Para testar o tratamento do driver de ponteiros de buffer inválidos, os ponteiros de buffer nessas chamadas de modo de usuário especificam endereços altos no espaço de endereço virtual do kernel, como (0xFFFFFC00). O teste do Fuzz executa o teste de buffer de Zero-Length em todos os dispositivos abertos durante os testes abertos básicos e adicionais. Você pode personalizar esse teste usando os parâmetros de comando MinFunctionCode e MaxFunctionCode para especificar o intervalo de códigos de função IOCTL ou FSCTL usados nas chamadas e MinDeviceType e MaxDeviceType para especificar o intervalo de tipos de dispositivo usados nas chamadas. Binário de teste: Devfund_DevicePathExerciser.dll Métodos de teste: DoZeroLengthBufferIOCTLTest, DoZeroLengthBufferFSCTLTest Parâmetros: - consulte Parâmetros do Teste de Fundamentos do Dispositivo MinDeviceType TipoDispositivoMáximo MinFunctionCode MaxFunctionCode DoPoolCheck TestCycles ChangeBufferProtectionFlags Personificar FillZeroPageWithNull |
Executar ataque de E/S |
Executa o ataque de E/S no dispositivo ou dispositivos especificados. Teste de binário: Devfund_IOAttack_DeleteDataFile.wsc Método de teste: RunIoAttack Parâmetros: - consulte Parâmetros do Teste de Fundamentos do Dispositivo DQ |
Sobre o teste de abertura e fechamento do Fuzz
O teste aberto e fechado do Fuzz emprega várias maneiras diferentes de abrir e fechar instâncias do dispositivo ou dispositivos especificados: Operações Abertas Básicas, Operações Abertas Diretas de Dispositivo e um teste Abrir e Fechar.
Operações abertas básicas
Durante as Operações Abertas Básicas, o teste do Fuzz abre repetidamente (cria) instâncias dos dispositivos especificados ou dos dispositivos exportados pelo driver especificado usando diferentes métodos e opções.
O teste do Fuzz sempre executa as Operações Abertas Básicas. Você não precisa selecioná-los e não pode excluí-los de uma sessão de teste.
O teste do Fuzz executa todas as operações abertas no modo de usuário chamando serviços do sistema (Rotinas ZwXxx) que são apropriados para o dispositivo. Se uma chamada aberta retornar um identificador para o dispositivo, o teste do Fuzz usará o identificador para executar os outros testes de dispositivo selecionados para a sessão de teste.
Há cinco tipos de Operações Abertas Básicas:
Abertura padrão O teste do Fuzz abre o dispositivo de forma assíncrona e especifica apenas o nome do dispositivo nativo.
Abra com barra invertida adicionada. o teste Fuzz emite uma chamada aberta para o nome do dispositivo seguido por uma barra invertida (\), como \device\cdrom\, como se a chamada estivesse abrindo um diretório raiz dentro do dispositivo.
Esta operação determina como o sistema de arquivos ou driver gerencia solicitações abertas em seu namespace. Em particular, se o dispositivo não der suporte a solicitações abertas em seu namespace, o driver deverá impedir o acesso não autorizado, seja falhando nas solicitações ou definindo a característica do dispositivo FILE_DEVICE_SECURE_OPEN quando ele chama IoCreateDevice ou IoCreateDeviceSecure para criar o objeto do dispositivo.
Abra como um pipe nomeado. o teste Fuzz abre o dispositivo e estabelece uma tubulação nomeada para o dispositivo. O parâmetro de acesso (ShareAccess) é inicialmente definido para leitura e gravação, mas é ajustado se a solicitação falhar. Se o dispositivo não der suporte a pipes nomeados, a solicitação deverá falhar.
Abra como um mailslot. o teste de fuzz abre o dispositivo como um mailslot. Se o dispositivo não der suporte a esse tipo de conexão, ele deverá falhar na solicitação.
Abrir como uma conexão de árvore. o teste Fuzz abre o dispositivo como uma conexão em árvore para uso no acesso remoto à rede. O parâmetro de acesso (ShareAccess) é inicialmente definido para leitura e gravação, mas é ajustado se a solicitação falhar. Se o dispositivo não der suporte a esse tipo de conexão, ele deverá falhar na solicitação.
Os parâmetros usados nas chamadas abertas variam para acomodar as características do dispositivo e tornar provável que as chamadas sejam bem-sucedidas. Por exemplo, se uma operação aberta básica falhar porque a chamada não atendeu aos requisitos de segurança do dispositivo, o teste do Fuzz repetirá a operação aberta com uma solicitação de acesso menor. Por exemplo, se uma operação de abertura que solicitou acesso de gravação resultar em um erro de violação de segurança, a operação de abertura será repetida com uma solicitação de acesso de leitura.
Operações de abertura de dispositivo direto
Durante as Operações Abertas de Dispositivo Direto, o teste de Fuzz abre o dispositivo diretamente como um dispositivo, e não como um arquivo em um sistema de arquivos. As operações de abertura de dispositivo direto são sempre síncronas. Se a chamada for bem-sucedida, o teste Fuzz usará o identificador fornecido para executar outros testes selecionados.
Teste de Abertura e Fechamento
Durante o Teste de Abrir e Fechar, o teste Fuzz cria vários fluxos, em que cada um executa milhares de sequências de criação-abertura-fechamento. Isso testa a capacidade do driver de lidar com um volume extraordinário de chamadas que, de outra forma, seriam simples e antecipadas.
O Teste Abrir e Fechar usa as mesmas opções em Operações Abertas Básicas e no teste Abrir com Barra Invertida Adicionada e é executado imediatamente antes desses testes.
Tópicos relacionados
Como testar um driver em runtime usando o Visual Studio
Como selecionar e configurar os testes de Fundamentos do Dispositivo
Testes de fundamentos do dispositivo
Plug-ins simples de E/S fornecidos pelo WDTF
Como testar um driver em tempo de execução em um prompt de comando