要約

  • 5 月 31 日公開の FORT 1.6.8 は、通知から異なるオリジンのスナップショットやデルタを参照することを制限する。作業領域の削除はダウンロード後に移り、内容の変更を示すフラグが条件となった。
  • キャッシュの高速経路は、記録した試行結果を引き続き返す。その結果はファイルの現存確認ではなく、ハッシュの一致も再構築の権限やルーターの動作まで保証しない。

消えたのは、発行者の権限ではなく、クライアントから見える記録かもしれない。FORT が公表したスナップショットのキャッシュ問題は、RPKI の署名だけを見ていては説明できない種類の不具合だった。

公開された事例では、スナップショットの内容は本物で、期待されたハッシュにも一致し得た。被害側の署名鍵を盗まなくても、その証明書機関のオブジェクトがローカルの検証出力から消える。前提となるのは同じトラストアンカー配下の委任された証明書機関であり、認証されていない一般の利用者が誰でも実行できるという説明ではない。

LACNIC と NIC.MX の FORT プロジェクトは、この問題を 1.6.8 で修正した。公式アドバイザリは深刻度を高とし、1.6.7 以前を影響対象に、1.6.8 を修正版に挙げる。本稿は 9 月 14 日の公開ソース調査である。攻撃の再現、導入状況の測定、9 月の新リリース報道ではない。

削除を許す条件が変わった

リリースのコミットに固定した 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 URL と言い切るのは正確ではない。

キャッシュの起動時刻に対して新しい試行なら、その試行結果を返す。この戻り値の直前で、必要なファイルが今もディスクにあるかを再確認してはいない。

ただし、FORT がファイルを一切調べないという意味ではない。cache_check はファイルを検査し、別のクリーンアップ処理はファイルがない記録を扱う。観察しているのは特定の高速経路であって、クライアント全体の検査を否定する話ではない。

残っている経路だけを根拠に、修正版でも公表された攻撃が成立すると主張することもできない。修正は、その結果を再構築に使う条件を変えている。これは修正の説明であり、新たな回避方法の発見ではない。

ダウンロード後と検証後は違う

修正版の parse_snapshot は、期待されたハッシュを確認してから XML を解析する。本調査は、ハッシュの一致しない内容を受け入れると主張していない。

しかし、作業領域を消す順序は別に確認すべきだ。changed 分岐では、handle_snapshot が領域を削除した後に parse_snapshot を呼ぶ。ハッシュの確認はその中で行われる。この関数に限れば、ダウンロードを削除より先にすることは、検証を削除より先にすることと同義ではない。最後の正常な状態を常に残す完全なトランザクションも、この順序だけでは証明できない。

それを実害の断定に変えてはいけない。ここでは完全な検証器を動かしておらず、広い範囲のフォールバック、復旧、最終的な出力公開も試していない。一つの関数の削除順序から、エラー後にルーターが経路を失うとは言えない。

ハッシュの一致は、取得したバイト列と期待値を結び付ける。別のリポジトリの作業領域を再構築する権限や、RPKI の署名・資源範囲の検証、ルーターの経路ポリシーを代わりに決めるものではない。

同一オリジンは、同じ物理サーバーではない

RFC 9674 は 2024 年 12 月の RFC 8182 更新であり、参照先のスキーム、ホスト、ポートを同じにすることと、異なるオリジンへのリダイレクトを禁止することを求める。オリジンは企業名やログインアカウントでもなく、物理サーバー一台の意味でもない。

必要なオリジンの背後で CDN を使うことは可能だ。今回のコード比較で確かめたのはスナップショットとデルタの参照チェックであり、HTTP リダイレクト処理や適合性の全面監査ではない。

キャッシュを残す理由は強い。多数の依存側が、より少ない数のリポジトリからデータを得る。毎回すべてを転送し直したり、分散配信を禁じたりすれば負荷が増える。必要なのは、ダウンロードの記憶と特定の再構築操作の間に境界を置くことであり、性能か安全性かという二者択一ではない。

参照資料