10年前のXRPレジャーバグでXRPを無から生成可能だった

実際には何が問題だったのか？

この問題は、XRPレジャーに組み込まれた分散型取引所（DEX）における決済処理を行うコード内に存在していました。昨日公開された公式の脆弱性開示レポートによると、1件の決済で多数のオファーが処理される際、エンジンはチェックされていない64ビット演算を用いて金額を合計していました。

その合計値が十分に大きくなると「ラップアラウンド」が発生しました。これは整数オーバーフローによる現象です。その結果、巨大な数値が小さな数値に変わり、取引の相手側である売り手には全額が支払われた一方で、買い手にはラップアラウンドしたごくわずかな合計額しか請求されませんでした。その差額は、それまで存在しなかったXRPでした。

台帳には「不変条件（invariant）」と呼ばれる安全チェック機能が実装されており、XRPが決して生成されないことを確認する役割を担っています。しかし、そのチェックも同様の検証されていない演算を使用していたため、本来検知すべきこの特定の不具合を見逃してしまいました。報告書によると、この欠陥は2015年に開発された現行の決済エンジンに起因するものです。

攻撃のコストはどれほど安かったのか？

報告書によると、攻撃に必要なコストは、準備金としてロックされた数百XRP（オブジェクトが削除されれば返還される）と通常の取引手数料のみでした。攻撃者は、意図的に誤った価格設定をしたオファーを数百件出し、その中から1件の支払いを経由させる必要がありました。

恐ろしいのはその見返りでした。RippleXはこのバグを「重大」と位置付けました。なぜなら、1回の検証済み取引で総供給量を超える使用可能なXRPが生成される可能性があったためです。 XRPの売り文句はすべて、1,000億トークンというハードキャップに基づいているため、このような「密かな発行」は、この資産の中核となる約束を揺るがすものだった。だからこそ、Whale Insiderなどの投稿では、このバグが「数十億」ものXRPを生み出す可能性があったと報じられたのである。

誰が発見し、どのくらいの速さで修正されたのか？

その経緯は極めて短期間で、以下の通りです：

• 9月22日：Cayden Liao氏とVeria AIがXRPLバグ報奨金プログラムを通じてこの問題を報告し、「Major（重大）」と評価しました。
• 9月23日：RippleXが問題を再現し、深刻度を「クリティカル」に引き上げ、修正がマージされました。
• 9月25日：Xrpld 3.4.1がリリースされ、同日時点でデフォルトのユニーク・ノード・リスト（UNL）バリデーターの80％以上がこれを稼働させていました。
• 10月9日：一般公開。

このパッチは通常の修正案投票を経ず、リリース3.4.1で直接的なコード変更として提供され、各サーバーのアップグレードに伴い適用されました。ソースコードはデプロイ後に公開されましたが、これは攻撃者に「攻撃の道筋」を与えることを避けるための標準的な措置です。 その後、XRPL Operationsアカウントは3.4.1を必須の最低バージョンに指定し、次のように付け加えました。

この問題がどのパブリックネットワークでも悪用されたという証拠は見つかっていません。

同じリリースで、深刻度が低い2つ目のバグも修正されました。これはバッチ取引のラッピング方法に関するもので、その修正はfixBatchV1_2修正案に含まれており、BatchV1_1と共に10月9日にメインネットで適用されました。報告書によると、このバグによる資金の損失もなかったということです。

この情報開示は、暗号資産のセキュリティにとって厳しい一週間の真っ只中に行われました。Bitcoin.com Newsが報じたところによると、Ledgerデバイスの紛失による被害額は推定9,340万ドルに達しました。 最後に、リップルが支援するEvernorthは月曜日にXRPNのティッカーシンボルでナスダックでの取引開始を準備しており、その保有高は約4億7300万XRPに上ります。XRPは分散型金融（DeFi）分野にも進出しており、Firelightは最近ネットワーク上でヴォールト保護機能を有効化しました。