O IETF (Internet Engineering Task Force) está se movimentando rapidamente para anular
oficialmente um problema de segurança no protocolo IPv6, o Routing Header de tamanho 0. O
problema, com potencial de criar ataques de negação de serviço era considerado desde 2005, mas
sempre foi tratado como de menor importância, até Abril desse ano.
No dia 03 de Abril, o commiter do FreeBSD, Arnaud Biondi, em conjunto com Jun-ichiro Itojun
Hagino, commiter do NetBSD, do FreeBSD, líder do KAME Project e principal desenvolvedor da
implementação BSD (a mais popular) do protocolo IPv6 e da especificação IPv6, além de
desenvolvedor do IPSec, descobriram que o problema em questão apresentava potencial de
amplificação da propagação de pacotes roteados com cabeçalho de tamanho 0.
Em testes laboratoriais que levaram 5 dias, foi descoberto que, sem muita dificuldade, um único
pacote desse tipo poderia ser amplificado em milhões de pacotes por segundo, e coordenados para
alcançar um destino todos ao mesmo tempo. Potencial para ser o maior problema de negação de
serviço da história.
Os resultados dos testes foram apresentados primeiro em listas de discussão sobre engenharia de
roteamento Internet, e suas discussões se expandem até o momento. O Projeto FreeBSD já lançou
um Security Advisory onde desabilita por padrão o recurso de Routing Header 0 no IPv6. Mas a
discussão continua, e para entender adequadamente as consequências do problema e as soluções em
discussão, resolvemos simplificar o que vem sendo discutido ao longo desse pequeno artigo.
O que é o mecanismo de Routing Header 0
O mecanismo que permite cabeçalhos de roteamento de tamanho 0, no IPv6, foi projetado para
garantir ao IPv6 o recurso de Source Routing – o que, deve ficar claro nesse momento, não tem
relação alguma com a técnica de Policy Routing onde políticas de roteamento podem sobrepor a
tabela primária de rotas, com regras baseadas na origem dos pacotes, e de acordo com tal origem
garantir que os pacotes sejam roteados por hops distintos – gateways seletivamente indicados por tal
política de roteamento.
O recurso de Source Routing no Ipv4 define por quais saltos de roteamento um pacote deve passar
antes de alcançar seu destino, e no IPv6 o Routing Header de tamanho 0 (doravante referido apenas
como RH0) tem esse mesmo propósito: possibilitar que pacotes escolham os hops de roteamento
onde devem passar, para chagar a um determinado destino.
Porquê RH0 é perigoso?
A princípio, não é perigoso. Sua motivação e uso são autênticos, apesar de pouco comum. O fato é
que nas redes IPv6 como conhecemos hoje, o mesmo em redes IPv4, a técnica de source routing é
usada apenas em ambientes especiais, e é considerada não útil, ou apenas um PoC (Prova de
Conceito, Proof of Concept).
A questão é que não há uso formal e prático para o RH0, apenas teórico. E o grande problema, que
de fato torna RH0 um problema de segurança em potencial é que não há qualquer mecanismo que
possa reconhecer ou evitar que um pacote passe quantas vezes quiser por um mesmo hop de
roteamento, antes de alcançar um destino. Destino que na prática pode ser inalcançável se os
caminhos por onde o pacote deva ser roteado for alterado ou pre-definido para se modificar de
acordo com a frequência com que passa por cada salto (roteador).
Com isso, de acordo com o Security Advisory lançado pelo Projeto FreeBSD, “Um ataque pode '
amplificar' a negação de serviço entre duas estações vulneráveis, enviando pequeno volume de
tráfego que pode consumir grande quantidade de banda entre as pontas vulneráveis, pois o pacote
pode estar montado de forma a se rotear para sempre entre cada salto de roteamento entre as
pontas”.
O desenvolvedor do FreeBSD, Paul Vixie, principal desenvolvedor do BIND, coordenador do
Internet Ssystems Consortium (www.isc.org) e coordenador da raiz-F de DNS (principal tronco de
servidores de nomes raiz da Internet, F-ROOT NAME SERVERS) ilustra que “ninguém, em lugar
algum, acha o RH0 útil para qualquer propósito, e sequer o usa; de tal forma RH0 deve ser
completamente descontinuado da especificação IPv6; eu mesmo fiz isso antes da apresentação de
CanSecWest de forma que a raiz de DNS do mundo não seja um exemplo conveniente de como RH0
pode ser perigoso”
O time de segurança do Projeto FreeBSD ainda informa que “um ataque pode usar uma ou mais
estações vulneráveis para concentrar um ataque de negação de serviço contra uma vítima, sendo
esta outra estação ou uma rede, enviando um conjunto de pacotes a cada período de 30 segundos,
e estes pacotes ser montados de forma que todos eles cheguem ao seu destino ao mesmo tempo,
dentre de um segundo ou menos.”
Os testes apresentados pelo Projeto FreeBSD junto à IETF ilustram um ataque como o mencionado
acima, no Advisory oficial do Projeto. Com isso é possível passar semanas montando pacotes e
deixando-os roteando-se pela Internet, e, uma semana depois, quando literalmente bilhões de
pacotes já estiverem na rede, todos alcançarem um mesmo destino ao mesmo tempo. As
consequências disso?
1) Um único computador ligado na rede por alguns dias pode tirar qualquer site, qualquer rede,
do ar, programando seus pacotes para chegar ao destino de uma só vez.
Após examinar com cuidado os testes apresentados pelo time de segurança do Projeto FreeBSD a
CISCO lançou seu Security Advisory, em 04 de Maio, que pode ser encontrado em:
http://www.cisco.com/warp/public/707/cisco-sa-20070124-IOS-IPv6.shtml
Neste, estudo e apresentação do problema, a CISCO chega a conclusões ainda mais caóticas sobre o
potencial do problema. O SA da Cisco informa que:
“É possível causar o crash de roteadores CISCO com IOS com apenas um pacote IPv6.”, e
também “Com esse problema é possível que uma única máquina cause o Colapso da Internet
IPv6”, e ilustra que “um único pacote pode tirar um país inteiro da Internet”.
Na lista da IETF, Jeff Roberson da CISCO Systems informam que “O mundo deve agradecer ao
Projeto FreeBSD por esse Advisory e pelos testes apresentados”, e Antony Joshua da Juniper
Networks ilustra que “Se o problema não fosse apresentado de forma tão clara pelo time de
segurança do FreeBSD, me pergunto o que aconteceria com a Internet daqui alguns anos, quando
IPv6 não puder mais ser adiado.”
Biondi ilustra que “de acordo com o que vocês podem ver nos slides em anexo, um único pacote de
90 bytes após ser roteado por 32 segundos em endereços diversos da Internet – e isso é um
ambiente real, testes de vida real em roteadores reais, e os administradores desses roteadores nem
imaginam que esse teste foi feito – temos ao longo de 40 round-trips 4Mbit/s chegando a um único
destino, e com adicionais 16MBytes de tráfego armazenados no caminho até o destino daquele
(agora, aqueles) pacote(s). Bem-vindos ao caos.”
O restante da apresentação ilustra mais o problema. O slide pode ser obtido em:
http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf
Ebalard apresenta uma forma prática de tirar todo o DNS do mundo do ar, com apenas um pacote,
propagado a cada poucos segundos, de uma única estação na rede IPv6. Vixie, pouco confortável
com o fato do DNS do mundo inteiro ter sido usado como exemplo prático do quão grande o Caos
pode se tornar, informou que “estamos filtrando com IPFW2 todo rounting header 0 do IPv6, já
que não pudemos reiniciar os servidores ainda após o SA do Projeto FreeBSD, que requer
recompilçao do kernel e reboot do sistema.”
Conforme aponta a apresentação e Vixie confirma, toda a infra-estrutura DNS do mundo, bem
como os nós centrais de roteamento IPv6, usam sistemas BSD, em especial FreeBSD.
Abordagem FreeBSD e OpenBSD
O Projeto FreeBSD e o Projeto OpenBSD tratam de forma distinta o problema, mas concordam que
RH0 deva ser desativado no kernel. O OpenBSD remove o roteamento de RH0 incondicionalmente,
como indicado no patch oficial:
ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.0/common/012_route6.patch
Enquanto o Projeto FreeBSD desativa RH0 por padrão no kernel, mas entende que em situações
muito peculiares, o administrador de redes por querer utilizar esse recurso, e permite que este seja
reativado a qualquer momento, com intervenção explícita do administrador, através da MIB sysctl
net.inet6.ip6.rthdr0_allowed, que recebe valor booleano, como indicado no ADV:
http://security.freebsd.org/advisories/FreeBSD-SA-07:03.ipv6.asc
Abordagem Linux
No kernel 2.6.21 uma abordagem similar foi tomada, desativando RH0 no kernel. Porém, Ebalard
apontou na CanSecWest Conference que “no Linux a situação é um pouco diferente; ainda pior, de
fato; além de sofrer a mesma vulnerabilidade, um erro de cálculo na forma como RTA_MAX é
tratado, ao invés de RTN_MAX em dn_fib_propos[] pode potencialmente ser explorado de forma
parecida, e causar um DoS nas mesmas proporções, mas estamos falando de outro problema, e
este poderia ser amplificado apenas entre múltiplas estações Linux, já que nenhum outro sistema
sofre desse erro. No kernel 2.6.21.r6 do Linux trataram esse cálculo, com algumas mudanças no
arquivo fib_semantics.c, mas o problema não foi solucinado. Apenas amenizado. No Linux o
potencial de exploração é ainda maior, e esse segundo problema, exclusivo do Linux,
aparentemente será corrigido apenas no kernel 2.6.22 no RC3, ou superior, pois no 2.6.22rc2
ainda não há a correção.
Porém, vamos nos ater ao RH0, pois para nossa sorte não há infra-estrutura global de Internet
rodando sobre Linux, então vamos nos preocupar menos com o RTA_MAX e voltar ao RH0”
Ações do IETF
O Internet Engineering Task Force respondeu a apresentação na CanSecWest Conference com um
draft que propõe a descontinuação imperativa do uso de RH0 no IPv6. Essa proposição do IETF
pode ser analisada aqui:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-rh0-00.txt
Considerando que roteamento por origem com RH0 pode ser utilizado de diversas formas, a maioria
delas indesejáveis, o IETF chega a um senso comum e indica que:
1) Implementações de roteamento por origem como definido pela RFC 791 e pela RFC 2460 é
opcional, e qualquer sistema que implementa uma forma de omitir ou não oferecer esse
recurso continua sendo considerado um sistema plenamente compatível com a RFC 791 e
RFC 2460, respectivamente, com tanto que esse comportamento possa ser modificado, se
explicitamente desejado pelo administrador de sistema;
2) Implementações do protocolo IP que continuem suportando roteamento por origem
DEVEM, imperativamente, oferecer um mecanismo administrativo para desativar esse
recurso, se ele estiver habilitado por padrão;
3) Implementações IP que suportem roteamento por origem são indicadas a ter o recurso
desabilitado por padrão.
4) Implementações IP que não incluem roteamento por origem ou as tem desabilitado, devem
retornar um erro ICMP apropriado, indicando ter encontrado uma opção desconhecida,
como indicam as RFC 791 e RFC 2460 respectivamente.
O IETF ainda alerta que, nenhum sistema deve filtrar source routing por padrão, seja IPv6 ou IPv4,
pois isso pode quebrar recursos já em uso na Internet ou recursos vindouros. O único filtro por
padrão que deve ocorrer é de Routing Header 0.
Joe Abley do IETF ainda mencionou que o problema de amplificação de DoS é apenas um dos
problemas do RH0. Fora ele, mapeamento remoto de redes e sobreposição a regras de firewall
também são possíveis com o RH0.
A única pessoa que parece ainda defender o uso de RH0 é Itojun, que diz que “recursos como os
implementados pelo traceroute -g podem ser melhorados com RH0; o que temos que fazer é
projetar RH0 de forma a oferecer todas suas vantagens potenciais sem ter feitos co-laterais
negativos, ao invés de descontinuar o recurso”.
Ninguém concorda com Itojun, exceto por Jaroen Massar do IETF que concorda com Itojun que
seria bom se fosse possível manter RH0 de forma segura, mas que não há como isso acontecer, e
devido à pouca usabilidade prática do recurso, defende que RH0 seja aposentado imediatamente. E
defende ainda que o recurso equivalente, em IPv4 seja também pouco incentivado, mas quer
preparar um Draft exclusivo para tratar a abordagem IPv4.
Adequação dos sistemas as indicações atuais do IETF
Considerando o senso comum do que o IETF concorda, o único sistema que cumpre todas essas
indicações é o FreeBSD, que implementa o recurso de Source Routing IPv6 e IPv4 no kernel, mas
que não os tem ativado por padrão; oferecendo no entanto mecanismos que podem habilitar ou
desativar tais recursos a qualquer momento, pelo usuário.
Linux não implementa o recurso ou o removeu imperativamente, enquanto no OpenBSD o recurso
está como indicado pelo IETF para IPv4, mas para IPv6 está implementado, mas desativado por
padrão, e não há forma de ativar sem a recompilação do kernel. Massar ilustra que “recompilar
kernel não pode ser considerado um mecanismo de ativação do recurso”, considerando a maneira
como o OpenBSD desativou a implementação que já existia. Eu particularmente discordo.
Recompilar kernel deve sim, ser considerado mecanismos de ativação de recurso. Mas o problema
ao meu ver é que não basta uma opção no kernel. A modificação requer intervenção manual no
código.
Muitos ficaram incomodados
A conferência CanSecWest de forma geral é pouco interessante, todos os anos. Esse ano não foi
diferente na maioria das apresentações, que abordavam assuntos sobre “Como hackear Apple
Macintosh – através do navegador Safari”, “Análise da exploração VoIP da Nortel” e até
“Hackendo Nintendo Wii”. Além de outros assuntos pouco encorajadores como “Ataques de
engenharia reversa com JavaScript” (!!!) ou “Eu sei o que a sua empresa fez, no verão passado”.
Normalmente parece um encontro de meninos que vivem no IRC, felizes por “pacotar” redes por
alguns segundos. E a apresentação sobre IPv6, de Biondi e Ebalard parecia ser mais uma, no mesmo
nível, com o assunto “Diversão com Cabeçalhos de Roteamento de tamanho 0”.
Mas essa se mostrou a mais importante, pelas adequadas ilustrações práticas do problema e também
pelas considerações complementares feitas por representantes da Cisco Systems e da Juniper
Networks, na mesma apresentação. Ao longo da apresentação, notamos que eles, em especial
Ebalard, não fizeram o menor esforço para não atacar e apontar nomes e fatos.
Itojun ficou especialmente incomodado com as afirmações que “os projetistas e desenvolvedores
do IPv6 não aprenderam com as falhas do IPv4, e voltam a repetí-las, de forma ainda mais
perigosa”. Apesar de Biondi e Vixie serem ambos companheiros no desenvolvimento do Projeto
FreeBSD, Biondi não conseguiu evitar que seu parceiro de apresentação, Ebalard, provocasse
também o desconforto de Vixie, quando apresentou a ilustração de ataque contra os servidores DNS
raiz do mundo. Vixie comentou que não estava mais vulnerável, e Ebalard tirou da cartola, no
último minuto, uma mini (psuedo?) apresentação com o título “Tirando o Kernel.org do ar, sob o
nariz do ISC, e com problemas de segurança que só o Linux oferece à seus usuários” onde Ebalard
apontava que com RH0 combinado com o problema de RTA_MAX todos os servidores na rede
IPv6 do kernel.org (site que formenta e hospeda os servidores que fornecem os kernel do Linux ao
mundo) poderiam causar um DoS que os tiraria do ar em 20 segundos. Em baixo do nariz do ISC,
que hospeda gentilmente toda a infra-estrutura do kernel.org.
Todos adeptos de sistemas livres ficaram também incomodados quando Ebalard apontou que apenas
o IOS da Cisco poderia filtrar RH0, desativar RH0 por tipo ou desativar RH0. Enquanto nas
soluções livres, Linux conseguia filtrar RH0 por tipo, com a opção ipv6header do Netfilter,
enquanto FreeBSD conseguia com ext6hdr do IPFIREWALL, mas nenhum podia desativar (nota:
FreeBSD pode agora, após o Security Advisory ter sido divulgado), e ainda, IPF não podia filtrar e o
PF do OpenBSD foi considerado “IPv6-ignorant”. Sobre o PF ainda, Ebalard mencionou “Feliz
quem usa PF no FreeBSD, pois Max Laier adicionou algum suporte eficiente a IPv6 no PF. Que
não existe no PF do OpenBSD. Ainda assim PF não é capaz de filtrar RH0, no FreeBSD. Menos
ainda no OpenBSD.”
Conclusão.
A primeira conclusão que tenho, é que finalmente, uma conferência CanSecWest valeu a pena ser
presenciada.. Obviamente, não por presenciar alguém invadindo um Mac OS X através do Safari
para ganhar muitos mil dólares. A acareação entre engenheiros e desenvolvedores IPv6 foi
memorável.
Apesar do IETF reconhecer e agradecer a importância dos testes apresentados por Biondi, em
ambiente FreeBSD, que originou o SA do Projeto FreeBSD,e dessa ser a primeira vez que vemos a
engenharia da IETF disposta a resolver um problema de design muito rápido, o que só enfatiza a
seriedade do problema, não há ainda uma conclusão se IPv6 RH0 deve ser apenas desativado ou
plenamente aposentado.
Contando com o fato de túneis 4to6 existir em praticamente toda rede IPv6 e alguns ponto de
estrutura de rede rotearem tanto IPv4 quanto IPv6, esse é um problema que, se de fato explorado,
pode acabar com a rede IPv6 e levar IPv4 indiretamente 'a mesma indisponibilidade.
Bob Beck do projeto OpenBSD, esteve presente, e não achou graça no comentário de Ebalard
quando esse disse que “Mais código e menos cerveja não faria mal ao PF”, se referindo a alguns
CDs do OpenBSD, autografados por Theo De Raadt, que estavam sendo vendidos a 50 dólares no
evento.
Sobre mim
Fyodor, autor do NMAP, eu e Deraison, autor do Nessus. Fotos tirada pelo Nico, co-worker na Sécurité.
Sou Diogo B. Avellie, formado em 2003 pela FATEC São Paulo e desde 2004 trabalho com
Segurança da Informação em Boston, MA. Escrevi esse mesmo resumo para o CISSN do CNRCCG do Canadá, onde faço especialização em Segurança da Informação – http://iit-iti.nrc-cnrc.gc.ca/.
Traduzi o trecho mais relevante do artigo, de francês para o português a pedido de Patrick
Tracanelli, para ser divulgado no site da FreeBSD Brasil. Conheci Tracanelli em um evento sobre
OpenBSD na FATEC São Paulo, e desde então mantemos contato. Essa é minha primeira
contribuição para a comunidade BSD brasileira.
As fotos aqui reproduzidas são de crédito à Nico, da companhia Francesa Sécurité, onde trabalho, na filial de Boston e não devem
ser reproduzidas sem autorização da companhia.