Resumo

  • A RFC 3128 combinou fragmento diminuto e sobreposição para fazer o filtro examinar um cabeçalho TCP enquanto o host podia remontar outro destino.
  • A correção exigiu que o fragmento TCP de deslocamento zero trouxesse o cabeçalho mínimo completo e manteve o bloqueio do deslocamento um.
  • O resultado dependia das regras e da implementação de remontagem; passagem pelo filtro não provava conexão concluída, serviço comprometido nem falha universal.

Havia duas verdades locais. Na borda, o primeiro fragmento apontava para uma porta autorizada a receber conexões. No destino, o conjunto completo de fragmentos podia produzir uma porta diferente. A falha de segurança estava na distância entre essas duas verdades.

O primeiro fragmento do exemplo da RFC 3128 começava no deslocamento zero e carregava pelo menos dezesseis bytes do cabeçalho TCP. Mostrava as portas, o número de sequência e os campos posteriores necessários para reconhecer o início de uma conexão. Para o filtro, era uma solicitação regular destinada a um serviço permitido.

O segundo fragmento também começava em zero, mas continha apenas oito bytes da parte de transporte. Esses bytes cobriam porta de origem, porta de destino e sequência; não alcançavam as flags TCP. O remetente podia substituir a porta de destino por outra que a política reservava a conexões de saída. Um terceiro fragmento completava o datagrama.

Se a pilha do host escolhesse os bytes da sobreposição curta, o cabeçalho final combinaria a nova porta com os campos posteriores da primeira versão. O filtro havia autorizado o cabeçalho que viu. O TCP receberia um cabeçalho que ninguém avaliara naquela forma.

A técnica explorava uma lacuna na defesa anterior. A RFC 1858 separara o ataque de fragmento diminuto, que esconde campos necessários fora da primeira peça, do ataque de sobreposição, que usa interpretações diferentes para bytes repetidos. Seu Método Indireto mandava descartar fragmentos TCP com Fragment Offset igual a um.

O deslocamento IPv4 é contado em blocos de oito bytes. Um fragmento na posição um começa logo após os oito primeiros bytes TCP. Bloqueá-lo impedia um modo conhecido de colocar as flags numa segunda peça e deixar o filtro com informação insuficiente.

Mas a substituição da RFC 3128 não começava em um. Voltava ao zero. A regra fechava a continuação imediata de um início curto, mas não verificava se toda nova peça de deslocamento zero tinha comprimento suficiente para sustentar a mesma decisão.

Essa composição é o centro histórico do documento. Não basta listar fragmentação, sobreposição e firewall como palavras-chave. O mecanismo exigia que uma primeira representação parecesse completa, que uma segunda repetisse só os bytes iniciais e que a remontagem do destino escolhesse uma combinação capaz de alterar o campo de política.

O controle estava distribuído. O remetente determinava limites, offsets e conteúdo. O filtro controlava a admissão daquilo que enxergava. A pilha IP controlava a remontagem. O TCP controlava a aceitação do segmento. O serviço controlava o efeito seguinte. Uma decisão numa camada não substituía evidência das demais.

Por isso a RFC 3128 condicionou o ataque à implementação exata de remontagem. A RFC 791 definiu os campos e a responsabilidade do destino; a RFC 815 mostrou um algoritmo prático para preencher lacunas e lidar com áreas repetidas. Ainda assim, não havia uma promessa de que cada sistema intermediário e cada host escolheriam o mesmo byte em toda sobreposição.

Essa incerteza impede duas conclusões fáceis. Não autoriza dizer que todo host era vulnerável. Também não autoriza o firewall a supor que o host interpretaria os fragmentos exatamente como ele. Quem encaminha ambiguidade sem normalizar ou remontar entrega a decisão final a outro programa.

A correção acrescentou um invariante de comprimento. Para TCP, se o offset é zero e o comprimento de transporte não contém o cabeçalho mínimo inteiro, o pacote deve ser descartado. O offset um continua proibido. Uma política baseada em porta e flags só pode autorizar quando esses campos mínimos estão integralmente presentes.

O invariante elimina a substituição curta do exemplo. Ele não resolve todas as ambiguidades IPv4, não obriga remontagem completa em toda borda e não demonstra que os produtos adotaram a recomendação. Tampouco transforma admissão em invasão: ainda faltam aceitação TCP, serviço em escuta, progresso do handshake e comportamento aplicativo.

Os documentos posteriores escolheram limites mais rígidos em contextos específicos. A RFC 5722 exigiu que o IPv6 descartasse o datagrama inteiro ao encontrar sobreposição. A RFC 7112 exigiu a cadeia completa de cabeçalhos no primeiro fragmento IPv6. A RFC 6274 retomou a segurança IPv4 e a RFC 8900 descreveu a fragilidade operacional de fragmentos atravessando middleboxes inconsistentes.

Esses textos não são prova de um incidente de 2001. Eles preservam a lição arquitetural: a camada que aplica a regra e a camada que consome o objeto precisam concordar sobre sua representação. Caso contrário, cada uma pode estar correta localmente e o caminho permanecer inseguro.

O mesmo formato de falha aparece em normalização de URL, decodificação repetida e combinação de campos duplicados. Não são a mesma vulnerabilidade, mas fazem a mesma pergunta: os bytes que justificaram a permissão continuam iguais quando a aplicação age?

A resposta da RFC 3128 foi modesta e duradoura. O log do filtro prova a visão do filtro. Não prova qual porta chegou ao TCP, se uma conexão se completou ou se houve dano. Entre o ato de permitir e o efeito há uma cadeia de reconstrução que precisa ser observada, testada e preservada.

Fontes