XRP Ledger(XRPL)の開発チームは10月9日、慎重に構築された条件下で使用可能なXRPを無から生成することを許しかねない整数オーバーフローの脆弱性を開示した。修正は9月25日にxrpldバージョン3.4.1として提供され、公開開示の約2週間前にあたる。また、この脆弱性がパブリックネットワーク上で悪用された証拠は見つからなかったとチームは報告している。

詳細はXRPLの10月9日の脆弱性開示レポートで公表された。

XRPを無から生成できた可能性のある支払い計算

レポートは、レジャーのペイメントエンジンにおける整数オーバーフローの脆弱性について説明している。慎重に構築された条件下では、多数のオーダーブックオファーを消費する支払いにより、送金者が実際に支払っていないXRPがアカウントにクレジットされる可能性があった。オーダーブックはXRPLのネイティブ構造であり、レジャーの内蔵取引機能の一部であるため、欠陥のある算術処理は支払いだけでなくレジャー上の取引を支えるコードに存在していたことになる。

トランザクション内の各オファーは、それ単体では有効に見えた。問題は、エンジンがすべてのオファーのXRP額を合算した際に発生した。合計がその計算に使用される数値の最大サイズを超えると、エラーを出す代わりに、はるかに小さい値にラップアラウンドする可能性があった。

このシナリオでは、エンジンはオファーの所有者に全額のXRPをクレジットしながら、買い手にはラップアラウンド後の合計額のみを請求していた。差額は新たに生成されたXRPを意味し、他の残高と同様に移動、取引、取引所への送金が可能だった。

脆弱性が深刻だった理由

この攻撃には大きなXRP残高は必要なかった。攻撃者は、オファーを出すアカウントを管理し、必要なアカウントリザーブとトランザクション手数料を支払い、生成したXRPをそれらのアカウントに分散させることができた可能性がある。

脆弱性はウォレットアクセスではなく支払いの算術処理に存在し、アカウントキーは影響を受けなかった。悪用には、意図的に価格設定された数百のオファーと、それらを一括で消費するよう設計されたトランザクションが必要で、通常のXRP支払いや取引ではオーバーフローを引き起こす値に達することはない。

レジャーにとって、使用可能な単位を鋳造できてしまう欠陥ほど深刻なものは少ない。すべての残高は、新しいXRPがネットワークの定義されたルールを通じてのみ流通に参入することに依存しているからだ。

XRPLは、パブリックネットワーク上での悪用の証拠は見つからず、秘密鍵の漏洩、資金の損失、コンセンサス障害も報告されていないと述べた。この脆弱性は、現行のペイメントエンジンが2015年に書かれてから存在していたとみられ、通常の活動が算術限界に達しなかったため発見されずにいた。

新規生成XRPに対するレジャーの既存の保護も、同種の加算処理に依存していた。ペイメントエンジンと同様にラップアラウンドする可能性があり、残高の予期しない増加を検知する代わりに、トランザクションが正常に見える状態を許していた。

開発者が緊急デプロイを採用した理由

開発者は技術的詳細を公表する前にオーバーフロー修正をリリースした。通常のアmendメントのタイムラインでは、既知の悪用手段が数週間にわたり利用可能なまま残ることになるためだ。修正パッチは9月25日にxrpldバージョン3.4.1として提供され、公開開示はその後10月9日に行われた。

XRPLは通常、トランザクションルールをアmendメントを通じて変更する。バリデータはまずソフトウェアをアップグレードし、一定期間必要なサポートを維持した後、新しいルールがネットワーク全体で同じレジャーポイントにて有効化される。このプロセスにより、異なるサーバーが同一トランザクションについて異なる結論に達する状況を回避している。

今回のケースでは、このプロセスを待つことで困難な問題が生じていた。xrpldはオープンソースであるため、修正を公開すると、脆弱なトランザクションパスをまだ受け付ける旧ソフトウェアが稼働している間に、攻撃者に調査の糸口を与える可能性があった。そこでチームは、個々のサーバーがアップグレードした時点で新しいオーバーフローチェックを有効にすることとした。

この迅速なアプローチには一時的な互換性リスクが伴った。未適用のサーバーが、アップグレード済みのサーバーが拒否する悪用トランザクションを受け入れる可能性があった。開発者は、生成されたXRPが市場に流入することを許すよりも危険性が低いと判断した。レポートによると、バージョン3.4.1のリリース日の時点で、デフォルトUNL上のバリデータの80%以上がアップグレードを完了していた。

開示には別個の第2の脆弱性も含まれていた

レポートは、複数のトランザクションを1つのユニットとして提出できるXRPLの forthcomingなBatch機能における検証問題についても詳述している。この欠陥により、異なるバージョンのソフトウェアを実行するサーバー間で不正なBatchトランザクションをめぐる見解の相が生じ、レジャー検証の中断やトランザクションデータを解析するアプリケーションの破損を招く可能性があった。

Batch機能の欠陥は、機能がメインネットに到達する前に発見された。一方、オーバーフローの問題は既存のペイメントエンジンコードに影響していたため、その修正は標準のアクティベーションサイクルを待つことができなかった。機能自体はまだ提供前であり、検証修正がすでに組み込まれた状態でのメインネットへの投入が、今回の開示で今後の部分となる。

レポートが公表された時期は、XRPLが企業向けの新しいアカウント管理ツールを有効化している時期とも重なった。これらの変更はレジャーの異なる部分に対応するものだが、いずれもノード運営者、ウォレット提供者、開発者が同一の現行ルールに従うことに依存している。

ユーザーと運営者が行うべきこと

通常のXRP保有者は、資金の移動、ウォレットの交換、トークンの交換を行う必要はない。今回の更新はトランザクションを検証するソフトウェアに関するものであり、アカウント残高、ウォレットキー、ユーザーが保有するXRP供給量の変更ではない。

• XRP保有者: 対応は不要。
• 取引所ユーザー: 取引所が独自のXRPLインフラのメンテナンスを実施する場合は、プラットフォームの通知に従うこと。
• ノード運営者: ネットワークとの同期を維持するため、xrpld 3.4.1以降にアップグレードすること。Batch修正の有効化に伴い、旧サーバーは現在アmendメントブロックされており、更新するまで現行のレジャールールに従い続けることができない。

修正はテストされる前にXRPの供給ルールを守った

今回の開示は、レジャーが供給の完全性の失敗にどれほど近かったか、そしてバリデータが迅速に動いた理由を示している。脆弱性は詳細が公開される前に修正され、悪用は確認されず、ペイメントエンジンは現在、同種の算術エラーが検証済みレジャーに到達する前に阻止するよう設計されたチェックを使用している。今後注目されるのは、未適用のサーバーがすでにアmendメントブロックされている中で、ネットワークの残りの部分がxrpld 3.4.1以降にどれだけ迅速に収束するかである。

本記事は情報提供のみを目的としており、投資または技術上の助言を構成するものではない。ノード運営者は、本番インフラを更新する前に最新のXRPLリリースドキュメントを確認すべきである。

本記事はCoindooが originally 公開した報道に基づいている。