CVE-2017-12240

Buffer overflow no subsistema de relay DHCP (DHCPv4) do Cisco IOS e IOS XE que permite execução de código arbitrário ou reload forçado (DoS) via pacote malformado, sem autenticação. O CVSS 9.8 é enganoso porque o vetor só existe em dispositivos configurados explicitamente como DHCP relay agent — a maioria dos roteadores/switches Cisco em produção não está nessa condição por padrão.

A falha é classificada como CWE-20 (Improper Input Validation) e ocorre no processamento de pacotes DHCPv4 pelo subsistema de relay. Quando um dispositivo Cisco IOS/IOS XE está atuando como relay agent, ele intercepta pacotes DHCP de clientes, insere o próprio endereço no campo giaddr e reenvia a mensagem ao servidor DHCP configurado. O tratamento de campos/opções desse pacote contém uma condição de buffer overflow — o advisório da Cisco não detalha a estrutura interna exata do bug nem o offset de memória afetado, apenas confirma a natureza do overflow e associa a falha aos bug IDs internos CSCsm45390 e CSCuw77959.

O atacante controla o conteúdo do pacote DHCPv4 enviado ao dispositivo. Não há necessidade de autenticação, interação do usuário ou privilégios prévios — daí AV:N/AC:L/PR:N/UI:N no vetor CVSS. O impacto declarado é confidencialidade, integridade e disponibilidade total (C:H/I:H/A:H), compatível com execução de código no plano de controle do dispositivo de rede.

A Cisco confirma que Cisco IOS XR e NX-OS não são afetados — a falha está isolada à base de código do IOS clássico e do IOS XE.

O pré-requisito central, e o dado que a manchete CVSS não transmite, é que o dispositivo precisa estar configurado como DHCP relay agent — via `ip helper-address` (roteadores/switches IOS/IOS XE) ou `cable helper-address` (CMTS). Um dispositivo sem essa configuração simplesmente não processa o pacote no caminho de código vulnerável. A Cisco fornece o comando `show running-config | include ip helper-address` (ou `cable helper-address` em CMTS) para verificar exposição: saída vazia significa que o relay não está ativo.

Com essa configuração presente, o atacante precisa apenas alcançar a interface do dispositivo que recebe tráfego DHCP de clientes — normalmente a rede local/broadcast domain onde os hosts DHCP residem, ou qualquer ponto de onde seja possível endereçar unicast a porta DHCP do relay, dependendo da topologia. Não é necessário estar autenticado no equipamento nem interagir com um usuário. O vetor do CVSS temporal registrado pela Cisco (E:F, RL:O, RC:C) indica que existia código de exploração funcional, correção oficial disponível e confirmação da vulnerabilidade — ou seja, a exploração prática foi validada, não é apenas teórica.

O caso está no catálogo KEV da CISA, mas a data de inclusão (março de 2022) é quase cinco anos posterior à publicação original (setembro de 2017), sugerindo exploração observada tardiamente em ambientes com dispositivos desatualizados, não um exploit lançado no dia zero. O EPSS relativamente baixo (0,139) reflete que a probabilidade de exploração em massa hoje é moderada, coerente com a pré-condição de configuração específica limitando o universo de alvos.

A Cisco declara explicitamente que não existe workaround para esta vulnerabilidade — a única mitigação real é atualizar para uma versão corrigida do Cisco IOS ou IOS XE Software, listada na seção "Fixed Software" do advisory oficial (cisco-sa-20170927-dhcp). Não foi possível confirmar nesta pesquisa os números exatos de versão corrigida por trem de release; consulte diretamente o advisory ou o Cisco Software Checker para o hardware/trem específico antes de assumir que uma atualização resolve o problema.

Como controle compensatório até a atualização, o único mitigador funcional é desabilitar a configuração de DHCP relay (remover `ip helper-address` ou `cable helper-address`) nas interfaces expostas, o que elimina o caminho de código vulnerável — mas tem custo operacional real: hosts em subredes que dependem do relay para obter IP via DHCP deixam de conseguir, exigindo um servidor DHCP local por segmento ou outra forma de encaminhamento.

Não há mitigação via ACL de camada 3/4 confiável, porque o tráfego DHCP legítimo (portas 67/68) é o próprio vetor de ataque — filtrar a porta quebra a função de relay tanto quanto desabilitá-la. Não considere a ausência de exposição direta à internet como mitigação suficiente: o vetor típico está dentro da rede interna, onde qualquer host comprometido no mesmo domínio de broadcast pode atingir o relay agent.

Sinais de tentativa de exploração incluem reloads inesperados ou crashes recorrentes em dispositivos com DHCP relay configurado, especialmente correlacionados a picos de tráfego DHCPv4 anômalo nas interfaces com `ip helper-address`/`cable helper-address` ativo. Mensagens de syslog relacionadas a falhas no processo de relay DHCP ou crash dumps mencionando o subsistema DHCP merecem investigação.

Não há assinatura pública confiável de payload (a Cisco não publicou detalhes do buffer overflow nem um IOC de rede específico), então a detecção depende primariamente de monitoramento de estabilidade do dispositivo (reloads não programados) e de inspeção de pacotes DHCPv4 malformados ou com opções fora do padrão destinados a interfaces relay — não existe padrão de assinatura definitivo disponível nas fontes consultadas.