CVE-2021-21551

Vulnerabilidade de controle de acesso insuficiente no driver dbutil_2_3.sys, distribuído junto com dezenas de utilitários de firmware da Dell (BIOS, Thunderbolt, TPM, docks) e com ferramentas como Dell Command Update e SupportAssist. Um usuário local autenticado, sem privilégios administrativos, consegue escalar para SYSTEM, causar negação de serviço ou ler memória do kernel. Importa porque o driver ficava presente e carregável em centenas de milhões de máquinas Windows mesmo depois de o utilitário de firmware já ter sido executado e encerrado.

O driver expõe um conjunto de IOCTLs (CWE-782 — IOCTL exposto com controle de acesso insuficiente) que qualquer processo em nível de usuário consegue acionar após abrir um handle para o dispositivo, sem verificação adicional de privilégio do chamador. As análises públicas (PacketStorm) descrevem handlers de IOCTL que permitem leitura e escrita arbitrária de memória — inclusive memória física/kernel — a partir do espaço de usuário.

O problema não está na lógica de atualização de firmware em si (a Dell é explícita: 'o firmware em si não é afetado'), mas no driver auxiliar que serve de ponte entre o utilitário em modo usuário e operações privilegiadas em modo kernel. Como o driver não valida se o chamador tem direito de realizar aquela operação de memória, qualquer processo com handle aberto para \\.\DBUtil_2_3 herda, na prática, capacidade de leitura/escrita em contexto de kernel.

O vetor CVSS (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) reflete exatamente isso: ataque local, complexidade baixa, privilégio baixo necessário, sem interação do usuário, mudança de escopo de segurança (S:C) porque o impacto ultrapassa o contexto do processo que aciona a falha e afeta o kernel inteiro — daí o C/I/A todos altos.

Pré-requisito real: acesso local autenticado (mesmo com privilégios baixos) a uma máquina Windows onde o driver dbutil_2_3.sys esteja presente e carregável. Isso descarta exploração remota pura — não há vetor de rede — mas cobre um universo enorme de máquinas, porque o driver era instalado (e muitas vezes deixado no disco) por praticamente qualquer utilitário Dell de atualização de firmware ou de notificação de updates, mesmo em máquinas que nunca tiveram uma atualização de firmware efetivamente aplicada.

Com o driver presente, o atacante abre um handle para o dispositivo e envia IOCTLs que dão leitura/escrita arbitrária em memória kernel, usado tipicamente para elevar um token de processo a SYSTEM, desabilitar mitigações de kernel ou provocar crash (DoS) manipulando estruturas do kernel. Há PoC pública e módulo Metasploit, o que reduz a complexidade de exploração a praticamente zero para quem já tem execução de código local — é o padrão clássico de abuso de "driver vulnerável assinado" usado também para BYOVD (bring-your-own-vulnerable-driver) em cadeias de ataque mais amplas, inclusive para desativar EDR/AV a partir de um processo com poucos privilégios.

Está no catálogo KEV da CISA (adicionado em 2022-03-31, prazo de correção 2022-04-21), confirmando exploração no mundo real, embora a CISA não classifique a falha como associada a campanhas de ransomware conhecidas ("Unknown").

A Dell orienta um processo de três passos, não apenas 'atualizar': (1) identificar se a plataforma teve algum pacote de firmware/utilitário Dell impactado instalado (BIOS, Thunderbolt, TPM, dock, Dell Command Update, Dell Update, Alienware Update, SupportAssist, Dell System Inventory Agent, Dell Platform Tags, Dell BIOS Flash Utility); (2) remover o driver vulnerável do sistema; (3) obter uma versão remediada do driver através dos pacotes de utilitário atualizados listados nas tabelas de produtos afetados do próprio advisory da Dell (a lista de números de versão por plataforma está nessas tabelas, não no texto geral do advisório — não há um único número de versão de driver que sirva para todos os casos).

A Dell alerta para um ponto que costuma ser ignorado: mesmo com a versão remediada instalada, um usuário com acesso administrativo pode reinstalar o driver vulnerável manualmente (ex.: baixando um instalador antigo). Por isso a mitigação real e duradoura passa por bloquear o carregamento do driver vulnerável via regras de bloqueio de driver recomendadas pela Microsoft, além de remover cópias órfãs do arquivo do disco.

O que não funciona como mitigação: assumir que 'nunca instalei uma atualização de firmware Dell' resolve — o driver era empacotado até em ferramentas de notificação que não chegam a aplicar firmware nenhum. Também não basta desinstalar o utilitário de firmware; o arquivo .sys pode permanecer no sistema e continuar carregável mesmo sem o utilitário que o instalou.

Monitorar carregamento de driver (ex.: Sysmon Event ID 6 / Driver Loaded) com nome de arquivo dbutil_2_3.sys ou hash correspondente às versões vulneráveis conhecidas publicamente; a simples presença do arquivo em disco, mesmo sem o utilitário Dell que o instalou, já é indicador de exposição. Em nível de comportamento, é possível monitorar processos não administrativos abrindo handles para o dispositivo \\.\DBUtil_2_3 e emitindo IOCTLs — mas isso exige instrumentação de EDR específica, já que não há assinatura de rede (a falha é puramente local) nem log nativo do Windows que registre chamadas de IOCTL por padrão.