Resumo

  • Publicado em 31 de maio, FORT 1.6.8 limita referências RRDP entre origens e baixa o snapshot antes de apagar a área local. A remoção e a leitura do conteúdo passam a depender do indicador de mudança.
  • O caminho rápido do cache ainda devolve o resultado registrado de uma tentativa. Não verifica novamente a existência do arquivo; um hash correto também não autoriza qualquer reconstrução nem determina o efeito no roteador.

O conserto de FORT não elimina a memória do cache. Ele muda uma decisão mais localizada: quando o cliente pode usar o resultado de um download para apagar e reconstruir a área de um repositório.

Isso importa porque o problema publicado não exigia um snapshot falso. Os bytes podiam ser autênticos, com o hash esperado. Ainda assim, os objetos da autoridade vítima podiam desaparecer da saída local sem o roubo de sua chave de assinatura. O caso descrito envolve autoridades delegadas sob uma mesma âncora de confiança; não significa que qualquer internauta sem autenticação tenha essa capacidade.

FORT é um projeto de LACNIC e NIC.MX. O aviso oficial atribui gravidade alta ao problema de cache compartilhado, aponta as versões até 1.6.7 como afetadas e 1.6.8 como corrigida. Esta é uma investigação das fontes publicadas feita em 14 de setembro. Não reproduz a exploração, mede instalações expostas ou noticia uma versão nova de setembro.

A reconstrução ganha uma condição

No código RRDP fixado ao lançamento 1.6.7, handle_snapshot começa com delete_rpp. Apaga a área local do ponto de publicação e só depois chama cache_download. Se houver retorno de sucesso, segue para parse_snapshot sem exigir que essa chamada tenha obtido conteúdo novo.

Na versão 1.6.8, o download vem primeiro e recebe também um indicador changed. Um erro de download encerra a função antes dessa remoção. Apagar a área, interpretar o snapshot e remover seu arquivo ficam dentro da condição changed.

A diferença não transforma uma lembrança em observação atual. Ela restringe o que o consumidor da lembrança pode fazer. Um sucesso encontrado no cache, sem mudança de conteúdo informada, deixa de ordenar incondicionalmente essa sequência de substituição.

Os analisadores de metadados da mesma versão rejeitam referências de snapshot e delta cuja origem difira da notificação. Há duas decisões: quais recursos uma notificação pode envolver e quando a reconstrução local deve ocorrer. Nenhuma se reduz a reforçar o cálculo de um hash.

O retorno rápido continua sendo uma lembrança

O código do cache de 1.6.8 obtém a URI de download no contexto da âncora de confiança. Procura o registro usando o caminho local retornado por uri_get_local como chave da tabela. Essa construção não deve ser descrita literalmente como uma simples URL HTTPS global.

Se a tentativa for recente em relação ao início do cache, o caminho rápido devolve o resultado salvo. Nesse retorno, não há uma nova consulta à presença física do arquivo necessário.

Outros caminhos fazem verificações, como cache_check e a limpeza de entradas cujo arquivo desapareceu. Portanto, não se pode dizer que FORT nunca verifica o disco. Também não se pode tratar todo sucesso lembrado como se fosse uma verificação realizada naquele momento.

A permanência desse caminho não demonstra que a exploração publicada ainda funcione na versão corrigida. O reparo altera as condições em que o resultado é consumido pelo gestor do snapshot. Esta leitura explica o conserto; não anuncia um novo desvio dele.

Um hash não decide a quem cabe reconstruir

parse_snapshot, na versão corrigida, verifica o hash esperado antes de analisar o XML. Aqui não se afirma que um snapshot com hash incorreto seja aceito.

A ordem ainda exige precisão. No ramo changed, handle_snapshot apaga a área de trabalho e depois chama parse_snapshot, onde ocorre a verificação do hash. Nessa função, baixar antes de apagar não significa validar antes de apagar. A sequência isolada não prova uma transação completa que preserve sempre o último estado bom.

Não foram executados o validador completo, seus mecanismos mais amplos de alternativa e recuperação ou a publicação final de resultados. Uma ordem de limpeza nesta função não basta para provar perda permanente de objetos, de rotas ou de tráfego.

Um hash coincidente relaciona os bytes ao resumo esperado. Não substitui a validação RPKI das assinaturas e dos recursos, não autoriza um contexto a reconstruir a área de outro repositório e não decide a política de um roteador.

Mesma origem não é a mesma máquina

RFC 9674 foi publicado em dezembro de 2024 e atualiza RFC 8182. Exige o mesmo esquema, host e porta nas referências e proíbe redirecionamentos entre origens. Isso não é uma regra de empresa única, conta de acesso ou servidor físico único.

Um CDN pode continuar por trás da origem exigida. A comparação apresentada comprova os controles revisados das referências de snapshot e delta, não uma auditoria integral dos redirecionamentos HTTP nem de conformidade do cliente.

Há um argumento forte para manter o cache. Muitos clientes recuperam um conjunto menor de repositórios. Refazer toda transferência ou proibir a distribuição por CDN aumentaria a carga. O objetivo razoável é separar a economia da memória de download da permissão para uma reconstrução específica, não escolher entre desempenho e segurança.

Fontes