Zusammenfassung

  • FORT 1.6.8, veröffentlicht am 31. Mai, begrenzt originübergreifende Snapshot- und Delta-Verweise. Der Download steht nun vor dem Löschen des lokalen Arbeitsbereichs; Löschen und Einlesen hängen von einer Änderungsmarkierung ab.
  • Der schnelle Cache-Pfad gibt weiterhin ein gespeichertes Versuchsergebnis zurück. Das ist keine erneute Dateiprüfung. Ein passender Hash entscheidet auch nicht über die Berechtigung zum Neuaufbau oder über die Reaktion eines Routers.

Der Hash musste nicht falsch sein. Genau darin liegt die lehrreiche Pointe des von FORT veröffentlichten Cache-Problems: Ein echter Snapshot konnte die erwartete Prüfsumme haben, während sein Verarbeitungskontext die lokale Sicht auf einen anderen Herausgeber beschädigte.

Der veröffentlichte Fall brauchte keinen gestohlenen Signaturschlüssel des Opfers. Er betrifft delegierte Zertifizierungsstellen unter einem gemeinsamen Vertrauensanker, nicht beliebige unauthentifizierte Internetnutzer. Das Problem war nicht bloß ein gefälschtes Routing-Zertifikat, sondern eine Verkettung von Download-Erinnerung und lokalem Neuaufbau.

FORT ist ein Projekt von LACNIC und NIC.MX. Der offizielle Sicherheitshinweis stuft das Problem des gemeinsam genutzten Snapshot-Caches als hoch ein, nennt Versionen bis 1.6.7 als betroffen und 1.6.8 als gepatcht. Diese Recherche liest veröffentlichte Quellen am 14. September. Sie reproduziert keinen Angriff, misst keine installierte Flotte und macht aus dem Mai-Patch keine September-Veröffentlichung.

Der Aufrufer bekommt eine engere Regel

Im auf den Release festgelegten RRDP-Code von 1.6.7 ruft handle_snapshot zuerst delete_rpp auf. Der lokale Arbeitsbereich des Veröffentlichungspunkts wird gelöscht, danach folgt cache_download. Bei Erfolg wird parse_snapshot aufgerufen, ohne dass dieser Aufruf neue Inhalte beschafft haben muss.

Die Funktion in 1.6.8 lädt zuerst und lässt eine changed-Markierung setzen. Ein Download-Fehler führt vor diesem Löschen zum Abbruch. Das Löschen des Arbeitsbereichs, das Einlesen des Snapshots und das Löschen der Snapshot-Datei stehen innerhalb der changed-Bedingung.

Damit wird ein gespeicherter Erfolg nicht zu einer neuen Beobachtung. Stattdessen ändern sich die Bedingungen, unter denen der Aufrufer ihn verwendet. Ein aus dem Cache zurückgegebener Erfolg ohne gemeldete Inhaltsänderung ordnet diese Ersatzoperation nicht mehr bedingungslos an.

Die Metadatenparser derselben Version lehnen außerdem Snapshot- und Delta-Verweise ab, deren Origin sich von der Benachrichtigung unterscheidet. Welche fremden Ressourcen eine Benachrichtigung einbeziehen darf und wann ein lokaler Bereich neu aufgebaut wird, sind zwei verschiedene Kontrollfragen. Keine davon lässt sich mit „stärkerer Hash-Prüfung“ hinreichend beschreiben.

Was der schnelle Cache-Pfad nicht neu erfährt

Im Cache-Code von 1.6.8 wird zunächst die herunterladbare URI im Kontext des Vertrauensankers ermittelt. Die Tabelle sucht den Eintrag anhand des von uri_get_local gelieferten lokalen Pfads. Dieser sichtbare Schlüssel ist nicht wörtlich bloß eine globale HTTPS-URL.

Ist der Versuch gegenüber dem Cache-Start hinreichend neu, gibt der schnelle Pfad das gespeicherte Ergebnis zurück. Er prüft an dieser Rückgabestelle nicht erneut, ob die benötigte Datei physisch vorhanden ist.

Andere Pfade prüfen Dateien durchaus. Dazu gehören cache_check und das Bereinigen von Einträgen, deren Dateien fehlen. Aus der schnellen Rückgabe lässt sich weder ableiten, FORT prüfe niemals das Dateisystem, noch, jeder gemerkte Erfolg belege einen gerade überprüften Bestand.

Der verbliebene Pfad beweist auch keinen fortbestehenden Angriff auf die gepatchte Version. Der veröffentlichte Fix begrenzt, wie sein Aufrufer diesen Rückgabewert verbraucht. Die Quellen erklären eine Reparatur; sie liefern hier keinen neu erprobten Weg an ihr vorbei.

Download vor Löschen ist nicht Prüfung vor Löschen

Die korrigierte parse_snapshot-Funktion prüft den erwarteten Hash vor dem Einlesen des XML. Es wird nicht behauptet, abweichende Snapshot-Hashes würden akzeptiert.

Eine andere Zusicherung begrenzt jedoch die Reihenfolge. In der changed-Verzweigung löscht handle_snapshot den Arbeitsbereich und ruft danach parse_snapshot auf; dort findet die Hash-Prüfung statt. In dieser Funktion bedeutet Download-vor-Löschen deshalb nicht Validierung-vor-Löschen. Allein daraus ergibt sich keine vollständige Transaktion, die stets den letzten guten Zustand erhält.

Ebenso wenig ergibt sich daraus ein erfundener Schaden. Der vollständige Validator, seine weitergehenden Rückfall- und Wiederherstellungswege und seine abschließende Ausgabe wurden hier nicht ausgeführt. Die Reihenfolge in einem Helfer beweist keinen dauerhaften Objektverlust und erst recht keinen Verlust von Routen oder Verkehr.

Ein übereinstimmender Hash verbindet Bytes mit dem erwarteten Digest. Er ersetzt keine RPKI-Signatur- und Ressourcenprüfung, gibt keinen Freibrief zum Neuaufbau eines anderen Repository-Bereichs und legt keine Router-Policy fest.

Gleiche Origin heißt nicht gleicher Rechner

RFC 9674 aktualisierte RFC 8182 im Dezember 2024. Er verlangt dieselben Scheme-, Host- und Port-Werte für die Verweise und untersagt originübergreifende Redirects. Diese Grenze ist weder eine Unternehmenszugehörigkeit noch ein Benutzerkonto oder ein einzelner physischer Server.

Ein CDN kann weiterhin hinter der vorgeschriebenen Origin arbeiten. Der hier beschriebene Codevergleich belegt die untersuchten Snapshot- und Delta-Verweisprüfungen, kein vollständiges Audit der HTTP-Weiterleitungen oder der gesamten Konformität.

Für den Cache gibt es einen starken Betriebsgrund: Viele Clients laden Daten aus einer deutlich kleineren Zahl von Repositories. Jede Übertragung zu wiederholen oder verteilte Zustellung zu verbieten würde Last erhöhen. Die sinnvolle Trennung liegt zwischen einem gemerkten Download und einer bestimmten erlaubten Neuaufbauoperation, nicht zwischen Leistung und Sicherheit als pauschalen Gegensätzen.

Quellen