Summary

  • FORT 1.6.8, released on 31 May, limits cross-origin snapshot and delta references and downloads a snapshot before deleting its local repository workspace. The deletion and parsing now depend on a content-change flag.
  • The reviewed cache fast path still returns a recorded attempt result. The repair does not make that result a fresh file-presence check, nor does a matching snapshot hash establish who may trigger a rebuild or what a router will do.

The unsettling part of FORT’s published cache-poisoning account is that the snapshot could be genuine. Its hash could match. The victim’s signing key did not have to be stolen for the validator’s local view of the victim’s objects to disappear. The published case involves delegated certification authorities under a common trust anchor, not any unauthenticated Internet user.

That is an availability problem assembled from otherwise useful pieces, not simply a forged routing certificate. A downloader remembers work it has already done. A repository handler replaces a local workspace. A certificate traversal discovers another notification. The trouble lies in treating a success remembered in one context as sufficient evidence for an operation in another.

FORT, a project of LACNIC and NIC.MX, shipped a repair in 1.6.8. The official advisory rates the shared-snapshot problem high, lists versions through 1.6.7 as affected and names 1.6.8 as patched. This article examines those published sources on 14 September. It does not report a new September release, reproduce an attack or establish how many deployed validators were affected.

The useful change is in the caller

A comparison of the release-pinned RRDP source makes the repair more specific than a reassuring version number.

In 1.6.7, handle_snapshot first calls delete_rpp to remove the local repository publication-point workspace. It then asks cache_download for the snapshot. A successful return is followed by parse_snapshot, regardless of whether this call obtained fresh content. Deletion has already happened before the downloader answers.

The 1.6.8 helper reverses that first dependency. It downloads first, asks the downloader to fill a changed flag and exits on download error. Only inside the changed branch does it delete the workspace, parse the snapshot and remove the snapshot file. In this helper, a remembered success without a reported content change is no longer an unconditional command to tear down and rebuild the workspace.

The same release also rejects snapshot and delta references whose origin differs from the notification’s origin. These are two different protections: limit which repository’s resources a notification can enlist, and limit when the snapshot handler performs destructive local replacement. Neither is adequately described as “the hash was strengthened”.

Memory is not a fresh observation

The cache source is worth reading alongside that caller change. The fast return has not become a disk check.

After obtaining the downloadable URI in its trust-anchor context, the cache finds a node using the local path returned by uri_get_local as its hash-table key. If the attempt is recent relative to the cache’s startup, it returns the saved attempt result. This is a literal source observation; calling the key simply a global HTTPS URL would miss the local-path construction shown in this release.

Other paths do check files, including cache_check and cleanup of nodes whose files have disappeared. It would be wrong to turn the fast-path distinction into a claim that FORT never checks the filesystem. It would be equally wrong to describe every saved success as a new observation that the required artifact is physically present.

Nor does this remaining fast return demonstrate that the repaired exploit still works. The published repair changes the conditions under which its caller consumes that return. The advisory and the pinned code support an explanation of the fix, not a newly discovered bypass.

A hash has a narrower job

The patched parse_snapshot validates the expected snapshot hash before parsing the XML. Integrity checking remains present; no acceptance of a mismatched snapshot is alleged here.

There is a further boundary in the source order. In the changed branch, handle_snapshot deletes the workspace and then calls parse_snapshot, where that hash check occurs. Download-before-delete is therefore not validate-before-delete in this helper. It is not, by itself, proof of an entire last-known-good transaction.

That observation must stop short of an invented incident. This investigation did not run the complete validator, test its broader fallback or recovery, or observe its eventual output publication. A helper’s cleanup order cannot establish that a failed check makes routers lose routes. It establishes which assurance this particular sequence does—and does not—provide.

A matching hash says that the retrieved bytes match the expected digest. It does not grant a notification permission to involve an unrelated repository, replace RPKI signature and resource validation, or prescribe a router’s origin-validation policy. Those decisions sit on different operating surfaces.

The origin boundary is not a ban on CDNs

RFC 9674, a December 2024 update to RFC 8182, requires the same scheme, host and port for the notification’s snapshot and delta references and disallows cross-origin redirects. Same origin does not mean one physical server, one legal organisation or one logged-in account. A CDN can serve behind the required origin.

The source comparison here proves the reviewed snapshot and delta parser checks. It is not a complete audit of HTTP redirect handling or all standards compliance.

There is a serious case for keeping the cache. RRDP was built for a system in which many relying parties retrieve a much smaller set of repositories. Repeating every transfer or banning distributed delivery would trade one failure mode for unnecessary load. The sensible distinction is between remembering a download and authorising a particular local rebuild—not between caching and security.

Sources