Heap-overflow vulnerability

Heap-overflow na implementação do protocolo DCERPC do vCenter Server, explorável remotamente sem autenticação e sem interação do usuário, com potencial de execução de código arbitrário. A Broadcom confirmou exploração ativa in-the-wild e a CISA incluiu a falha no catálogo KEV — o CVSS 9.8 aqui reflete risco real, não teórico, dado o acesso via rede à interface de gerenciamento.

A falha é um heap-based buffer overflow (CWE-122) no código que processa pacotes DCERPC dentro do vCenter Server. DCERPC é o protocolo RPC usado por componentes internos do vSphere para comunicação entre serviços; a implementação vulnerável não valida corretamente o tamanho ou conteúdo de dados recebidos antes de copiá-los para um buffer alocado no heap, permitindo que um pacote malicioso corrompa memória adjacente. O atacante controla o conteúdo do pacote de rede enviado ao serviço que expõe essa interface DCERPC — não há indicação nas fontes de que autenticação prévia seja necessária, e o vetor CVSS (AV:N/AC:L/PR:N/UI:N) confirma isso.

Um ponto crítico documentado pela própria Broadcom: os patches liberados em 17 de setembro de 2024 (data original da VMSA-2024-0019) não corrigiram completamente o CVE-2024-38812. Só as versões liberadas em 21 de outubro de 2024 (8.0 U3d, 8.0 U2e, 7.0 U3t) endereçam a falha por completo. Isso significa que ambientes que aplicaram apenas o primeiro round de patches em setembro permaneceram vulneráveis até a atualização de outubro, mesmo acreditando estar corrigidos.

A vulnerabilidade foi reportada de forma responsável por pesquisadores (zbl & srs, do time TZL) durante o Matrix Cup 2024, contest chinês de competição de exploração — o que também explica por que exploração in-the-wild surgiu relativamente rápido após a divulgação inicial.

O vetor é rede: um atacante com conectividade à porta/serviço DCERPC do vCenter Server envia um pacote malformado especificamente construído para acionar o overflow. Não há evidência nas fontes de exigência de autenticação, interação de usuário ou configuração não padrão — a superfície de ataque é a própria interface de gerenciamento do vCenter, que tipicamente fica acessível a administradores de rede interna, mas em ambientes mal segmentados pode estar exposta além do necessário.

A Broadcom confirmou formalmente, na atualização de 18 de novembro de 2024 da VMSA-2024-0019 (versão .3), que exploração ocorreu in-the-wild tanto para CVE-2024-38812 quanto para CVE-2024-38813 (a falha de escalação de privilégio companheira). A CISA adicionou o CVE-2024-38812 ao catálogo KEV em 20/11/2024, com prazo de correção (due date) em 11/12/2024, reforçando que agências federais dos EUA e, por extensão, qualquer organização com exposição similar, tratem isso como exploração ativa confirmada, não apenas risco potencial.

O impacto final documentado é execução remota de código no vCenter Server — comprometimento completo do serviço que centraliza gerenciamento de toda a infraestrutura vSphere (hosts ESXi, VMs, storage, rede virtual). Não há detalhes técnicos públicos sobre a cadeia de exploração além da confirmação do heap-overflow; as fontes não descrevem PoC ou exploit público conhecido, apenas a confirmação de uso ofensivo real.

A correção definitiva depende da versão de origem. Para vCenter Server 8.0, aplicar 8.0 U3d ou, para quem está na linha U2, 8.0 U2e. Para vCenter Server 7.0, aplicar 7.0 U3t. Para VMware Cloud Foundation, os patches são assíncronos: 5.x recebe patch para 8.0 U3d, 5.1.x para 8.0 U2e, e 4.x para 7.0 U3t (procedimento descrito na KB88287). Atenção: se o ambiente aplicou apenas os patches de setembro de 2024, a correção é incompleta — é necessário atualizar novamente para as versões de outubro para fechar o CVE-2024-38812 por completo.

A própria Broadcom declara explicitamente que workarounds in-product foram avaliados e considerados não viáveis. Não existe configuração, flag ou controle compensatório oficial que mitigue a falha sem aplicar o patch — isso inclui qualquer prática de 'desativar serviço X' não documentada pelo fornecedor, que não deve ser tratada como mitigação real. A única ação de contenção prática, na ausência de patch imediato, é restringir rigorosamente o acesso de rede ao vCenter Server (segmentação, firewall, VPN de gestão) para reduzir a superfície de exposição — mas isso reduz risco, não elimina a vulnerabilidade.

Dado o status KEV com exploração confirmada, o patch deve ser tratado como prioridade máxima e não como item de manutenção de rotina, independente de o vCenter estar ou não exposto diretamente à internet — redes internas comprometidas por outros vetores também dão ao atacante o acesso de rede necessário.

As fontes não descrevem assinaturas, padrões de log ou indicadores de rede específicos para detectar tentativas de exploração do heap-overflow DCERPC. Não há PoC público documentado nas referências consultadas, o que limita a criação de detecção baseada em payload conhecido; monitorar crashes ou comportamento anômalo do serviço vCenter (reinícios inesperados, erros relacionados a RPC) pode ser um indicador indireto, mas não há confirmação de que isso seja sinal confiável de exploração versus falha operacional comum.