要約

  • Whois 1.124は8月27日に本番化され、その4日後、RIPE NCCはクライアント証明書認証で署名証明書だけを使う1.124.1を公開した。
  • 公開された修正は、接続相手の証明書配列を先頭のリーフ証明書一つに絞り、別のメンテナーに結び付く第2証明書では更新できないことを負のテストで確認している。
  • RIPE NCCは悪用の証拠を発見しなかったと述べた。この判断を検証可能にするには、対象バージョン、期間、インターフェース、ログ保全、集計件数、オブジェクト履歴との照合、通知基準をまとめた非機密の評価記録が必要だ。

Whois 1.124が本番環境に入ったのは8月27日だった。31日には1.124.1が続いた。RIPE NCCの告知によれば、差分は一つだけで、クライアント証明書認証に使う証明書を署名証明書だけに限定した。前週に報告されたセキュリティ上の脆弱性を修正するため、通常ならリリース候補環境で待つ2週間を置かなかった。

既知の認証リスクを、定例日程のために残す理由はない。緊急配備は正しい。一方、同じ告知に記された「この脆弱性が悪用された証拠は見つからなかった」という一文は、配備とは別の成果物である。前者はコードの状態を変える。後者は過去を調べた結果を表す。

公開情報から侵害や不正更新が確認されたわけではない。調査方法が短くしか説明されていないことも、結論が誤りだという根拠にはならない。ただ、否定的な結論の強さは、どこまで探したかによって決まる。

認証対象はチェーンではなく一つの身元

RIPE Databaseの説明では、クライアント証明書はREST API経由の更新を認証する手段である。利用者はX.509証明書と秘密鍵を作り、証明書をkey-certオブジェクトとして登録し、そのキーをメンテナーのauth:属性から参照する。Whoisは提示された証明書の署名を、データベースにある証明書と照合する。認証局までの信頼経路は検証しない、という注意もある。

つまり、権限を持つのはTLS通信に同梱された証明書の集合ではない。特定の証明書と、特定のメンテナー規則との結び付きである。チェーンに何枚入っていても、接続の身元は実際に署名に使われたリーフ証明書でなければならない。

8月31日付の公開commit 504fccd515caは、題名が「Multiple certificates」と簡潔だ。証明書抽出部はピア証明書の配列をX.509ラッパーへ変換した後、.limit(1)を適用するようになった。コメントは、インデックス0をリーフ、すなわち接続で実際に使われた署名証明書と説明する。証明書情報を返す診断サービスも、生の配列を独自に走査せず、同じ抽出処理を使うよう変更された。

追加された統合テストは境界を具体化する。まずOWNER-MNTに対応する証明書を作り、別のANOTHER-MNTには第2の証明書を作る。両方をテスト用キーストアに入れ、最初の証明書で接続したまま、後者が保護するオブジェクトの更新を試す。期待値は認証失敗である。第2証明書が接続に含まれても、第2のメンテナー権限を持ち込めない。

これは修正後の不変条件を示すテストだ。本番環境で同じ構成が使われた証拠でも、更新が不正に通った証拠でも、特定の利用者が影響を受けた証拠でもない。

修正内容と過去調査は別々に検証する

リポジトリを読めば、現在の判断分岐は追える。先頭のリーフだけを身元とし、追加証明書を無視し、メンテナーをまたぐ試験を拒否する。しかし「悪用なし」を評価するには、調査母集団が必要だ。

古い挙動はどの版から存在したのか。1.124の4日間だけを見たのか、それ以前まで遡ったのか。REST更新のほか、照会、診断表示、同じ抽出部を使う別経路も対象だったのか。証明書認証ログの保存期間は十分だったのか。ログは単一証明書と複数証明書の提示を区別できたのか。通過した更新をオブジェクト履歴や通知と突き合わせたのか。どの結果ならメンテナーへの連絡が必要だったのか。

ここで求めるのは生の証明書でも、氏名でも、攻撃手順でもない。公表された安心材料が、どの時間とデータに立っているかである。

規模については有力な反論がある。RIPE NCCが2024年9月に示したMD5パスワード廃止の影響分析では、有効なX.509 key-certを参照するメンテナーは29件、X.509認証による更新は年に数件だった。利用が少なければ、全件確認は現実的になりやすい。だが、この数字は2026年8月時点の件数ではなく、関連する提示がすべてログに残ったことまでは示さない。

責任ある開示にも配慮がいる。RIPE NCCの方針は、解決前の詳細公表を控えるよう研究者に求め、組織側は迅速な対応を約束する。今回の告知と負のテストは、まず修正し、その後で制御境界を見せるという順序を守っている。続く方法メモは、脆弱性の再現方法を公開せずに作れる。

公開すべきは秘密ではなく評価の枠

「クライアント証明書露出評価記録」は、影響し得るバージョン範囲、最初の本番露出時刻、修正完了時刻から始める。次に、REST更新、照会、診断、他の認証手段を分け、どの操作を調べたかを列挙する。

証拠の欄では、監査ログの種類、保持期間、相関に使える項目、重要な欠落を示す。件数は集計でよい。証明書認証要求、複数証明書提示、許可と拒否、関係するメンテナーまたはオブジェクトの範囲を数える。少数利用者の保護には幅表示が使えるが、本当にゼロならゼロと記録する。

さらに、異常な認証判断をオブジェクトの版履歴と更新通知へ結び付ける。処理結果は、想定されたテスト、拒否済み要求、正当に許可された更新、未解決事象、確認済み不正変更など、固定した分類にする。個々の身元を伏せたまま、未処理の事象が残っているかを示せる。

最後に評価日、責任者、当事者通知の基準、訂正履歴を付ける。新しい証拠が出たら、旧版を消さずに次版で結論を改める。

RIPE NCC内部にこうした資料がない、と推測する根拠はない。問題は、公表された結論に範囲が添付されていないことだ。大げさな事故報告ではなく、一枚の再利用可能な記録で埋められる空白である。

情報源