本文へスキップ
MameTechNews
バックエンド

XRP Ledger、64ビット加算の桁あふれでXRPを無から作れた欠陥を公表 安全チェックも同じ演算で素通り

## POINTS

  • 多数のオファーを1回で約定させる合計額の64ビット加算に桁あふれのチェックがなく、差額が新しいXRPになっていた
  • XRPを作らないことを確かめる不変条件も同じ演算で集計していたため、検出できなかった
  • 修正は3.4.1で検証者投票を経ずに即時有効化。不変条件のチェックはより広い整数型での集計に変更

XRP Ledgerの開発チームは10月9日、9月25日公開のxrpld 3.4.1で修正した2件の脆弱性の報告書を公開した。重大度が高いのは支払いエンジンのXRPオーバーフローで、バグバウンティ経由で9月22日に報告された。支払いがオーダーブックの多数のオファーを1回で約定させる際、買い手が払う合計額を符号付き64ビット整数のチェックなしの加算で求めていた。非常に大きなXRP額を求めるオファーを数百件並べると合計が桁あふれして小さな値になり、エンジンは各オファーの持ち主には満額を支払う一方、買い手からは桁あふれ後の額しか引かなかった。差額が新たに生まれたXRPになる。トランザクションがXRPを作らないことを確かめる不変条件のチェックも同じ64ビットの加算で差分を合計していたため、同じように桁あふれして検出できなかった。口座ごとの残高上限チェックも、作られたXRPを数百口座に分散させると通過した。必要なのは数百XRPの準備金と手数料だけだったという。報告書によると欠陥は2015年に現在の支払いエンジンが書かれた時点から存在していた。3.4.1では合計時の桁あふれを検出して支払いを失敗させ、不変条件のチェックはより広い整数型で集計するようにした。通常の修正手順である検証者投票(アメンドメント)を経ずにアップグレード時点で即時に有効にしたのは、修正のソースが公開されれば攻撃方法が分かる状態が数週間続くためとしている。公開当日に既定のUNLの検証者の80%超が3.4.1に更新した。