Um hacker do Google White Hat identificou uma nova categoria de bug no Windows

O hacker do Google Project, James Forshaw, descobriu uma nova categoria de vulnerabilidades em alguns dos drivers do modo kernel no Windows que podem permitir que invasores aumentem. Os defeitos devem-se à falta de verificações necessárias ao processar solicitações específicas.

janelas

O Windows usa os campos PreviousMode para configurar o UserMode ou KernelMode e, portanto, determina se os argumentos de chamada são provenientes de uma fonte confiável ou não confiável.

O mecanismo também é usado para criar e abrir arquivos, onde o código do modo do kernel pode ser selecionado em várias funções da API, incluindo algumas que levam à operação interna do IopCreateFile do I / O Manager.

Nesse caso, o PreviousMode é atribuído a uma variável específica para determinar se verificará parâmetros e buffer válidos.

O sistema operacional também usa a variável para verificar privilégios no objeto do dispositivo, se for UserMode. O parâmetro Options em IopCreateFile é exibido nas funções da API que só poderiam ser usadas pela função kernel para definir um sinalizador para ignorar o AccessMode e defini-lo como KernelMode.

“O IoCreateFile pode ser chamado apenas pelo código operacional do kernel e não há período de transição de syscall, portanto todas as chamadas usarão qualquer função anterior definida no encadeamento. Se IoCreateFile for chamado de um thread com um estado anterior definido no UserMode, isso significa que o SecAC e o MemAC serão executados. Lendo a análise do hacker de chapéu branco.

“A aplicação do MemAC é muito problemática, pois significa que o modo kernel não pode passar os indicadores principais para o IoCreateFilewhich, tornando a API muito difícil de usar. No entanto, a boa vontade do IoCreateFile não pode simplesmente mudar o estado anterior do thread no KernelMode, pois o SecAC será desativado. ”

Sob certas condições, isso significa que as verificações de acesso são forçadas a ocorrer, permitindo que os drivers no modo kernel abram um nome de objeto especificado por um aplicativo de função do usuário.

Forshaw explicou que alguns drivers enviados com o Windows executando no modo kernel não executaram todas as verificações de acesso ao lidar com solicitações específicas (IRP_MJ_CREATE). O código do modo kernel pode forçar verificações de acesso, abrindo a porta para atividades maliciosas.

“O tipo de operação executada e os parâmetros específicos da operação são transmitidos para a estrutura de localização da pilha de E / S imediatamente após a estrutura do IRP”, continua o especialista. “No caso de abrir um arquivo, o principal tipo de operação é IRP_MJ_CREATE e usa o campo Create union da estrutura IO_STACK_LOCATION.”

Um invasor que verifica os argumentos de um arquivo de criação / chamada aberta pode usar solicitações da função de usuário para destruir o problema e enviar uma solicitação IRP_MJ_CREATE com uma verificação definida no KernelMode, dessa maneira aumentar privilégios.

Para definir a classe de erro que leva ao aumento dos privilégios locais, são necessários os seguintes elementos separados.

  1. Um mecanismo operacional principal original (que chama IoCreateFile ou IoCreateFileEx) que define os sinalizadores INPC e IFAC, mas não define OFAC. Isso pode estar em um driver ou no próprio kernel.
  2. Um receptor vulnerável que usa RequestorMode ao executar IRP_MJ_CREATE para uma decisão de segurança, mas também não controla o Flag for SFAC.

“Um invasor deve ser capaz de direcionar o iniciador para abrir um objeto do dispositivo que está sendo manuseado pelo receptor. A verificação de segurança no receptor é ignorada porque Irp-> RequestorMode será KernelMode, mas o sinalizador SL_FORCE_ACCESS_CHECK não será considerado. “Leia a análise publicada pela Microsoft.”

“Em sua pesquisa, James encontrou momentos de protocolos e receptores, mas ninguém que, quando conectado, levaria imediatamente a uma escalada de privilégios. Optamos por trabalhar com ele para mais pesquisas e ver o que podemos encontrar juntos “.

A Microsoft corrigirá o erro em versões futuras do sistema operacional Windows e, enquanto isso, planeja implementar a maioria das atualizações de código no Windows 10 19H1.

Para resumir a pesquisa combinada de James e do MSRC, não parecia haver uma combinação de iniciador e receptor nas versões atuais suportadas do Windows que poderiam ser usadas para dimensionar os privilégios locais “prontos para uso”.

No entanto, optamos por tratá-los em versões futuras do Windows como uma medida de defesa profunda. A maioria dessas atualizações de código está em andamento para lançamento no Windows 10 19H1, com algumas sendo retidas para testes de compatibilidade adicionais e / ou porque o recurso existente está desativado por padrão ”, conclui a Microsoft.

“Existe o risco de drivers de terceiros ficarem vulneráveis ​​a essa vulnerabilidade, e instamos todos os desenvolvedores de drivers de kernel a revisar seu código para garantir que as solicitações de IRP sejam processadas corretamente e que as APIs sejam usadas abertamente”.