摘要

  • FORT 在五月发布的 1.6.8 中限制跨源快照、增量引用，并把下载移到本地工作区删除之前；删除和解析还需满足内容变化条件。
  • 缓存快路径仍会返回先前尝试的结果。这不是重新检查文件是否存在；哈希吻合也不能单独证明重建权限、完整事务恢复或路由器的最终动作。

同一批路由授权数据，可能仍由原持有人合法签署，却从某个验证器的本地视野里消失。先把这种消失归咎于签名造假，或者理解为注册机构收回资源，都会错过 FORT 公布的缓存问题真正发生的地方。

它令人不安的细节是：快照可以是真的，哈希也可以对得上。受害方的签名密钥不必被盗，客户端的处理上下文仍可能出错。官方案例的前提是共同信任锚下的受委托证书机构，并不是任意未经认证的互联网用户都能照此行事。

FORT 是 LACNIC 与 NIC.MX 的项目。官方安全公告将共享快照缓存投毒列为高危，标明受影响版本为 1.6.7 及以前、修复版本为 1.6.8。本文在 9 月 14 日调查发布源码：没有复现攻击，没有测量部署规模，也不把五月补丁写成九月的新版本或线上事故。

补丁改变的是谁在什么条件下重建

固定在 1.6.7 发布提交上的 RRDP 源码显示，handle_snapshot 先调用 delete_rpp，删除本地发布点工作区，再调用 cache_download。下载器返回成功后，它会调用 parse_snapshot，并不要求本次调用确实取得了新内容。

固定在 1.6.8 上的同一处理函数先下载，并要求下载器填写 changed 标记。下载报错时，函数会在这一处删除之前退出。删除工作区、解析快照和删除快照文件，被放进 changed 条件分支。

这不是给旧的成功记录赋予新知识，而是改变消费它的调用方。仅仅从缓存里取回成功、却没有报告内容变化，不再无条件命令这一段代码拆除并重建工作区。

同一版本的通知元数据解析器还会检查快照和增量引用：它们的源若与通知不同，就拒绝。一个限制通知能够借用哪里的资源，另一个限制本地重建何时发生。把两者概括成“哈希验证更强”，会抹掉真正的控制面。

缓存记住的仍是一次尝试

1.6.8 的缓存代码没有把快返回改成现场查文件。它先在信任锚上下文中取得可下载 URI，再用 uri_get_local 返回的本地路径查哈希表。这个字面键值值得说准，不能直接照搬成一条全局 HTTPS 地址。

如果尝试时间相对于缓存启动时间足够新，快路径就返回记住的尝试结果。它没有在这个返回处重新确认所需文件仍在磁盘上。

这不等于 FORT 从不检查文件。cache_check 会查；清理代码也会处理记录还在、文件却不在的情况。观察的边界是一条具体快路径，不是整个客户端所有检查的总评。

快路径仍存在，也不证明修复后的漏洞仍可利用。补丁已经改变了调用方消费这一结果的条件。本文解释公开修复的源码机制，并没有发现或验证新的绕过。

先下载，不等于先验证再删除

修复版的 parse_snapshot 会先核验预期哈希，再解析 XML。本文没有声称错误哈希被接受。

但调用顺序还限定了另一种保证。在 changed 分支里，handle_snapshot 先删除工作区，再进入 parse_snapshot 做哈希检查。因此，就这一个函数而言，“下载在删除之前”不是“验证在删除之前”，也不能单独证明它是永远保留上一份正确状态的完整事务。

这个差别不能被升级成编造的损失。调查没有运行完整验证器，没有测试更广的回退、恢复与最终输出发布。函数里的清理顺序，不足以证明校验失败后路由器一定丢失路由。

哈希吻合说明所取字节与预期摘要相符。它不是一个通知操作另一座库工作区的授权，也不是 RPKI 签名、资源范围验证或路由器策略的替代品。文件完整性与操作上下文，本来就各有任务。

同源限制不是强迫所有数据放在一台机器

2024 年 12 月发布的 RFC 9674 更新了 RFC 8182，要求通知引用的快照、增量使用相同协议、主机与端口，并禁止跨源重定向。这里的“源”不是同一家公司、同一个登录账号，也不是同一台物理服务器。

CDN 可以继续在要求的源后面提供服务。本文的源码比较确认的是所查快照、增量解析器的引用检查，没有完整审计 HTTP 重定向处理，更没有给整个客户端发一张合规证明。

保留缓存有很强的工程理由：大量依赖方需要读取数量小得多的发布库。每次都重传，或把同源误读成禁止分布式交付，会增加负载。值得坚持的是让缓存记忆与特定重建操作之间有清楚边界，不是把性能与安全简单摆成对立面。

来源