CVE-2018-0173

Falha de negação de serviço no agente de retransmissão DHCP (DHCP relay) do Cisco IOS e IOS XE, explorável remotamente e sem autenticação, que pode derrubar (reload) o roteador ou switch afetado. Só importa para dispositivos que atuam como relay DHCP com inserção de option 82 habilitada — a maioria dos equipamentos Cisco em produção não usa essa configuração, o que restringe bastante a superfície real de exposição apesar do CVSS alto.

A falha (CWE-20, validação de entrada incompleta) está na rotina que remove a option 82 inserida pelo próprio relay antes de encaminhar a resposta DHCPOFFER de volta ao cliente. Quando o relay recebeu originalmente uma option 82 do cliente, ele a encapsula dentro de uma nova option 82 que adiciona; ao processar a resposta do servidor, ele usa memset para limpar a memória antes e depois da option 82 original do cliente, partindo do pressuposto de que a option 82 adicionada pelo agente encapsula totalmente a original.

Segundo a análise da Tenable (que descobriu a falha junto com CVE-2018-0172 e CVE-2018-0174, vulnerabilidades irmãs no mesmo subsistema), esse pressuposto quebra se o cliente enviou uma option 82 com comprimento inválido (maior do que deveria). Nesse caso o tamanho da option 82 do cliente excede o da option 82 inserida pelo agente, e o cálculo do offset 'depois' para o memset produz um valor absurdamente grande, causando um access violation e o reload do dispositivo.

O atacante controla o conteúdo e o comprimento da option 82 dentro de um pacote DHCPv4 (tipicamente um DHCPDISCOVER) enviado ao relay. O gatilho de fato só disparado depois que esse pacote transita pelo servidor DHCP e retorna como DHCPOFFER — por isso o nome 'Relay Reply DoS': o erro ocorre no processamento da resposta do servidor, não do pacote inicial em si.

Pré-condições reais, segundo o próprio advisório da Cisco: o dispositivo precisa estar configurado como agente de relay DHCP (interface com ip helper-address, ou cable helper-address em cBR-8) e configurado para inserir option 82 (ip dhcp relay information option-insert ou equivalente). Sem essas duas configurações simultâneas, o dispositivo não é vulnerável, independentemente da versão de software. Além disso, o ambiente precisa ter um servidor DHCP real que aceite e devolva a option 82 encapsulada — a validação desse comportamento é dependente do servidor.

O vetor de ataque é um pacote DHCPv4 malformado (option 82 com comprimento inválido) enviado ao relay; o relay encaminha ao servidor, o servidor responde com DHCPOFFER, e é nesse processamento de retorno que o access violation ocorre. A complexidade de exploração é baixa (AC:L, sem interação do usuário, sem autenticação) uma vez que as pré-condições de configuração estejam satisfeitas — não exige credenciais nem posição de man-in-the-middle, apenas capacidade de enviar tráfego DHCP que chegue à interface configurada como relay.

A CVE está no catálogo KEV da CISA, confirmando exploração ativa observada, mas as fontes consultadas não detalham a campanha, o ator ou o contexto específico dessa exploração — apenas o registro no catálogo.

O advisório da Cisco (cisco-sa-20180328-dhcpr2) afirma explicitamente 'No workarounds available' — não existe configuração paliativa reconhecida pelo fornecedor. A única correção é atualizar para uma versão de Cisco IOS ou IOS XE que já traga o fix (Cisco Bug ID CSCvg62754); a Cisco distribui a lista de releases fixas por meio do Cisco Software Checker vinculado ao advisório, e as fontes disponíveis aqui não trazem essa tabela de versões, então não é seguro apontar um número específico sem consultar o Software Checker diretamente.

Como controle compensatório real, dado que não há workaround oficial, a opção prática é desabilitar a inserção de option 82 (remover ip dhcp relay information option-insert / option server-id-override / ip dhcp relay information option) em interfaces expostas a redes não confiáveis, ou remover a função de relay DHCP (ip helper-address) dessas interfaces quando ela não for estritamente necessária. Isso elimina a pré-condição de exploração, mas tem custo funcional: perde-se o rastreamento de porta/circuito que a option 82 fornece para segurança e para DHCP snooping downstream — avalie se essa informação é usada por controles de segurança de camada 2 antes de desativá-la.

Equipamentos OEM que embutem IOS/IOS XE (como switches Rockwell Automation Stratix/ArmorStratix, cobertos pelos advisórios ICS-CERT ICSA-18-107-04 e ICSA-18-107-05) seguem o mesmo cronograma de patch do fornecedor de base, mas dependem do fabricante do equipamento para disponibilizar o firmware atualizado — o prazo de correção nesses casos costuma ser mais longo que o da Cisco diretamente.

As fontes consultadas não descrevem assinatura de rede ou padrão de log específico para detectar tentativas de exploração desta CVE. O sintoma observável é o reload inesperado do dispositivo relay DHCP; em ambientes que possuem essa configuração, reloads não programados correlacionados com tráfego DHCP anômalo (options 82 com comprimento fora do padrão) merecem investigação, mas não há um IOC ou string de log documentado nas referências disponíveis — trate a ausência de sinal confiável como informação relevante para quem está caçando esta falha retroativamente.