CVE-2017-6736
Priorize a correção. Ela está sob exploração confirmada pelo CISA e tem prova de conceito pública.
Apply updates per vendor instructions.
Resumo
Falha de buffer overflow (CWE-119) no subsistema SNMP do Cisco IOS e IOS XE, parte de um lote de nove CVEs divulgadas no mesmo advisory (cisco-sa-20170629-snmp). Um atacante que já possua a community string SNMP read-only (v1/v2c) ou credenciais válidas de usuário SNMPv3 pode enviar um único pacote SNMP malformado e executar código arbitrário ou forçar reload do equipamento. Está no catálogo KEV da CISA com exploração confirmada e existe PoC pública funcional, o que eleva o risco prático apesar de exigir acesso autenticado prévio.
Detalhamento técnico
A falha está no processamento, pelo agente SNMP do IOS/IOS XE, de objetos de um conjunto específico de MIBs legadas e proprietárias da Cisco: ADSL-LINE-MIB, ALPS-MIB, CISCO-ADSL-DMT-LINE-MIB, CISCO-AUTH-FRAMEWORK-MIB, CISCO-BSTUN-MIB, CISCO-MAC-AUTH-BYPASS-MIB, CISCO-SLB-EXT-MIB, CISCO-VOICE-DNIS-MIB, CISCO-VOICE-NUMBER-EXPANSION-MIB e TN3270E-RT-MIB. Todas essas MIBs ficam habilitadas por padrão sempre que o SNMP está ativo no dispositivo, mesmo que não apareçam completas na saída do comando show snmp mib.
O CWE-119 (restrição inadequada de limites de buffer) ocorre porque o código que trata as requisições GET/GETNEXT/SET para os OIDs dessas MIBs não valida corretamente o tamanho dos dados recebidos antes de copiá-los para um buffer interno. O atacante controla o conteúdo do pacote SNMP — OID solicitado e, dependendo do vetor, o valor associado — e consegue sobrescrever memória adjacente no processo do agente SNMP, que no IOS roda com privilégios de sistema (não há isolamento de processo como em um SO convencional).
A advisory da Cisco agrupa nove CVEs (6736 a 6744) sob o mesmo mecanismo de estouro, cada uma mapeada a Bug IDs distintos — indício de que são pontos de código diferentes dentro do mesmo subsistema, afetando MIBs ou caminhos de parsing distintos, mas com a mesma classe de falha e o mesmo vetor de exploração via pacote SNMP.
O PoC público (artkond) demonstra a exploração completa em um Cisco 2811 ISR rodando IOS 15.1(4)M12a, injetando shellcode MIPS através do payload SNMP e desviando o fluxo de execução para código controlado pelo atacante — prova de conceito de que o overflow é explorável para execução de código, não apenas para negação de serviço.
Como é explorada
O vetor é um único pacote SNMP (via UDP, IPv4 ou IPv6) endereçado à interface onde o agente SNMP do dispositivo escuta. A pré-condição crítica, que a manchete de CVSS 8.8 esconde, é que o atacante precisa de autenticação prévia: a community string read-only para SNMPv1/v2c, ou credenciais de usuário válidas para SNMPv3. Não há bypass de autenticação nesta falha — é estritamente pós-autenticação SNMP.
O PoC do repositório artkond/cisco-snmp-rce ilustra o mecanismo: o exploit é dependente de firmware, com shellcode MIPS e offsets calculados para uma imagem específica (C2800NM-ADVENTERPRISEK9-M, versão 15.1(4)M12a). Adaptar o exploit para outra imagem ou plataforma exige reengenharia dos offsets e do layout de memória daquele binário — não é um exploit genérico ponto-e-clique contra qualquer IOS. O exploit-db 43450 replica esse PoC.
A presença no catálogo KEV da CISA (adicionada em 2022-03-03) confirma exploração ativa em algum momento, mas as fontes consultadas não detalham campanhas específicas nem o TTP usado por atacantes reais — apenas que a exploração foi observada. Um exploit bem-sucedido entrega controle total do dispositivo de rede (execução de código arbitrário) ou, no mínimo, causa reload — que já é disruptivo para infraestrutura crítica de roteamento.
Versões
Como se proteger
A correção definitiva é atualizar para uma versão fixa de Cisco IOS ou IOS XE. A Cisco não publicou, no advisory, uma lista única de números de versão corrigidos — a checagem é feita por trem de release através do Cisco IOS Software Checker vinculado ao próprio advisory (cisco-sa-20170629-snmp), pois o lote de nove CVEs afeta releases distintos por plataforma.
Se a atualização não for viável imediatamente, o workaround publicado pela Cisco é excluir as MIBs vulneráveis (a lista completa de dez MIBs citada na seção técnica) das views SNMP configuradas no dispositivo, negando acesso aos seus subtrees de OID. A Cisco recomenda implementar a lista de exclusão completa, já que nem todas as MIBs habilitadas aparecem em show snmp mib — um levantamento incompleto deixa MIBs vulneráveis expostas sem que o administrador perceba. Esse workaround tem custo operacional: qualquer monitoramento ou automação que dependa dessas MIBs específicas para coleta de dados perde essa telemetria.
Controles compensatórios adicionais: restringir acesso SNMP por ACL de gerência a IPs de administração confiáveis, migrar de SNMPv1/v2c para SNMPv3 com authPriv, e desabilitar SNMP inteiramente se não for usado. O que NÃO mitiga: fortalecer ou trocar a community string não resolve, pois a falha não depende da força do segredo — qualquer string ou usuário válido, mesmo robusto, é suficiente para acionar o overflow. A vulnerabilidade está no parsing, não no controle de acesso.
Como detectar
Não há assinatura de rede confiável e genérica: a exploração ocorre em um único pacote SNMP UDP autenticado, e o payload malicioso está embutido em campos de OID/valor que variam por firmware-alvo, dificultando uma regra simples. Sinais indiretos a observar: reloads inesperados de dispositivos correlacionados no tempo com tráfego SNMP GET/GETNEXT/SET recebido de origens não usuais; arquivos de crashinfo gerados após reload sem causa administrativa conhecida; requisições SNMP direcionadas a OIDs sob as dez MIBs listadas partindo de IPs fora do range de gerência esperado; e uso da community string RO ou de usuários SNMPv3 fora do padrão normal de acesso. Captura de pacotes na porta UDP 161 com inspeção do payload SNMP (tamanho de campos anômalo) é o único método com alguma confiabilidade, mas exige análise manual — não há indicador único e definitivo de tentativa de exploração nas fontes disponíveis.