Cisco IOS XR Software DVMRP Memory Exhaustion Vulnerability

Falha de esgotamento de memória (CWE-400) no processo IGMP do Cisco IOS XR quando o recurso DVMRP está em uso, explorável remotamente sem autenticação. Não é uma RCE nem permite escalada de privilégio — o impacto é disponibilidade: o dispositivo pode ficar instável e afetar protocolos de roteamento vizinhos. Está na KEV da CISA porque houve exploração confirmada, mas o vetor exige uma pré-condição específica de configuração que a maioria dos ambientes não tem.

A causa raiz, segundo o próprio advisory da Cisco, é gerenciamento de fila insuficiente para pacotes IGMP (a descrição original fala em 'insufficient queue management'; a versão final do advisory generaliza para 'incorrect handling' de pacotes IGMP, CWE-400 — Uncontrolled Resource Consumption). O DVMRP é transportado sobre IGMP no IOS XR, e o processo que trata esses pacotes não limita corretamente a alocação de memória ao processar tráfego DVMRP malformado ou em volume anormal.

O atacante controla o conteúdo e a taxa dos pacotes IGMP/DVMRP enviados a uma interface do roteador. Não há necessidade de autenticação nem de estabelecer sessão de roteamento — basta que a interface aceite o tráfego. O resultado é o processo igmp consumindo memória até esgotar o limite (RLIMIT_DATA) e crashar, ou, na variante relacionada CVE-2020-3569 (mesmo advisory, mesmo bug de fundo), crash imediato do processo.

O advisory trata CVE-2020-3566 e CVE-2020-3569 como duas vulnerabilidades distintas do mesmo pacote de correção: uma leva a esgotamento gradual de memória (a desta página), a outra a crash imediato do processo IGMP. Cisco atribuiu os IDs internos CSCvr86414 e CSCvv54838.

Como o processo IGMP compartilha recursos de memória do sistema com outros processos do plano de controle, o esgotamento pode degradar protocolos de roteamento interior e exterior (IGP/BGP) que rodam na mesma caixa, mesmo sem relação funcional direta com multicast.

Pré-condição real, e é a informação mais importante da página: o dispositivo só é vulnerável se houver uma interface ativa com multicast routing habilitado (visível via `show igmp interface` retornando saída não vazia) E se essa interface estiver de fato recebendo tráfego DVMRP (visível via `show igmp traffic`, campo 'DVMRP packets' diferente de zero). Se multicast routing não está habilitado, o dispositivo não é afetado, independentemente da versão de IOS XR.

Com essa pré-condição satisfeita, a exploração é trivial em complexidade (AC:L, sem interação do usuário, sem privilégio): o atacante envia tráfego IGMP/DVMRP manipulado para a interface exposta. Não é preciso estar na mesma rede administrativa nem ter credenciais — só alcance de rede até a interface que aceita esse tráfego. O resultado final é negação de serviço: consumo de memória até degradação ou crash do processo IGMP, com possível efeito colateral em outros processos do roteador.

A CISA lista a CVE no catálogo KEV (adicionada em 2021-11-03, prazo de correção 2022-05-03), confirmando exploração no mundo real, mas sem detalhar campanha, ator ou contexto — a nota da CISA no catálogo apenas classifica como 'unknown' quanto a uso em ransomware e remete à ação genérica 'aplicar atualizações conforme instruções do fornecedor'.

O advisory da Cisco afirma que updates de software foram liberados, mas o conteúdo do advisory capturado aqui não especifica os números de versão corrigidos por trem de release — para obter a versão exata aplicável ao seu hardware/trem, é necessário consultar o Cisco Software Checker vinculado ao próprio advisory (cisco-sa-iosxr-dvmrp-memexh-dSmpdvfz). Não afirme aqui uma versão corrigida sem confirmar isso na ferramenta oficial.

A Cisco declara explicitamente que não há workaround (configuração que elimine a falha), mas lista mitigações parciais: (1) rate limiter de tráfego IGMP via `lpts pifib hardware police flow igmp rate `, calculado abaixo da taxa média atual de IGMP do ambiente — eficaz apenas para o cenário de esgotamento gradual de memória (CVE-2020-3566), não para o crash imediato (CVE-2020-3569); (2) controle de acesso (ACL) bloqueando tráfego IGMP/DVMRP não confiável nas interfaces expostas — eficaz para ambos os cenários. Se o processo já crashou, o restart é automático pelo sysmgr; se está em esgotamento progressivo sem crash, o comando `process restart igmp` recupera a memória manualmente.

Mitigação mais simples quando aplicável: desabilitar multicast routing ou DVMRP em interfaces que não precisam dele elimina a superfície de ataque por completo, já que a falha só existe nesse caminho de código. Não existe mitigação via firmware antigo ou reinício simples do roteador de forma permanente — o restart apenas resolve o sintoma até a próxima exploração.

A Cisco lista indicadores de comprometimento diretamente no advisory. Para o esgotamento de memória (esta CVE): mensagens de log como `%PKT_INFRA-PQMON-6-QUEUE_DROP: Taildrop on XIPC queue 1 owned by igmp`, seguidas de `%OS-DUMPER-7-DUMP_REQUEST` / `%OS-DUMPER-4-SIGSEGV` para o processo igmp. Para crash do processo IGMP (CVE-2020-3569 relacionada): `%HA-HA_WD_LIB-4-RLIMIT: wd_handle_sigxfsz: Reached 90% of RLIMIT_DATA`, `%ROUTING-IPV4_IGMP-4-OOM_STATE_THROTTLE` e `%HA_WD_LIB` seguido de `sysmgr` reportando terminação anormal do processo igmp com reinício automático.

Além dos logs, `show igmp traffic` mostrando volume anormalmente alto no contador 'DVMRP packets' recebidos é sinal de tráfego de exploração em andamento, especialmente comparado à baseline histórica do ambiente.