Cisco IOS XR Software DVMRP Memory Exhaustion Vulnerabilities

Falha de exaustão de memória no processo IGMP do Cisco IOS XR, disparada pelo tratamento incorreto de pacotes DVMRP recebidos em interfaces com roteamento multicast ativo. Um atacante remoto não autenticado pode forçar o processo IGMP a consumir toda a memória disponível até travar, degradando outros processos do equipamento — incluindo protocolos de roteamento interno e externo. Está no catálogo KEV da CISA por exploração confirmada, mas exige uma pré-condição específica de configuração que reduz bastante a superfície real de exposição.

A causa raiz é CWE-400 (Uncontrolled Resource Consumption). O processo IGMP do IOS XR, ao processar pacotes DVMRP recebidos, aloca estruturas de estado sem limite efetivo de consumo de memória por pacote recebido. Um fluxo de pacotes DVMRP forjados e enviados continuamente faz o processo alocar memória progressivamente até esgotar a memória disponível no sistema, afetando outros processos que competem pelo mesmo pool.

O advisory da Cisco agrupa esta CVE com a CVE-2020-3566 sob o mesmo aviso (cisco-sa-iosxr-dvmrp-memexh), cobrindo duas variantes de exploração da mesma família de bug: uma leva a crash imediato do processo IGMP, outra leva a exaustão gradual de memória seguida de crash. O texto do fornecedor não detalha, no nível de código, a diferença exata de trigger entre as duas CVEs — apenas que ambas decorrem do parsing incorreto de pacotes IGMP/DVMRP.

O atacante controla o conteúdo e a taxa de envio dos pacotes IGMP/DVMRP direcionados à interface vulnerável. Não há necessidade de autenticação nem de estabelecer sessão prévia com o roteador — basta que o pacote chegue a uma interface com IGMP habilitado.

Pré-condição decisiva, que a manchete de 8.6/crítico esconde: o dispositivo só é vulnerável se tiver multicast routing habilitado em pelo menos uma interface ativa e estiver de fato recebendo tráfego DVMRP nessa interface. Roteadores IOS XR sem multicast configurado, ou com multicast habilitado mas sem DVMRP habilitado/permitido, não são explorável por este vetor. O próprio advisory fornece os comandos para verificar isso (show igmp interface e show igmp traffic).

Com a pré-condição satisfeita, a exploração é trivial em termos de complexidade: o atacante envia pacotes IGMP/DVMRP manipulados via rede para a interface exposta — sem necessidade de acesso privilegiado, VLAN interna ou qualquer credencial. O vetor de ataque de rede (AV:N) e a ausência de interação do usuário (UI:N) tornam viável a exploração por qualquer host capaz de rotear tráfego IGMP até a interface vulnerável, incluindo potencialmente peers BGP/multicast externos dependendo da topologia.

A presença no catálogo KEV da CISA confirma exploração em ambiente real, embora a CISA não classifique isso como uso em campanhas de ransomware. O resultado da exploração bem-sucedida é indisponibilidade: crash do processo IGMP (com reinício automático pelo sysmgr) ou exaustão de memória que desestabiliza outros processos do plano de controle, incluindo protocolos de roteamento IGP/EGP — o que pode causar queda de sessões de roteamento e não apenas do multicast.

Não há workaround que elimine a vulnerabilidade — apenas mitigações paliativas, e cada uma cobre um cenário diferente. Para o caso de exaustão de memória, um rate limiter (comando `lpts pifib hardware police flow igmp rate `) é eficaz, mas exige que o operador conheça a taxa média atual de tráfego IGMP legítimo e configure um limite abaixo dela — há um limitador padrão, mas o advisory recomenda ajuste manual. Para o caso de crash imediato do processo IGMP, apenas controle de acesso (ACL bloqueando ou restringindo tráfego DVMRP/IGMP de origens não confiáveis) é citado pelo fornecedor como eficaz; o rate limiter não protege esse cenário.

A correção definitiva é a atualização de software indicada pela Cisco. O trecho de advisory disponível não lista as versões corrigidas exatas por trem de release (IOS XR tem múltiplos trens e tabelas de correção via Cisco Software Checker) — não invente números aqui; consulte a tabela oficial do advisory ou o Cisco Software Checker para a versão exata do seu trem.

Se o processo IGMP já estiver com memória exaurida, `process restart igmp` recupera a memória consumida sem exigir reboot completo do equipamento; no caso de crash imediato, o sistema já reinicia o processo automaticamente. Desabilitar multicast routing na interface, quando não há necessidade operacional de DVMRP, remove completamente a exposição — é o controle compensatório mais simples quando a atualização não é imediata.

Sinais de exaustão de memória em andamento aparecem nos logs do sistema como mensagens `%PKT_INFRA-PQMON-6-QUEUE_DROP` (taildrop na fila XIPC do processo igmp), seguidas potencialmente por `%OS-DUMPER-7-DUMP_REQUEST`, `%OS-DUMPER-7-DUMP_ATTRIBUTE` e `%OS-DUMPER-4-SIGSEGV` indicando falha do processo. Um crash já consumado do processo IGMP gera `%HA-HA_WD_LIB-4-RLIMIT` (aproximação do limite RLIMIT_DATA), `%ROUTING-IPV4_IGMP-4-OOM_STATE_THROTTLE` e `%HA-HA_WD_LIB... sysmgr` reportando reinício automático do processo (jid do igmp) com fail_count incrementado.

No plano de tráfego, o comando `show igmp traffic` mostrando contador de `DVMRP packets` recebidos crescendo de forma anômala em uma interface onde DVMRP não é esperado é o indicador mais direto de tentativa de exploração — especialmente se a taxa de recebimento subir descoladamente do padrão histórico do ambiente.