CVE-2018-19321

Os drivers de baixo nível GPCIDrv e GDrv, distribuídos com utilitários de motherboard e placa de vídeo da GIGABYTE (APP Center, AORUS GRAPHICS ENGINE, XTREME GAMING ENGINE, OC GURU II), expõem um IOCTL que permite a qualquer processo local — mesmo em baixa integridade, sem privilégio administrativo — ler e escrever memória física arbitrária. Isso equivale a uma primitiva de execução em kernel para qualquer usuário local, permitindo elevação direta a SYSTEM. É crítica porque o driver é assinado digitalmente pela Microsoft e frequentemente permanece instalado e carregado no boot mesmo após o usuário desinstalar o software da GIGABYTE, servindo como vetor clássico de BYOVD (bring-your-own-vulnerable-driver).

A falha é uma exposição de IOCTL com controle de acesso insuficiente (CWE-782): o driver cria um device object acessível por qualquer processo local (handle obtido via CreateFile em \\.\GIO ou \\.\GPCIDrv64 sem exigir privilégio elevado) e implementa, dentro do IOCTL dispatch routine, funcionalidade que copia dados entre um buffer controlado pelo usuário e memória física do sistema — sem validar se o chamador tem permissão para essa operação. Isso é distinto da falha irmã CVE-2018-19320, também presente nos mesmos drivers, que expõe um memcpy sobre memória virtual arbitrária via outro código de controle; a CVE-2018-19321 trata especificamente do acesso a memória física, o que na prática é ainda mais direto para um atacante, pois contorna qualquer mapeamento de página do processo alvo e dá acesso a estruturas do kernel independentemente do espaço de endereçamento virtual corrente.

O atacante controla o endereço físico de origem/destino e o tamanho da cópia enviados no buffer de entrada do IOCTL. Com essa primitiva de leitura/escrita arbitrária em ring 0, é possível localizar estruturas de token de processo, tabelas de páginas ou ponteiros de função no kernel e sobrescrevê-los para forjar um token SYSTEM, desabilitar mitigações (PatchGuard, callbacks de segurança) ou corromper estruturas de outros drivers carregados — inclusive soluções de EDR/AV.

O advisory original da SecureAuth Labs (CORE-2018-0007), que motivou a atribuição de CVE, agrupa quatro falhas distintas nos mesmos drivers (CVE-2018-19320, 19321, 19322, 19323), todas na mesma classe CWE-782. A descrição pública do NVD/vendor referencia AORUS GRAPHICS ENGINE 'antes de 1.57' e XTREME GAMING ENGINE 'antes de 1.26', enquanto o advisory original de dezembro de 2018 cita versões mais baixas (1.33 e 1.25, respectivamente) como o corte testado — indício de que o alcance de versões foi ampliado após a publicação inicial, provavelmente por análise adicional do fornecedor ou do NVD.

Exploração é estritamente local: o atacante precisa de capacidade de executar código no host (usuário de baixo privilégio já é suficiente, incluindo processos em baixa integridade), com o driver vulnerável instalado e carregado — pré-condição real, mas não incomum, já que os utilitários da GIGABYTE ficam residentes por padrão em motherboards e placas de vídeo dessa marca e o serviço/driver frequentemente continua ativo mesmo sem o software de gerenciamento aberto. Não há vetor remoto: AV:L no CVSS reflete exatamente essa limitação — não é uma falha explorável pela rede.

Na prática, o processo é: abrir um handle para o device object exposto pelo driver, montar a estrutura de entrada do IOCTL com endereço físico e tamanho desejados, e emitir a chamada via DeviceIoControl. A partir daí, o atacante tem uma primitiva de leitura/escrita em memória física que pode ser encadeada para elevação de privilégio completa (de usuário padrão a SYSTEM) ou para desabilitar controles de segurança do sistema. A PoC pública documentada no advisory da SecureAuth (para a falha irmã de memcpy sobre memória virtual, CVE-2018-19320) demonstra o padrão de chamada e resulta em BSOD controlado — evidência de que o driver aceita e executa a operação sem verificação de permissão, mesmo sem detalhar exploração de elevação completa.

O caso está no catálogo KEV da CISA (adicionado em outubro de 2022, quase quatro anos após a divulgação), o que confirma exploração confirmada em ambiente real — coerente com o padrão de abuso de drivers assinados vulneráveis (BYOVD) que ganhou popularidade em campanhas de ransomware e ferramentas de evasão de EDR, já que o driver da GIGABYTE, assinado pela Microsoft, oferece a um atacante já autenticado uma forma de rodar código arbitrário em kernel sem precisar de driver próprio não assinado.

O advisory original (dezembro de 2018) registra que o fornecedor não disponibilizou correção nem workaround até aquele momento. A CISA, ao incluir a CVE no catálogo KEV com prazo de 2022-11-14, orienta genericamente 'aplicar atualizações conforme instruções do fornecedor', remetendo ao aviso de segurança da GIGABYTE (gigabyte.com/Support/Security/1801) — não há, nas fontes analisadas aqui, uma versão específica de driver ou utilitário confirmada como corrigida; antes de considerar o ambiente seguro, é necessário conferir diretamente esse aviso do fornecedor para a versão exata do GPCIDrv/GDrv corrigida no seu modelo de placa.

O controle compensatório mais efetivo, quando a atualização não está disponível ou confirmada, é remover o software de gerenciamento da GIGABYTE (APP Center, AORUS GRAPHICS ENGINE, XTREME GAMING ENGINE, OC GURU II) e, principalmente, desinstalar/desabilitar os arquivos de driver GPCIDrv.sys/GDrv.sys residentes — desinstalar apenas o aplicativo em modo gráfico frequentemente não remove o driver do disco nem impede seu carregamento. Em ambientes corporativos, bloquear o carregamento desses drivers por hash/certificado via política de integridade de código (WDAC/Device Guard) ou listas de bloqueio de drivers vulneráveis é o paliativo mais realista quando o hardware exige o utilitário instalado.

Não funciona como mitigação apenas fechar o aplicativo da GIGABYTE em execução: o driver kernel pode permanecer carregado como serviço independentemente da GUI estar aberta, e o ataque não depende de nenhuma interação com a interface do usuário (UI:N no vetor CVSS).

Não há assinatura de rede: a exploração é inteiramente local, via IOCTL para um device object do kernel, sem tráfego de rede associado. Em endpoint, os sinais possíveis são: presença dos drivers GPCIDrv.sys/GDrv.sys (ou nomes de device \\.\GIO, \\.\GPCIDrv64) carregados no sistema mesmo sem o software GIGABYTE em execução; chamadas de CreateFile para esses device paths seguidas de DeviceIoControl vindas de processos não pertencentes ao ecossistema GIGABYTE (indicativo forte de abuso, já que aplicações legítimas raramente emitem essas chamadas fora do próprio utilitário); e, via monitoramento de carregamento de driver (ETW, EDR com visibilidade de kernel), o carregamento do driver vulnerável em hosts onde o hardware GIGABYTE correspondente não está presente — padrão típico de BYOVD. Sem instrumentação de kernel/EDR específica, não há forma confiável de detectar tentativas de exploração apenas por log padrão do Windows.