XRP Ledger を運用しているノードオペレーターには、迅速な対応が求められている。Ripple のエンジニアリングディレクターである Vijay Khanna 氏は、インフラプロバイダーに対し、7 月 31 日にバリデータのマニフェストフラッドがネットワークを襲ったことを受けて、8 月 2 日に XRP Ledger ノードのアップグレード を完了し、xrpld バージョン 3.2.1 へ更新するよう促した。インシデントの間もレジャーはブロック生成を継続していたが、この出来事により、Ripple が今回のホットフィックスで封じ込めようとしているリソース枯渇の弱点が露呈した。
Summary
主なポイント
- 7 月 31 日のバリデータ・マニフェストフラッドを受け、Ripple は 8 月 1 日に緊急ホットフィックスとして xrpld 3.2.1 をリリースした。
- イベント期間中も XRP Ledger は通常どおりレジャーをクローズし続け、資金の損失、トランザクションの改ざん、コンセンサスの失敗は確認されていない。
- 新たに 4 つのセーフガードが導入され、マニフェストサイズ、メッセージバッチサイズ、未知のバリデータキーに対するキャッシュの増加、および信頼されていないデータの外向き共有に上限が設けられた。
- オペレーターはアップグレードを行い、xrpld が稼働していることを確認したうえで、パッチ適用前から残っているマニフェストを消去するために、サービスをもう一度再起動する必要がある。
- Ripple は 2 月 18 日にパッケージ署名用の GPG キーをローテーションしているため、オペレーターはアップデートを正しくインストールするために新しいキーを信頼済みに設定しなければならない。
XRP Ledger ノードアップグレードが必要になった理由
今回のフラッドは、バリデータマニフェストを標的としていた。マニフェストとは、バリデータの恒久的なマスターアイデンティティと、日々のバリデーション通信に用いる一時キーを結びつける、暗号署名付きの記録である。バリデータがその一時キーをローテーションするとき、マスターキーで署名された新しいマニフェストをブロードキャストし、ネットワーク全体のピアがその変更が正当であることを検証できるようにする。
修正前は、ノードは構造的に有効なデータである限り、これまで見たことのないバリデータキーに紐づくマニフェストであっても受け入れ、キャッシュし、再配布していた。ここに隙があった。誰かが大量の未知のアイデンティティを生成し、接続されているすべてのノードに対し、そのノイズを処理するだけでメモリ、ストレージ、帯域幅、処理能力を消費させることができてしまうのだ。このインシデントに紐づく公開コード記録では、これをアカウントやキーの侵害ではなく、マニフェスト伝播の欠陥として説明している。
ノードリソースへの負荷にもかかわらず、XRP Ledger Operations は、ネットワークがその間ずっと通常どおりレジャーをクローズし続けていたと報告している。この違いは重要だ。フラッドはインフラを圧迫したが、コンセンサスを妨害したり、トランザクション履歴を破損させたりする段階には至らなかった。
xrpld 3.2.1 ホットフィックスの内容
Ripple の対応は 7 月 31 日付で、8 月 1 日早朝に署名付きリリースとして公開された。6 つのコミットが 13 個の変更ファイルにまたがっており、そのうち 4 つは、未知のバリデータからのマニフェストをノードがどのように扱うかを直接制限するものだ。これらは、同種のフラッドが再びノードリソースを枯渇させることを防ぐために設計された 4 つのセーフガードを構成している。
1 つ目は、ノードがマニフェストのデコードを完了する前に、サイズ超過のマニフェストを拒否し、異常に大きなオブジェクトの処理コストを入り口で遮断する。2 つ目は、信頼されていないマニフェストが 1 つのネットワークメッセージ内で移動できる数に上限を設けるもので、ノードがデータを受信する場合も、ピア向けに準備する場合も同様だ。サイズ超過のバッチは、接続を自動的に切断することなく破棄されるため、ロールアウト期間中もパッチ適用済みノードと未適用ノードが通信を継続できる。
3 つ目の変更は、ノードのマニフェストキャッシュが保持できる未知のバリデータアイデンティティの数を制限するもので、最終的なコードではその上限が 100 に設定されている。キャッシュが一杯になると、新たな未登録キーは拒否される一方で、信頼済みおよび既知のバリデータは中断なく動作を続ける。4 つ目の調整は、信頼されていないマニフェストデータがネットワーク全体にどのように広がるかを変更し、未登録ピアからのゴシップの外向き共有を引き締める一方で、設定済みまたは承認済みバリデータに紐づくデータには手を触れない。このバランスは意図的なものだ。通常のバリデータキーのローテーションは引き続き機能するが、見知らぬ相手によるキャッシュの無制限な増大は許されない。
ノードオペレーターが今すべきこと
Khanna 氏の指示はシンプルだが、順番を守る必要がある。オペレーターは標準的なアップデートをインストールし、1～2 分待って xrpld が実際に稼働していることを確認し、そのうえでサービスをもう一度再起動する必要がある。
2 回目の再起動は形式的なものではない。パッチ適用前にオペレーターのノードが取り込み、保存していたマニフェストが、メモリやディスク上に残っている可能性があるからだ。3.2.1 をインストールすると、今後新たに受信するマニフェストの扱いは変わるが、脆弱な状態だったときにノードが取得したデータを消去するには、新たな再起動が必要になる。このステップを省略すると、コード自体は修正済みであっても、古い信頼されていないマニフェストが残り続けるリスクがある。
もう 1 つ注意すべき点は、パッケージの信頼設定だ。Ripple は 2 月 18 日に xrpld パッケージへ署名するための GPG キーをローテーションしており、その代替キーをまだ信頼済みにしていない環境では、アップデートが自動的に取得されない可能性がある。XRPL インフラを管理している人は、アップグレードが問題なく適用されると決めつける前に、署名キーの設定を確認すべきだ。
重要なのは、このXRP Ledger ノードアップグレードは、個々の保有者ではなくインフラを直接の対象としている点だ。取引所、カストディアン、ウォレットのバックエンド、データプロバイダー、そして自前で XRPL サーバーを運用しているあらゆる事業者は、自分たちのノードバージョンと再起動状況を確認する必要がある。一般の XRP 保有者は、この問題のために資金を移動したり、ウォレットキーを変更したり、新しいアカウントを開設したりする必要はない。この修正はサーバーレイヤーの内部に完結している。
被害が出なかったことがなぜ重要なのか
今回のフラッドに関連して CVE 識別子や金銭的損失の推計は公表されておらず、入手可能な証拠は、盗難やトランザクション改ざん、コンセンサス崩壊ではなく、ノードリソースとピアツーピアトラフィックへの負荷を示している。これは、巨額の価値決済を担うネットワークとしては心強い結果だが、インシデントにコストが伴わなかったという意味ではない。資金に触れないリソース枯渇攻撃であっても、サービス品質を低下させ、インフラプロバイダーを減速させ、パッチ適用が遅れた場合には追撃の足掛かりを生む可能性がある。
そこが、まだ公開記録から欠けている部分だ。XRP Ledger Operations は技術的なポストモーテムを後日公開するとしているが、8 月 2 日時点ではそのレポートはまだ出ていない。レポートが公開されるまでは、フラッドを送信した人物の正体、実際に関与したマニフェストの量、そしてネットワーク全体でノードオペレーターが 3.2.1 をどれだけ迅速に採用したかといった点は、いずれも未解明のままだ。このレポートではまた、開発者が異常なトラフィックを最初に検知したタイミングや、共有レジャー自体はブロック生成を止めなかったものの、個々のノードが到達不能になったケースがあったかどうかについても明らかにされる見込みだ。
今年に入ってから、ネットワークが強制的なソフトウェア移行を迫られたのはこれが初めてではない。3.2.1 ホットフィックスは、6 月 15 日に実施されたより大規模な 3.2.0 ロールアウトに続くもので、このときはリファレンスサーバーの名称が rippled から xrpld に変更され、それに伴う設定更新が必要になった。同じリリースによって、XRPL インフラオペレーターである David Schwartz 氏も、新しい名称とプロトコル変更に先立って自らのセットアップを移行することになった。ノードオペレーターはまた、アメンドメントの有効化に紐づく 3.1.3 の期限にも対応しなければならなかった。これらを総合すると、XRPL のインフラレイヤーには、より短いアップデートサイクルに歩調を合わせることが求められており、どれか 1 つのリリースで遅れを取ったオペレーターは、ネットワークの他の部分ではすでに修正済みの脆弱性を抱え続けるリスクを負うことになる。
FAQ
XRP Ledger ノードアップグレードが必要になった原因は何ですか？
7 月 31 日にバリデータマニフェストフラッドが発生し、ノード上でリソース枯渇を引き起こしたため、この問題を緩和する目的で xrpld 3.2.1 ホットフィックスが必要になりました。
マニフェストフラッドは、XRP Ledger 上で資金の損失やコンセンサスの失敗を引き起こしましたか？
XRP Ledger Operations によると、フラッド発生中に金銭的損失、トランザクションの改ざん、レジャーコンセンサスの失敗はいずれも確認されていません。
xrpld 3.2.1 で導入された主なセーフガードは何ですか？
このアップデートでは、マニフェストサイズ、メッセージバッチサイズ、未知キーのキャッシュ増加（100 エントリに上限）、および信頼されていないマニフェストの外向き共有に制限が設けられています。
誰が xrpld 3.2.1 にアップグレードする必要があり、運用上の手順は何ですか？
XRPL ノードを運用するインフラプロバイダー（取引所、カストディアン、ウォレットオペレーターなど）は、アップグレードを実施し、ソフトウェアが稼働していることを確認したうえで、保持されているマニフェストを消去するために 2 回目の再起動を行う必要があります。
{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”XRP Ledger ノードアップグレードが必要になった原因は何ですか？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”7 月 31 日にバリデータマニフェストフラッドが発生し、ノード上でリソース枯渇を引き起こしたため、この問題を緩和する目的で xrpld 3.2.1 ホットフィックスが必要になりました。”}},{“@type”:”Question”,”name”:”マニフェストフラッドは、XRP Ledger 上で資金の損失やコンセンサスの失敗を引き起こしましたか？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”XRP Ledger Operations によると、フラッド発生中に金銭的損失、トランザクションの改ざん、レジャーコンセンサスの失敗はいずれも確認されていません。”}},{“@type”:”Question”,”name”:”xrpld 3.2.1 で導入された主なセーフガードは何ですか？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”このアップデートでは、マニフェストサイズ、メッセージバッチサイズ、未知キーのキャッシュ増加（100 エントリに上限）、および信頼されていないマニフェストの外向き共有に制限が設けられています。”}},{“@type”:”Question”,”name”:”誰が xrpld 3.2.1 にアップグレードする必要があり、運用上の手順は何ですか？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”XRPL ノードを運用するインフラプロバイダー（取引所、カストディアン、ウォレットオペレーターなど）は、アップグレードを実施し、ソフトウェアが稼働していることを確認したうえで、保持されているマニフェストを消去するために 2 回目の再起動を行う必要があります。”}}]}
本記事は人工知能の支援を受けて作成され、編集チームによる確認を経ています。
