Resumen

  • FORT 1.6.8, publicado el 31 de mayo, restringe las referencias RRDP entre orígenes. La descarga pasa a preceder al borrado del espacio local y la reconstrucción queda condicionada a un cambio de contenido.
  • El camino rápido del caché sigue devolviendo el resultado de una tentativa recordada. No vuelve a acreditar la presencia del archivo; un hash correcto tampoco autoriza por sí solo una reconstrucción ni determina el resultado en un router.

Una descarga que salió bien no es un cheque en blanco para el siguiente paso. El parche de FORT permite ver esa diferencia en una operación muy concreta: cuándo un cliente puede borrar y reconstruir su copia local de un repositorio RPKI.

La explicación pública del problema admite una paradoja útil. El snapshot podía ser auténtico y su hash, correcto. No era necesario robar la clave de firma de la autoridad víctima para que sus objetos desaparecieran de la salida local del validador. El caso publicado presupone autoridades delegadas bajo una misma ancla de confianza, no cualquier usuario de Internet sin autenticar. La integridad de los bytes y la seguridad del contexto no eran la misma garantía.

FORT es un proyecto de LACNIC y NIC.MX. El aviso oficial considera de gravedad alta el problema de caché compartido, identifica como afectadas las versiones hasta 1.6.7 y señala 1.6.8 como corregida. Esta investigación del 14 de septiembre compara fuentes publicadas. No reproduce la explotación, cuenta instalaciones vulnerables ni presenta el parche de mayo como una novedad de septiembre.

Qué deja de ser incondicional

En el código RRDP fijado a 1.6.7, handle_snapshot empieza llamando a delete_rpp. Borra el espacio local del punto de publicación y después solicita el snapshot a cache_download. Si este devuelve éxito, el gestor llama a parse_snapshot sin exigir que esta invocación haya recibido contenido nuevo.

El gestor de 1.6.8 descarga primero y pide un indicador changed. Un error de descarga termina el recorrido antes de ese borrado. Solo dentro de la condición changed se borra el espacio local, se analiza el snapshot y se elimina su archivo.

El cambio no consiste en enseñar al recuerdo de una descarga a conocer el presente. Consiste en limitar lo que su consumidor puede hacer con él. Un éxito recuperado de la memoria, sin cambio señalado, ya no ordena incondicionalmente esta sustitución del espacio de trabajo.

Los analizadores de metadatos de la misma versión rechazan además las referencias de snapshot y delta cuyo origen difiere del de la notificación. Una protección restringe qué recursos puede involucrar una notificación; la otra restringe la secuencia local de reconstrucción. No son dos nombres para una comprobación criptográfica.

La memoria que sigue ahí

El código del caché conserva el retorno rápido de un resultado anterior. Tras obtener la URI descargable en el contexto de su ancla de confianza, busca la entrada mediante el camino local que proporciona uri_get_local. Esa es la clave visible en la tabla; describirla literalmente como una URL HTTPS global omitiría la construcción local.

Si la tentativa es reciente respecto al arranque del caché, se devuelve su resultado guardado. Ese retorno no vuelve a consultar si el archivo necesario sigue físicamente disponible.

Hay controles de archivos en otros recorridos, como cache_check y la limpieza de entradas cuyos archivos faltan. Sería incorrecto afirmar que FORT nunca comprueba el disco. También sería incorrecto atribuir al retorno rápido una comprobación nueva que no realiza.

Lo que permanece no demuestra un fallo del parche. El arreglo restringe los casos en que el gestor usa ese resultado para reconstruir. Esta lectura explica la reparación publicada; no descubre una forma de seguir explotándola.

Descargar antes no significa validar antes

En 1.6.8, parse_snapshot verifica el hash esperado antes de analizar el XML. Aquí no se afirma que se acepten snapshots con una huella distinta.

El orden importa, sin embargo, para otra promesa. Dentro de la rama changed, handle_snapshot borra el espacio y después llama a parse_snapshot, donde ocurre la comprobación del hash. En esta función, descargar antes de borrar no equivale a validar antes de borrar. La secuencia, por sí sola, no prueba una transacción completa que conserve siempre la última copia buena.

No se ejecutó el validador entero, ni se probaron sus alternativas de recuperación o su publicación final de resultados. El orden de este gestor no acredita una pérdida definitiva de objetos, y menos aún una pérdida de rutas o de tráfico.

La huella correcta vincula unos bytes a un valor esperado. No sustituye la validación de firmas y recursos RPKI, no otorga autoridad sobre el espacio de otro repositorio y no decide la política de validación de origen de un router.

La misma máquina no es la regla

RFC 9674, publicado en diciembre de 2024 como actualización de RFC 8182, exige el mismo esquema, host y puerto para las referencias y prohíbe las redirecciones entre orígenes. Esa frontera no coincide necesariamente con una empresa, una cuenta de acceso o un servidor físico.

Un CDN puede servir detrás del origen requerido. Esta comparación acredita los controles revisados de referencias de snapshot y delta; no audita toda la gestión de redirecciones HTTP ni certifica el cumplimiento completo del cliente.

El caché tiene una razón de peso. Muchos clientes consultan un conjunto bastante menor de repositorios. Repetir toda transferencia o prohibir la distribución mediante CDN añadiría carga. El objetivo defendible es conservar esa economía sin convertir el resultado recordado de una tentativa en permiso para cualquier operación posterior.

Fuentes