CVE-2018-19320

O driver kernel GDrv (\\.\GIO), distribuído junto com utilitários GIGABYTE/AORUS para controle de placas-mãe e placas de vídeo (fan curves, LEDs, overclock), expõe um IOCTL que funciona como um memcpy arbitrário em ring0. Qualquer processo local sem privilégios pode abrir um handle para o driver e ler/escrever em qualquer endereço de memória do kernel, escalando de usuário comum para SYSTEM/kernel. É CVE de acesso local, mas está no catálogo KEV da CISA por exploração confirmada, o que a torna relevante em cenários de escalada de privilégio pós-comprometimento inicial (malware, ransomware, red team) mais do que como vetor remoto.

A falha é uma exposição de IOCTL com controle de acesso insuficiente (CWE-782). O driver GIO (parte do conjunto GPCIDrv/GDrv usado por GIGABYTE APP Center, AORUS GRAPHICS ENGINE, XTREME GAMING ENGINE e OC GURU II) cria um device object acessível por qualquer processo, inclusive em integridade baixa, sem exigir privilégio administrativo para obter o HANDLE via CreateFile em \\.\GIO.

O IOCTL 0xC3502808 implementa uma função equivalente a memcpy que recebe uma estrutura com três campos — endereço de destino (ULONG64 dest), endereço de origem (ULONG64 src) e tamanho (DWORD size) — e executa a cópia diretamente em memória do kernel, sem qualquer validação de que os endereços pertencem ao espaço do processo chamador ou de que a operação é legítima para as funções que o driver deveria expor (leitura de sensores, controle de fan curve, etc.). O atacante controla os três parâmetros integralmente.

Com essa primitiva de leitura/escrita arbitrária em ring0, é possível sobrescrever estruturas do kernel (tokens de processo, tabelas de callback, ponteiros de função) para executar código arbitrário com privilégios de kernel, ou simplesmente corromper memória crítica e causar BSOD, como demonstrado no PoC público do advisório original. O mesmo conjunto de drivers também expõe IOCTLs de leitura/escrita em portas de I/O (CVE-2018-19322), tratada em CVE separada.

A vulnerabilidade foi descoberta por Diego Juarez e publicada pela SecureAuth (advisório CORE-2018-0007), que reporta ainda três falhas relacionadas nos mesmos drivers (CVE-2018-19321, CVE-2018-19322, CVE-2018-19323).

Exploração exige apenas acesso local ao sistema — nenhuma autenticação de rede, nenhuma interação do usuário, e nenhuma configuração especial além de ter o software GIGABYTE/AORUS instalado com o driver GIO carregado (o que ocorre por padrão ao instalar os utilitários listados). Um atacante com qualquer sessão local, mesmo com processo em baixa integridade, abre o handle do driver e envia o IOCTL malicioso para ler ou escrever memória do kernel, obtendo controle total do sistema (execução de código em ring0) a partir de um usuário sem privilégios.

O PoC público divulgado no full-disclosure demonstra a primitiva de escrita arbitrária causando BSOD instantâneo ao escrever em endereço zero — prova de conceito de negação de serviço, mas a mesma primitiva de R/W arbitrário é suficiente, em mãos mais elaboradas, para elevação de privilégio completa (sobrescrita de token de processo é a técnica clássica para esse tipo de driver vulnerável). A CISA lista a CVE no catálogo KEV com confirmação de exploração ativa, mas não indica uso em campanhas de ransomware.

O padrão de uso mais realista não é ataque remoto contra um servidor, e sim escalada de privilégio local por malware ou por um atacante que já obteve execução de código como usuário comum em uma máquina com o driver vulnerável instalado — cenário comum em estações de jogos/gamer com hardware GIGABYTE/AORUS, que é o público-alvo desses utilitários.

O advisório original da SecureAuth (dezembro de 2018) registra explicitamente que o fornecedor não disponibilizou correção nem workaround até a publicação. A página de segurança da GIGABYTE (gigabyte.com/Support/Security/1801) é a referência para status de patch, mas seu conteúdo não foi verificado nesta pesquisa — não é possível confirmar aqui número de versão corrigida para APP Center, AORUS GRAPHICS ENGINE, XTREME GAMING ENGINE ou OC GURU II. A descrição posterior da CVE, ao citar 'before 1.57' e 'before 1.26', sugere que versões mais novas de AORUS GRAPHICS ENGINE e XTREME GAMING ENGINE corrigiram o problema, mas essa faixa diverge da lista original do pesquisador (v1.33 e v1.25), e nenhuma das fontes lidas confirma o mecanismo exato da correção.

Como paliativo real e verificável pelas fontes: remover os utilitários GIGABYTE/AORUS/OC GURU II listados quando não forem estritamente necessários, ou desinstalar/desabilitar o serviço do driver GDrv (arquivo do driver GIO) elimina a superfície de ataque — a maior parte dos usuários não precisa desses drivers para uso normal do hardware. Verificar se o driver ainda está presente mesmo após atualização do software é importante, já que drivers legados costumam permanecer instalados.

Antivírus e EDR não bloqueiam nativamente chamadas DeviceIoControl para drivers assinados e legítimos, então não funcionam como mitigação por si só; regras específicas de controle de aplicação (bloquear carregamento do driver vulnerável por hash/caminho) são a única mitigação técnica de host confiável na ausência de patch confirmado.

Não há indicador de rede, já que a exploração é inteiramente local via IOCTL para um device driver. Em host, sinais possíveis incluem: presença do driver GIO/GDrv (ou GPCIDrv) carregado no sistema; processos não privilegiados abrindo handle para \\.\GIO; chamadas DeviceIoControl com o código de controle 0xC3502808 originadas de processos que não são os utilitários GIGABYTE legítimos. Nenhuma dessas checagens é feita por logging padrão do Windows — requer monitoramento via ETW, driver de segurança com hooks de I/O, ou EDR com visibilidade de chamadas ao driver; na ausência disso, não há sinal confiável de tentativa de exploração.