【続報】XRPL、XRPを不正に作れてしまうバグを修正　悪用の形跡なし　Batch V1.1は10月9日に有効化

XRP Ledger（XRPL）のサーバーソフト「xrpld」に、買う側は少ししか払わないのに売る側には全額届き、払っていない分のXRPが不正に生まれてしまうおそれのあるバグがあったと、10月9日付の報告書で分かりました。9月25日公開の「xrpld 3.4.1」で修正済みで、公開ネットワークでの悪用の形跡は見つかっていません。

さくっと要点
どんなバグだったのか
投票を待たない「すぐ効く修正」
Batch V1.1が延期された理由
参考・関連記事
出典

さくっと要点

誰の話か：xrpld。Ripple社の開発部門RippleXとXRPL財団が修正
何があったか：細工した大量の注文をまとめて買うと、合計額の計算がくるい、払っていない分のXRPが生まれてしまうおそれがあったバグ（3.4.0以前）。悪用の形跡はなし
いつ直ったか：9月25日の修正版で対応済み
前後関係：9月21日の記事のBatch V1.1は延期後、10月9日に有効化

どんなバグだったのか

買う側は少ししか払わないのに、売る側には全額届く。そうなりうる状態でした。XRPL内蔵の交換機能で多くの注文（オファー）を1回の支払いでまとめて買うとき、xrpldが足す合計額に上限チェックがなく、64ビット整数の上限を超えるとエラーにならず小さな数に戻る作り（桁あふれ）だったためです。

悪用された場合の流れ（報告書より）

① 注文を数百件
数百のアカウントが「少しのトークンを大量のXRPと交換」する注文を出す

▶

② 1回でまとめ買い
別のアカウントから、全部の注文を一度に買う支払いを送る

▶

③ 合計が桁あふれ
合計が上限を超えて小さな数に。買い手はわずかしか払わない

▶

④ 差額が新しいXRPに
売り手には全額が届き、差額は本来ないはずのXRPになる

「XRPが増えていないか」の安全チェックも同じ足し算で見抜けず、1アカウントが総供給量（1,000億XRP）を超えて持たないかのチェックも、数百アカウントに分ければ反応しない作りでした。

報告書は、悪用されれば数百XRPの準備金（後で戻る）と手数料ほどで、1回の取引で総供給量を大きく超えるXRPを作れた、としています。普通の送金や売買では起きず、バグは2015年からあったとみられます。

発見者は研究者のCayden Liao氏とVeria AIで、バグ報奨金経由で報告。RippleXは深刻度を「クリティカル」に上げました。

投票を待たない「すぐ効く修正」

XRPLのルール変更は通常、バリデーター（取引の承認役）の投票「アメンドメント」で、80%超の支持が2週間続くと全サーバーが一斉に切り替わります。今回はあえて各サーバーが3.4.1に更新した時点で効く形にしました。取引処理の変更では、この仕組みができて10年以上で初めてです。修正を出せば公開コードからバグの場所が分かるため、投票待ちの数週間に悪用されるのを避けた、と報告書は説明しています。ソースコードは伏せて配り、報告書の公開に合わせて公開しました。

更新の遅れで結果が食い違うおそれもありましたが、標準の信頼リスト（UNL）に載るバリデーターの80%超が9月25日のうちに3.4.1以降へ更新しました。

今回の流れ

9月22日
バグ報奨金で報告。RippleXが再現

▶

9月23日
修正をリリース候補版に取り込み

▶

9月25日
xrpld 3.4.1を公開。UNLのバリデーターの80%超が当日に更新

▶

10月9日
報告書を公開。fixBatchV1_2とBatch V1.1が有効化

Batch V1.1が延期された理由

3.4.1には、Batch（最大8件の取引をまとめる機能）向けの修正「fixBatchV1_2」も入りました。中の取引の枠（RawTransaction）の確認漏れで、バージョンで判断が割れ、ネットワーク停止のおそれがありました。Batch V1.1は本番前で資金への影響はなく、Rippleなどは賛成票をいったん取り下げて修正を先に入れました。3.4.1より前のサーバーは今、ネットワークに追いつけない状態（アメンドメントブロック）です。

更新を求められたのはサーバー運用者で、保有者向けの手続きの案内はありません。持つだけなら何もしなくてよさそうです。海外の暗号資産メディアCoin BureauはXで「GOOD NEWS」と紹介しました。