HTTP Protocol Stack Remote Code Execution Vulnerability

Falha use-after-free no driver http.sys, o componente kernel-mode do Windows que processa requisições HTTP para IIS e outros serviços que usam a pilha HTTP nativa. Afeta especificamente as versões que introduziram suporte a trailers HTTP (Windows 10 2004/20H2 e Windows Server 2004/20H2), não o Windows em geral, e permite execução remota de código sem autenticação — mas a maior parte das provas de conceito públicas demonstra negação de serviço (BSOD), não RCE completo.

A vulnerabilidade é um use-after-free (CWE-416) no processamento de requisições HTTP pelo http.sys, o driver de modo kernel que atende conexões HTTP/HTTPS para IIS, WinRM e qualquer aplicação Windows que use a API HTTP Server. O bug está ligado ao suporte a trailers HTTP (campos enviados após o corpo da mensagem, usado em requisições chunked/HTTP/2), funcionalidade adicionada nas versões 2004 e 20H2 do Windows 10/Server — por isso a falha não existe em versões anteriores do Windows, que não implementam esse trecho de código.

Um use-after-free acontece quando o código libera uma estrutura de memória e depois continua a referenciá-la. No caso do http.sys, ao processar certos trailers malformados ou em determinada sequência, uma estrutura associada à requisição é liberada prematuramente enquanto outra parte do driver ainda mantém um ponteiro para ela. Se o atacante conseguir controlar o conteúdo que reocupa aquele espaço de memória antes do próximo acesso, a execução do driver pode ser desviada para código arbitrário, em modo kernel — daí a criticidade máxima (Integridade e Confidencialidade e Disponibilidade em Alto).

Como o driver roda em kernel, uma exploração bem-sucedida de RCE dá ao atacante controle total do sistema, sem qualquer privilégio prévio (PR:N) e sem interação do usuário (UI:N). O vetor é puramente de rede: basta enviar requisições HTTP manipuladas a um endpoint que use http.sys — na prática, qualquer servidor IIS ou serviço Windows exposto que aceite HTTP/2 com trailers.

O vetor de ataque é uma requisição HTTP enviada à porta onde o serviço baseado em http.sys está escutando — tipicamente IIS, mas também WinRM ou outros serviços que usam a API HTTP Server do Windows. Não é necessária autenticação, conta de usuário, nem interação de vítima; o atacante só precisa de acesso de rede ao endpoint vulnerável e a versão certa do Windows do lado servidor (ou cliente, já que http.sys também é usado por componentes que fazem requisições, tornando cenários client-side teoricamente possíveis, embora o cenário documentado e explorado seja servidor).

As provas de conceito e o módulo Metasploit publicados majoritariamente demonstram o disparo do use-after-free causando crash do sistema (BSOD) — ou seja, negação de serviço confiável e trivial de reproduzir. A escalada de UAF para execução de código arbitrária em kernel é significativamente mais difícil, exigindo controle preciso de heap grooming para que a memória liberada seja reocupada com dados controlados pelo atacante antes do uso subsequente; não há relato público consolidado de um exploit de RCE completo e estável, ainda que o CVSS reflita o impacto teórico máximo.

A CISA confirmou exploração ativa no mundo real (entrada no catálogo KEV, adicionada em abril/2022), sem detalhar se os ataques observados buscavam DoS ou RCE. Dado o EPSS próximo de 1.0 e a disponibilidade pública de PoC e módulo Metasploit, o risco prático mais provável e fácil de explorar em massa é a queda do serviço/sistema, não necessariamente comprometimento total — mas isso não reduz a urgência de correção, já que ambos os desfechos são inaceitáveis em produção.

A correção definitiva é aplicar a atualização de segurança da Microsoft de maio de 2021 para a versão específica do Windows (Windows 10 2004/20H2 ou Windows Server 2004/20H2). Consulte o advisory oficial da Microsoft (MSRC) para o link exato do pacote cumulativo correspondente à build instalada — não há aqui confirmação de números de KB específicos para citar com segurança, e usar o KB errado deixa o sistema exposto acreditando estar corrigido.

Como a falha depende do suporte a trailers HTTP introduzido nessas duas versões do Windows, sistemas em versões anteriores (por exemplo Windows 10 1909 ou anteriores) e versões posteriores já corrigidas não são afetados pelo mesmo código vulnerável. Se a atualização não puder ser aplicada imediatamente, a única mitigação real é reduzir a exposição do serviço que usa http.sys — restringir acesso de rede ao IIS/WinRM afetado via firewall, segmentação ou desativação do serviço até o patch — já que não há confirmação nas fontes consultadas de uma configuração de registro oficialmente validada pela Microsoft para desabilitar o suporte a trailers sem o patch.

Não existe mitigação eficaz via WAF de camada de aplicação, porque a falha ocorre no driver de kernel antes de qualquer processamento HTTP de nível de aplicação — um WAF reverso-proxy pode reduzir exposição apenas se filtrar/normalizar trailers HTTP antes de repassar ao backend Windows, mas isso não é uma mitigação oficial e não foi validado como solução completa.

O sinal mais confiável em ambientes não corrigidos é o crash do processo/serviço que usa http.sys — travamentos do IIS, reinicializações inesperadas (BSOD) associados a http.sys nos logs de eventos do Windows (System/Application), e entradas de dump de memória do kernel apontando para http.sys. Como a maior parte dos PoCs públicos gera negação de serviço em vez de exploração silenciosa, picos de indisponibilidade correlacionados a requisições HTTP anômalas (trailers malformados, HTTP/2 com chunked encoding incomum) em logs de acesso do IIS são um indício, mas não há assinatura de rede oficial amplamente publicada para diferenciar uma tentativa de exploração de tráfego legítimo malformado — na ausência de uma exploração RCE estável documentada publicamente, a detecção prática hoje é majoritariamente reativa (crash pós-fato), não preventiva.