📡 Signal｜XRP Ledger、XRP を無から生める10年来の不具合を修正

XRP Ledger の公式サイト xrpl.org は10月9日、支払いエンジンの整数オーバーフローによって、1回の取引で XRP の総供給量をはるかに超える XRP を無から生み出せた不具合の開示報告を公表した。不具合は2015年から台帳に残っていた。9月22日に報告を受け、9月25日公開の xrpld 3.4.1 で修正済みで、公開ネットワークで悪用された証拠は見つかっていないという。

XRP は発行時に1,000億枚が作られ、それ以上は増えない設計だ。その前提を一度の取引で崩せる穴が、台帳の安全チェックにも引っかからないまま約10年残っていた。修正は中身を伏せて先に配り、バリデータの大半が更新を終えてから公表する順序で進んだ。

本サイトの速報 (リップル、1000億XRP超の不正生成を許した脆弱性を修正) の続報として、開示報告の一次の記述から仕組みと経緯を整理する。

足し算 1 つで、上限が意味を失う

不具合は、支払いが複数の売り注文 (オファー) をまたいで約定するときの合計の計算にあった。報告によると、その合計は64ビット整数の単純な足し算で、桁あふれの検査がなかった。合計が上限を超えると値が折り返して小さな数になる。

支払いエンジンは、各オファーの持ち主にはそれぞれ満額を払い、買い手からは折り返した後の小さな合計しか差し引かなかった。差額は、どこからも来ていない XRP として台帳に現れる。報告は、悪用されていれば1回の検証済み取引で総供給量をはるかに超える使える XRP を作れたとし、影響を「critical」と評価している。

攻撃に要るのは、アカウントとオファーの準備金として数百 XRP (オブジェクトを消せば戻る) と、通常の取引手数料だけだったという。

安全装置も同じ計算をしていた

XRP Ledger には、どの取引も XRP を新たに作っていないことを確かめる不変条件 (invariant) の検査が組み込まれている。だが報告によると、この検査も残高の変化を同じやり方で足し合わせていたため、同じように折り返し、異常を見逃した。不変条件の検査は支払いエンジンの2年後に足されたもので、元の計算の弱点をそのまま引き継いだ形だ。

アカウントごとの残高上限の検査もあった。こちらは、生み出した XRP を数百のアカウントに散らせば、どのアカウントの残高も上限を下回るため、すり抜けられたという。

修正後は、合計が桁あふれする場合、支払いは「経路が尽きた」か「部分的な支払い」の結果で失敗する。不変条件の検査は、折り返さない幅の広い計数器に置き換えられた。

伏せて配り、更新が進んでから公表した

時系列は次のとおりだ。

9月22日: Cayden Liao 氏と Veria AI がバグ報奨金制度を通じて報告と実証コードを提出。報告時の深刻度は「Major」で、RippleX が再現したのち「critical」に引き上げた
9月23日: 修正を 3.4.1 のリリース系統に取り込み、3.4.1-rc1 に収録
9月25日: xrpld 3.4.1 を公開。同日中に既定の UNL (信頼するバリデータの一覧) に載るバリデータの80%超が 3.4.1 以降に更新
10月9日: 開示報告を公表

9月25日のリリースノートは、これを「緊急リリース」と明記し、変更点は「支払いエンジンと台帳の補助処理における整数演算の強化」と1行で書いていた。セキュリティ上の理由でソースコードは公開せず、バイナリだけを配った。何かが危険だったことは告げ、何が危険だったかは伏せた。GitHub の XRPLF/rippled のリリース欄では、ソースは10月10日 (日本時間) に公開されている。

もう1つ、今回の修正は配り方が異例だった。XRP Ledger では、取引の処理を変える修正は通常、バリデータの投票で一斉に有効化する「amendment」として出す。今回はサーバーを更新した時点で効く形で出した。報告は、amendment の仕組みができて10年あまりで、取引処理の変更を意図してこの形で出したのは初めてだとしている。投票の期間を待てば、その間に穴の存在が外から推測されうる。速さを優先した判断だ。

同じ報告は、2件目の不具合も開示した。複数の取引を束ねて実行する Batch 機能で、内側の取引を包む形式の検証が甘く、ソフトウェアのバージョンが混在すると合意が割れて台帳が止まるおそれがあった。こちらは発見時点でメインネットでは有効になっておらず、資金への影響はなかった。修正の amendment である fixBatchV1_2 は、Batch 機能の BatchV1_1 とともに10月9日にメインネットで有効になった。これで、3.4.1 より古いサーバーは amendment blocked となり、ネットワークと同期できない。

2010年の Bitcoin は、悪用されてから直した

ブロックチェーンの供給を桁あふれで破る不具合には前例がある。2010年8月15日、Bitcoin のブロック74638に、約1,844億 BTC を生み出す取引が含まれていることが見つかった。原因は同じく整数オーバーフローで、CVE-2010-5139 として登録されている。修正版のクライアントは5時間以内に出され、ソフトフォークで正しいチェーンがブロック74691で不正なチェーンを追い抜いた。

違いは、悪用が起きたかどうかだ。Bitcoin は実際に不正な取引がブロックに入り、チェーンの巻き戻しで処理した。XRP Ledger は、報奨金制度を通じた報告で穴を先に見つけ、悪用の証拠がないまま塞いだ。どちらも「上限が守られている」という確認は、検査のコードが正しく書かれていることに依存していた。上限は設計図に書くだけでは守られず、検査の実装が支えている。

次に見るもの

確認できる次の一点は、10月10日に公開された xrpld 3.4.1 のソースコードだ。GitHub の XRPLF/rippled で修正の差分を誰でも読めるようになり、外部の開発者が修正の範囲を検証できる段階に入った。開示報告が「整数演算の強化」と呼んだ変更が、支払いエンジン以外のどこに及んでいるかは、この差分で確かめられる。

ノードを運用する取引所や事業者にとっては、より手前の確認がある。3.4.1 より古いサーバーは10月9日の amendment 有効化で同期できなくなっている。自社のサーバーが 3.4.1 以降かどうかが、今日確かめるべき点だ。

ことば

整数オーバーフロー — 整数を入れる箱の上限を計算結果が超え、値が最小値側へ折り返す現象。金額の計算で起きると、大きな合計が小さな数に化けるため、支払いや残高の検査がすり抜けられる。
amendment — XRP Ledger で取引の処理規則を変えるときの仕組み。バリデータの一定割合が一定期間支持すると有効になる。全員が同じ規則へ同時に切り替えるための手順で、今回はあえてこれを使わずに修正を出した。
UNL — 各サーバーが「このバリデータの投票を信頼する」と定める一覧。既定の一覧に載るバリデータの更新率が、修正がネットワークに行き渡ったかの目安になる。

🔗 一次ソース

足し算 1 つで、上限が意味を失う

安全装置も同じ計算をしていた

伏せて配り、更新が進んでから公表した

2010年の Bitcoin は、悪用されてから直した

次に見るもの

ことば

関連記事