CVE-2020-3992
Priorize a correção. Ela está sob exploração confirmada pelo CISA e tem prova de conceito pública.
Apply updates per vendor instructions.
Resumo
Falha de use-after-free (CWE-416) no serviço OpenSLP do VMware ESXi, acessível via porta 427/TCP-UDP, que permite execução remota de código a um atacante posicionado na rede de gerenciamento, sem autenticação. É crítica onde a interface de gerenciamento do ESXi está exposta a redes não confiáveis; em ambientes onde a porta 427 está isolada em uma VLAN de gerência restrita, o risco prático cai bastante mesmo com CVSS 9.8.
Detalhamento técnico
A falha está no processamento de mensagens SLP (Service Location Protocol) pelo daemon OpenSLP embutido no ESXi. O serviço libera (free) um objeto em memória e, em uma condição específica de fluxo de mensagens, continua referenciando esse objeto depois — um use-after-free clássico. A ZDI descreve a causa raiz como 'lack of validating the existence of an object prior to performing operations on the object', ou seja, o código assume que o objeto ainda é válido sem checar seu estado antes de operar sobre ele.
Há duas variantes documentadas sob a mesma CVE. A ZDI-20-1377 (CVSS 8.8, AV:A) descreve o vetor original: um atacante adjacente à rede, sem autenticação, envia mensagens SLP malformadas para acionar o UAF e executar código no contexto do daemon SLP. A ZDI-20-1385 (CVSS 7.8, AV:L), divulgada dias depois, descreve uma segunda exploração da mesma classe de bug, mas exigindo que o atacante já tenha execução de código com privilégios baixos na máquina, permitindo escalar para root — indicando que o primeiro patch da VMware não eliminou completamente a superfície do UAF.
O detalhe mais relevante para quem está lendo o advisory da VMware corrido: a própria VMSA-2020-0023 admite que os patches lançados em 20/10/2020 (as versões citadas na descrição oficial da CVE, como ESXi_7.0.1-0.0.16850804) NÃO corrigiram o problema por completo. A correção definitiva só saiu em builds posteriores, publicados em 24/11/2020.
Como é explorada
Pré-requisito real: acesso de rede à porta 427 do host ESXi (TCP e UDP), tipicamente restrita à VLAN de gerenciamento. Não é necessária autenticação — o serviço OpenSLP responde a mensagens SLP de qualquer origem que alcance a porta. Isso torna a exploração viável para qualquer atacante que já tenha pé dentro da rede de gerenciamento (movimento lateral, VPN comprometida, segmentação de rede falha), mas inviabiliza ataque direto pela internet em topologias bem desenhadas, onde a interface de gerenciamento nunca deveria estar exposta.
Existe PoC pública e a falha está no catálogo KEV da CISA com confirmação de exploração ativa in-the-wild (adicionada em 03/11/2021, CWE-416, sem associação confirmada a campanhas de ransomware conforme o registro da CISA). O resultado final da exploração bem-sucedida é execução de código no contexto do daemon slpd, que historicamente roda com privilégios elevados no hypervisor — dado o papel do ESXi como base de virtualização, comprometimento aqui equivale a controle total das VMs hospedadas.
A segunda variante (ZDI-20-1385) não é um vetor de acesso inicial: serve para escalada de privilégio local a partir de um acesso já obtido com privilégios baixos, relevante em cenários pós-comprometimento parcial ou onde o atacante já controla uma VM/console com acesso limitado ao host.
Versões
Como se proteger
A correção do fornecedor é aplicar o patch. Atenção: os patches de outubro/2020 citados na descrição oficial da CVE (ESXi_7.0.1-0.0.16850804, ESXi670-202010401-SG, ESXi650-202010401-SG) são incompletos segundo a própria VMware. As versões que corrigem definitivamente são: ESXi 7.0 → ESXi70U1a-17119627; ESXi 6.7 → ESXi670-202011301-SG; ESXi 6.5 → ESXi650-202011401-SG; VMware Cloud Foundation (ESXi 4.x) → 4.1.0.1; VMware Cloud Foundation (ESXi 3.x) → 3.10.1.2.
O advisory oficial referencia um workaround documentado na KB76372 da VMware (não detalhado no conteúdo consultado aqui) — validar diretamente essa KB antes de aplicá-lo como paliativo. Como controle compensatório imediato e independente de patch: desabilitar ou remover o serviço SLP no ESXi (quando não usado, o que é o caso da maioria dos ambientes) e garantir que a porta 427 nunca esteja acessível fora da rede de gerenciamento estritamente controlada — isso neutraliza o vetor remoto sem depender do patch, mas não resolve a variante de escalada local (ZDI-20-1385).
O KEV da CISA determinou prazo de correção (due date 03/05/2022) para agências federais dos EUA, o que sinaliza a gravidade e a exploração confirmada — não é apenas classificação teórica de CVSS.
Como detectar
As fontes consultadas não trazem assinatura de rede ou IOC específico publicado pela VMware ou pela CISA para esta CVE — o registro KEV confirma exploração in-the-wild sem detalhar indicadores. Na prática, monitorar tráfego SLP (portas 427 TCP/UDP) originado de fora da sub-rede de gerenciamento do ESXi é o sinal mais direto de exposição indevida (pré-condição de ataque), não necessariamente evidência de exploração. Crashes inesperados ou reinícios do processo slpd nos logs do ESXi (vmkernel/hostd) merecem investigação como possível indício de tentativa de UAF, mas não há confirmação pública de que esse seja um indicador confiável e exclusivo dessa CVE.