CVE-2010-3035
Priorize a correção. Ela está sob exploração confirmada pelo CISA.
Apply updates per vendor instructions.
Resumo
Falha de tratamento de atributos BGP transitivos não reconhecidos no Cisco IOS XR (versões 3.4.0 a 3.9.1) causa reset de sessão de peering ao receber um anúncio de prefixo com um atributo desconhecido — episódio documentado publicamente em agosto de 2010 com o atributo tipo 99. Não há execução de código nem comprometimento de dados; o impacto é indisponibilidade de roteamento (queda de sessões BGP), mas em escala de backbone isso já basta para causar instabilidade de rota observável na internet.
Detalhamento técnico
A RFC 4271 exige que um roteador BGP que recebe um atributo de caminho transitivo que não reconhece o marque como 'partial' e o propague adiante, sem derrubar a sessão. O IOS XR, nas versões afetadas, não implementava esse tratamento corretamente para determinados códigos de atributo não alocados/desconhecidos: ao encontrar o atributo, o processo BGP enviava uma mensagem NOTIFICATION e resetava a sessão de peering com o vizinho que propagou o prefixo, em vez de simplesmente marcar e repassar o atributo. A CISA classifica a causa raiz como CWE-20 (validação de entrada inadequada) — o parser de atributos de UPDATE trata um valor fora do conjunto esperado como condição de erro fatal em vez de caso degradado previsto pelo protocolo.
Como é explorada
O vetor é uma mensagem BGP UPDATE contendo um atributo de caminho transitivo com código de tipo não reconhecido pelo roteador de destino — no incidente de agosto de 2010, o atributo usado foi o tipo 99, que se propagou organicamente pela internet a partir de um AS que o originou (não foi um roteador de teste isolado; o atributo malformado se replicou de peer para peer via BGP normal, como qualquer atualização de rota legítima se propagaria). Não é necessário acesso autenticado ao roteador vítima nem configuração não padrão: qualquer sessão eBGP/iBGP estabelecida e ativa é suscetível, bastando que o atacante (ou um AS de trânsito comprometido/mal configurado) consiga fazer esse prefixo alcançar o roteador IOS XR vulnerável através da malha de peering.
Versões
Como se proteger
A correção definida pelo fornecedor está associada ao Bug ID Cisco CSCti62211, referenciado no advisory oficial da Cisco; a versão exata de IOS XR que corrige o comportamento não está detalhada de forma acessível nas fontes consultadas para esta página — consulte diretamente o advisory da Cisco e o Bug ID para confirmar o release-alvo antes de decidir não atualizar. Como paliativo, o próprio mecanismo do protocolo (RFC 7606, que formalizou o tratamento de 'atributo malformado' via 'treat-as-withdraw' em vez de reset de sessão) tornou esse tipo de bug em roteadores modernos menos catastrófico — mas isso depende da implementação de cada fornecedor, não é algo configurável no IOS XR afetado. Filtro de prefixos ou de atributos BGP anômalos em roteadores de borda (rejeitar UPDATEs com atributos de tipo não alocado) reduz a superfície, mas é um controle operacional, não uma correção da falha em si; atualizar para uma versão de IOS XR posterior à correção do CSCti62211 é a única mitigação real.
Como detectar
Nos logs do processo BGP do IOS XR (e de qualquer implementação que registre eventos de peering), buscar mensagens de reset de sessão com causa 'UPDATE Message Error' / 'unrecognized attribute' ou notificações de erro de atributo próximas ao horário de recebimento de um prefixo específico, seguidas de flapping do peer. Em captura de tráfego BGP (ex. via MRT dumps ou route collectors como os do RIPE RIS/RouteViews), o indicador direto é a presença de um atributo de caminho com código de tipo não padrão (como o tipo 99 no incidente de 2010) em mensagens UPDATE que precedem os resets — não há assinatura de payload malicioso além dessa anomalia estrutural, e como o atributo se propaga como anúncio de rota legítimo, sistemas de detecção de intrusão de rede tradicionais não capturam o evento sem visibilidade específica de protocolo BGP.