CVE-2018-0174

Falha de validação de entrada (CWE-20) na funcionalidade de encapsulamento de DHCP option 82 do Cisco IOS e IOS XE, que permite a um atacante remoto não autenticado provocar reload do dispositivo (DoS) enviando um pacote DHCPv4 malformado. O impacto real depende de uma configuração específica de relay agent que não é padrão na maioria dos ambientes — mas onde existe (redes de acesso, campus, ambientes industriais com switches Rockwell/Allen-Bradley baseados em IOS), a exploração é trivial e não exige autenticação.

A vulnerabilidade está no código do DHCP relay agent do IOS/IOS XE responsável por encapsular a informação de option 82 recebida de outros relay agents. Segundo a análise da Tenable (TRA-2018-06), quando o relay agent recebe um DHCPv4 com option 82 já presente, ele precisa mover (memmove) o option 82 original para abrir espaço para o novo option 82 que vai inserir, encapsulando o original como suboption. Para calcular o tamanho desse memmove, o código faz a aritmética pEndOfMsg - pEndOfEncapsulatedOpt82.

O bug (CVE-2018-0174, identificado pela Tenable como 'Bad Pointer Arithmetic #1') está em que pEndOfEncapsulatedOpt82 pode acabar sendo maior que pEndOfMsg — um resultado negativo que, tratado como aritmética de ponteiros/inteiro sem sinal, gera um valor de tamanho absurdamente grande para o memmove. O processo tenta mover essa quantidade de dados, sai da região de memória válida e dispara uma access violation, que reinicia o dispositivo (crash controlado, não RCE).

É uma das três falhas correlatas encontradas pela Tenable no mesmo subsistema durante pesquisa sobre CVE-2017-12240: CVE-2018-0172 (heap buffer overflow no memmove quando o option 82 do cliente está no fim de um bloco heap) e CVE-2018-0173 (memset com tamanho calculado incorretamente ao remover option 82 de uma DHCPOFFER). As três compartilham a mesma superfície — o parser de option 82 do relay agent — mas CVE-2018-0174 é puramente uma condição de DoS por corrupção de aritmética de ponteiro, não um overflow de heap explorável para execução de código.

O atacante controla o conteúdo e o tamanho do campo option 82 dentro do pacote DHCPv4 que envia ao dispositivo agindo como relay.

O vetor é um pacote DHCPv4 forjado contendo um option 82 malformado, enviado ao dispositivo que atua como DHCP relay agent. Não há autenticação envolvida (PR:N, UI:N) e a complexidade de ataque é baixa (AC:L) — quem tem acesso de rede ao segmento onde o dispositivo escuta DHCP pode tentar.

O ponto crítico, que a manchete do CVSS 8.6 não deixa claro: a falha só é explorável se o dispositivo estiver configurado simultaneamente como (1) DHCP relay agent (ip helper-address configurado), (2) inserindo option 82 nos pacotes que retransmite (ip dhcp relay information option-insert) e (3) configurado para encapsular option 82 recebido de outros relay agents (ip dhcp relay information policy encapsulate). Essa combinação de três configurações não é padrão de fábrica — é típica de topologias com relay agents em cascata, comuns em redes de acesso de operadoras e em alguns ambientes industriais que usam switches Allen-Bradley/Rockwell baseados em IOS/IOS XE.

A CVE está no catálogo KEV da CISA, indicando exploração confirmada em ambiente real, embora as fontes disponíveis não detalhem campanha específica ou ator. O resultado de uma exploração bem-sucedida é reload do dispositivo — impacto de disponibilidade puro (C:N/I:N/A:H), sem indício de execução de código relatado para este CVE especificamente (diferente de CVE-2018-0172, que é overflow de heap).

O advisory da Cisco (cisco-sa-20180328-dhcpr3) afirma explicitamente que não há workaround disponível — a única correção é atualizar o software para uma versão fixa do IOS ou IOS XE. As fontes coletadas não trazem a tabela completa de releases corrigidas por trem de versão; use o Cisco Software Checker ou a seção 'Fixed Software' do advisory oficial para identificar a versão exata para o seu hardware/trem de release antes de planejar a atualização — não generalize uma versão de outro produto Cisco para o seu.

Como controle compensatório real, já que não há flag de mitigação, é possível reduzir a superfície de exposição verificando se a configuração de risco está de fato presente: rode show running-config | include ip helper-address (ou show running-config | include cable helper-address em Cisco cBR-8) para detectar relay agent ativo, e show running-config | include ip dhcp relay information option e show running-config | include ip dhcp relay information policy.* encapsulate para verificar se option 82 insertion e encapsulation estão habilitados. Se nenhuma dessas configurações estiver presente, o dispositivo não está na condição vulnerável descrita pelo fornecedor, mesmo rodando uma versão de software listada como afetada.

Em ambientes onde não é possível atualizar (típico de infraestrutura industrial legada, como os switches Rockwell/Allen-Bradley citados nos advisories ICS-CERT), considerar isolar o tráfego DHCP em VLANs de gerência restritas e limitar quem pode enviar pacotes DHCPv4 ao segmento onde o relay está configurado, como redução de exposição — isso não corrige a falha, apenas reduz quem pode alcançá-la.

As fontes coletadas não indicam assinatura IDS/IPS oficial ou padrão de log confiável e documentado publicamente para detectar tentativas de exploração deste CVE especificamente. Como indício indireto, reloads inesperados e recorrentes em dispositivos configurados como DHCP relay agent com option 82 insertion/encapsulation habilitados, correlacionados no tempo com tráfego DHCPv4 anômalo (pacotes com option 82 de tamanho ou estrutura fora do padrão) proveniente de segmentos não confiáveis, é o sinal prático a investigar. Capturar e inspecionar pacotes DHCPv4 recebidos nas interfaces configuradas como relay é a única forma concreta de confirmar tentativa, na ausência de assinatura publicada.