CVE-2019-5544

Falha de heap overflow no daemon OpenSLP (slpd), usado pelo VMware ESXi e pelos appliances Horizon DaaS para o Service Location Protocol. Um atacante na rede, sem autenticação, pode corromper heap e obter execução remota de código no host, ou no mínimo travar o serviço. É a vulnerabilidade que ficou conhecida como o vetor 'SLP no ESXi' e está no catálogo KEV da CISA por exploração confirmada em ambiente real.

A falha está na função ProcessSrvRqst() em slpd_process.c, parte do código que processa requisições de serviço (SrvRqst) recebidas pelo daemon SLP. O parser calcula ou usa incorretamente o tamanho de um buffer alocado no heap ao montar a resposta ou ao copiar dados de campos controlados pelo atacante dentro do pacote SLP, resultando em escrita fora dos limites do buffer (heap-based buffer overflow, CWE-122/CWE-787). O atacante controla o conteúdo de campos da requisição SLP que chegam ao daemon, o que permite direcionar a sobrescrita de metadados de heap ou de estruturas adjacentes.

O relatório original foi feito pela equipe 360Vulcan durante o Tianfu Cup Pwn Contest de 2019, e a VMware Security Response Center confirmou o problema publicamente em dezembro de 2019, distribuindo patches para as versões 1.2.1 e 2.0.0 do openslp diretamente aos mantenedores e a distribuidores como Red Hat — não via commit público imediato no repositório upstream do projeto (openslp-org/openslp no GitHub), que na época da divulgação ainda não tinha recebido a correção.

A descrição oficial da VMware é genérica quanto a versões exatas de ESXi e Horizon DaaS afetadas — ela cita apenas 'ESXi and the Horizon DaaS appliances' sem listar builds específicos nas fontes disponíveis aqui. Quem precisa confirmar exposição em um ambiente VMware deve consultar o advisory oficial da VMware (VMSA correspondente) para a lista de builds e patches específicos daquele produto, já que este texto documenta primariamente o componente OpenSLP em si, tal como distribuído em distribuições Linux (Red Hat, Fedora, Gentoo).

O SLP escuta por padrão nas portas UDP/TCP 427. Não há necessidade de autenticação nem de qualquer interação do usuário — basta acesso de rede ao serviço SLP exposto (AV:N, PR:N, UI:N no vetor CVSS). O atacante envia uma requisição SrvRqst malformada com campos manipulados para acionar o overflow em ProcessSrvRqst(); dependendo do controle alcançado sobre a região sobrescrita do heap, o resultado varia de crash do slpd (negação de serviço) até execução remota de código com os privilégios do processo do daemon.

No contexto VMware, isso se torna crítico porque o SLP no ESXi historicamente roda com privilégios elevados e ficou exposto em interfaces de gerenciamento acessíveis pela rede — cenário que tornou esta CVE (e a CVE-2020-3992 relacionada, do mesmo componente) alvo de campanhas de ransomware que escaneiam a porta 427 em busca de hipervisores vulneráveis. A presença no catálogo KEV da CISA confirma exploração ativa observada, e a existência de PoC pública e de template Nuclei reduz a barreira técnica para reprodução — qualquer scanner de rede pode identificar hosts com o serviço ainda ativo.

A complexidade de exploração é considerada baixa (AC:L) porque não exige condições de corrida, bypass de ASLR sofisticado documentado publicamente, ou acesso privilegiado prévio — apenas alcance de rede à porta do SLP. Isso explica o CVSS 9.8 e o EPSS próximo do máximo.

Para hosts Linux/distribuições usando o pacote openslp diretamente: atualizar para as versões corrigidas distribuídas pelos fornecedores — Red Hat publicou openslp-2.0.0-8.el7_7 para RHEL 7 (RHSA-2019:4240) e openslp-2.0.0-4.el6_10 para RHEL 6 (RHSA-2020:0199); Fedora e Gentoo (GLSA 202005-12) também lançaram builds corrigidos. Não há uma versão upstream 'oficial' do projeto openslp corrigida no momento da divulgação, já que os patches foram entregues diretamente aos mantenedores e distribuidores, não commitados imediatamente no repositório GitHub do projeto — por isso a correção real disponível a cada ambiente depende do pacote da distribuição usada, não de uma tag de versão upstream específica.

Para ambientes VMware ESXi e Horizon DaaS, a mitigação correta é aplicar o patch/VMSA específico da VMware para o produto e build em uso — este texto não tem acesso ao número exato do VMSA nem à lista de builds ESXi corrigidos nas fontes disponíveis, e não deve ser preenchido por suposição. Como paliativo amplamente divulgado pela própria comunidade de segurança para o SLP em ESXi, quando a atualização imediata não é viável: desabilitar o serviço SLP no host (que não é necessário para operação normal do ESXi na maioria dos ambientes) e bloquear/filtrar as portas UDP/TCP 427 na rede de gerenciamento, restringindo-as a hosts de confiança.

Não funciona como mitigação apenas colocar o hipervisor atrás de um firewall de borda genérico se a rede de gerenciamento interna ainda permite acesso lateral à porta 427 — o vetor típico de exploração em campanhas reais partiu de movimento lateral dentro da rede, não de exposição direta à internet.

Não há, nas fontes analisadas, uma assinatura de rede ou indicador de comprometimento oficialmente publicado pela VMware ou pela Red Hat para esta CVE especificamente. Como sinal geral, monitore tráfego anômalo ou inesperado nas portas UDP/TCP 427 (SLP) partindo de origens não autorizadas, crashes repetidos do processo slpd em logs do sistema, e escaneamentos de rede voltados a essa porta — padrão associado a campanhas de ransomware que buscam hipervisores ESXi com SLP exposto. A existência de template Nuclei e PoC pública sugere que qualquer tentativa de exploração deve gerar múltiplas requisições SrvRqst malformadas em sequência, mas não há um payload de assinatura confirmado nas fontes disponíveis.