CVE-2018-0172

Falha de heap overflow no processamento de encapsulamento da opção 82 do DHCP relay agent em Cisco IOS e IOS XE. Um atacante não autenticado na rede pode enviar um pacote DHCPv4 malformado e forçar o reload do dispositivo, causando negação de serviço. Está no catálogo KEV da CISA com exploração confirmada, mas só afeta equipamentos configurados como relay agent com opção 82 habilitada — não é toda instalação IOS/IOS XE.

A causa raiz (CWE-20, validação de entrada incompleta) está na rotina de encapsulamento de option 82 do relay agent DHCPv4 do IOS/IOS XE. Quando o relay recebe um DHCP discover contendo uma option 82 do cliente e está configurado para encapsulá-la, o código gera uma nova option 82 e usa memmove para deslocar a option 82 original (e os dados subsequentes) para abrir espaço antes de inserir a nova option 82 no início do buffer.

O problema, descrito pela pesquisa da Tenable (TRA-2018-06), é que se a option 82 fornecida pelo cliente estiver posicionada no final de um bloco de heap, o memmove grava além dos limites daquele bloco, corrompendo a próxima estrutura alocada no heap. É um heap buffer overflow clássico: o atacante controla o conteúdo e, indiretamente, o posicionamento da option 82 dentro do pacote DHCP, o suficiente para acionar a escrita fora de limites.

A vulnerabilidade está relacionada a duas outras no mesmo subsistema (CVE-2018-0173 e CVE-2018-0174), também descobertas pela Tenable ao pesquisar o CVE-2017-12240: todas envolvem aritmética de ponteiros ou cópias de memória malfeitas na lógica de encapsulamento/remoção da option 82 do relay DHCPv4. As três compartilham o mesmo vetor de entrada — pacotes DHCPv4 crafted — mas mecanismos de corrupção distintos.

O impacto documentado é reload do dispositivo (DoS), não execução de código — nem o fornecedor nem a Tenable relataram RCE demonstrado para este CVE especificamente.

O vetor é um pacote DHCPv4 (discover) enviado ao dispositivo vulnerável contendo uma option 82 elaborada para cair no final de um bloco de heap — a Tenable menciona especificamente o uso de uma mensagem DHCP discover de 0x2000 bytes com a option 82 posicionada no fim do bloco para provocar o overflow. Não requer autenticação nem interação do usuário (UI:N), e o AV:N/AC:L do vetor CVSS refletem isso: qualquer host capaz de enviar tráfego DHCP ao relay agent pode tentar.

A pré-condição real, e é o ponto que a nota do CVSS/KEV não deixa óbvio: o dispositivo precisa estar configurado como DHCP relay agent (comando ip helper-address ou, em cBR-8, cable helper-address) E ter habilitada a inserção de option 82 E a encapsulação de option 82 recebida de outros relay agents (ip dhcp relay information policy encapsulate). Sem essas três configurações simultâneas, o caminho de código vulnerável nunca é executado. Isso restringe bastante o universo de exposição real em comparação com 'todo equipamento Cisco IOS'.

A entrada no catálogo KEV da CISA indica exploração confirmada em ambiente real, mas os detalhes públicos de exploração ativa (quem, contra o quê, com que payload) não estão nas fontes consultadas. O resultado de uma exploração bem-sucedida é queda/reload do dispositivo — impacto de disponibilidade em roteador ou switch, potencialmente crítico em ambientes industriais (o CVE foi incluído em advisories ICS-CERT para switches Rockwell Automation Stratix/ArmorStratix, que embarcam IOS/IOS XE).

O advisory da Cisco (cisco-sa-20180328-dhcpr1) afirma explicitamente que não há workaround: 'There are no workarounds that address this vulnerability.' A única correção é atualizar para uma versão corrigida do Cisco IOS ou IOS XE — a lista exata de releases fixas está na seção 'Fixed Software' do advisory oficial e deve ser confirmada com a ferramenta Cisco Software Checker, pois as versões variam por trem de release (12.2, 15.x, IOS XE 3.x/16.x) e não foram enumeradas nos materiais disponíveis para esta análise.

Como controle compensatório até a atualização: desabilitar a encapsulação de option 82 (remover 'ip dhcp relay information policy encapsulate' ou o equivalente por interface) elimina o caminho de código vulnerável, já que a falha só ocorre quando o encapsulamento está ativo. Isso tem custo funcional — perde-se a capacidade de preservar a option 82 de relay agents upstream — mas é um paliativo real, não um mito. Restringir quem pode enviar pacotes DHCP ao dispositivo (ACLs, isolamento de VLAN de gerenciamento) reduz a superfície, mas não corrige a falha em si.

Para os produtos Rockwell Automation Stratix/ArmorStratix (que embarcam IOS/IOS XE), os advisories ICS-CERT ICSA-18-107-04 e ICSA-18-107-05 apontam que switches nas versões 15.2(6)E0a e anteriores (Stratix 5400/5410/5700/8000, ArmorStratix 5700) e 15.2(4a)EA5 e anteriores (Stratix 8300) usam versão vulnerável do IOS/IOS XE e possuem atualizações disponíveis pelo canal do fornecedor do equipamento.

Nenhuma das fontes consultadas (Cisco, Tenable, ICS-CERT) descreve assinatura de rede, mensagem de log ou IOC específico para detectar tentativas de exploração deste CVE. Como indício indireto, reloads inesperados de dispositivos configurados como DHCP relay agent com encapsulação de option 82 habilitada, correlacionados com tráfego DHCPv4 anômalo (pacotes discover de tamanho atípico, próximo do limite de MTU, com option 82 grande) merecem investigação, mas não há confirmação de que esse padrão seja um indicador confiável e exclusivo de exploração.