BitsLab傘下のTonBit、TON VMコアの脆弱性を発見：脆弱性の根本原因および緩和策の詳細な説明
TechFlow厳選深潮セレクト
BitsLab傘下のTonBit、TON VMコアの脆弱性を発見：脆弱性の根本原因および緩和策の詳細な説明
本レポートでは、TON仮想マシンに存在する主要なDoS脆弱性の技術的詳細、根本原因および考えられる攻撃手法について詳細に分析するとともに、TonBitチームが提案した効率的な解決策を紹介しています。
Web3業界の深掘り報道に専念し潮流を洞察最近、TONネットワークの仮想マシンシステムが重大なセキュリティアップグレードを実施しました。BitsLab傘下のセキュリティチームTonBitは、TON仮想マシンのリソースを枯渇させる可能性のあるコア脆弱性を発見し、その修復を支援することに成功しました。この脆弱性は、仮想マシンがContinuationのネスト処理を行う際の再帰的メカニズムを利用したもので、悪意あるスマートコントラクトによって悪用され、システムクラッシュやネットワークの不安定化を引き起こす可能性がありました。
この脆弱性が悪用された場合、1つのTONも消費せずにすべてのバリデータノードをダウンさせ、ネットワークの可用性を直接脅かす恐れがありました。今回の事象において、TonBitは卓越した技術力により迅速に脆弱性を特定し、仮想マシンの内部制御フロー機構を調整することで、再帰処理を反復処理に置き換える革新的な解決策を提案しました。これにより、TONユーザーにとってより安全なエコシステムが構築されました。TON公式チームは、最新のアップデート公告にて、TonBitによるエコシステムの安全性への貢献に対し特別に謝意を表しています。
以下に掲載する詳細なセキュリティレポートでは、この脆弱性の原因、技術的詳細および解決策について深く分析します。本レポートは、Continuationの深度ネストによってリソース枯渇攻撃を引き起こす再帰チェーンがどのように構築されるか、また悪意あるコントラクトが呼び出しスタックを拡張してホストのスタックスペースを消費する仕組みを詳しく説明します。さらに、TonBitチームが再帰チェーンの設計上の欠陥を排除し、協調的な反復処理方式へと移行することで問題を完全に解決したプロセスについても紹介します。今回の修正はTONネットワークの安定性を大幅に向上させただけでなく、ブロックチェーン業界における基盤的安全性にも重要な示唆を与えています。
ケーススタディ：TON VMにおけるDoS脆弱性と関連緩和策
はじめに
本レポートは、TON仮想マシン（TON VM）に存在するDoS（サービス拒否）脆弱性およびその緩和策について述べます。この脆弱性は、コントラクト実行中にContinuationのネストを処理する方法に起因しています。攻撃者はContinuationを作成し、特定の方法で深くネストすることで評価プロセス中に深い再帰を発生させ、ホストのスタックスペースを枯渇させ、仮想マシンの動作を停止させることが可能でした。この問題の緩和のために、仮想マシンはContinuationおよび制御フローの処理方法を変更しました。現在では、Continuationチェーンに対する順次末尾呼び出しではなく、仮想マシンが自らそのチェーンを反復的に処理します。このアプローチにより、ホスト側のスタックスペース使用量が一定に保たれ、スタックオーバーフローが防止されます。
概要
公式ドキュメントによると、TON VMはスタックベースの仮想マシンであり、内部プロセスおよびスマートコントラクトの制御フローとして「Continuation-Passing Style」（CPS、継続渡し形式）を採用しています。制御フローレジスタはコントラクトからアクセス可能となっており、柔軟性が確保されています。
TVMにおけるContinuationは理論上、以下の3種類に分類できます：
-
OrdCont（vmc_std）— 実行すべきTON ASM断片を含むTVM内の一等オブジェクト。コントラクトは実行時に明示的にこれらを作成・渡すことができ、任意の制御フローを実現可能です。
-
非通常Continuation（Extraordinary continuations）— OrdContを構成要素として持ち、明示的な反復プリミティブまたは特殊な暗黙操作によって生成され、対応する制御フロー機構を処理するために使用されます。
-
追加のArgContExt — 他のContinuationをラップし、制御データを保存するために使用されます。
コントラクトの実行中、仮想マシンはメインループに入り、毎回コントラクト断片の1語をデコードし、適切なハンドラーに操作を割り当てます。通常のハンドラーは操作を実行後すぐに返却します。
一方、反復命令は提供されたContinuationを構成要素として使用して非通常Continuationを作成し、適切なコンテキストにジャンプします。非通常Continuation自体はジャンプ時にロジックを実装し、条件に基づいて特定の構成要素に遷移します。例えば、WHILE命令を使用する場合、図1にそのプロセスを示します（抜け出る可能性は省略）。
図1：非通常Continuationのロジック
根本原因
脆弱性を有する仮想マシンのバージョンでは、これらのジャンプが連続する動的末尾呼び出しを引き起こし、各ジャンプに対してホスト側のスタックフレームを維持する必要がありました（図2参照）。
WhileContを例に示し、他の部分は簡潔さのため省略します。
図2：深くネストする三重ジャンプの再帰
理想状態では、これは問題になりません。なぜなら構成要素は通常OrdContとして表現されており、ジャンプは現在のコンテキストを保存した上で、保持している断片を残りのコントラクト断片より先に実行するよう仮想マシンに指示するだけであり、追加の再帰は発生しないためです。しかし、理論的には非通常Continuationの構成要素がTVM内のcc（c0）レジスタ（前述のset_c0分岐）経由でアクセスできるように設計されています。そのため、コントラクトはこの機能を悪用して深層再帰を実行することが可能でした（後述）。この通常機能の実装を変更するよりも、非通常Continuationのジャンププロセス自体で再帰を排除する方が明確かつ容易です。
既に取得済みの非通常Continuationを繰り返し使用して上位レベルの非通常Continuationを構築することで、反復的に深くネストされたContinuationを作成できます。このような深くネストされたContinuationが評価されるとき、ホストの利用可能なスタックスペースを枯渇させ、OSがSIGSEGVシグナルを送信して仮想マシンプロセスを終了させる可能性があります。
図3はネストプロセスの概念実証（PoC）を示しています。
図3：ネストプロセス
各イテレーションで、本体がWhileCont{chkcond=true}を1つ拡張していることがわかります。前回イテレーションで生成・保存されたccを実行すると、次のようなコールスタックが得られます：
スタックスペースがネストレベル（すなわちイテレーション回数）に線形に依存していることが明らかであり、スタックスペースの枯渇リスクがあることを示しています。
実環境での悪用可能性について
実際のブロックチェーン環境では、ガス料金の制限により悪意あるコントラクトの構築は非常に困難です。ネストプロセスは線形の計算複雑性を持ち（TVMの設計は自己参照によるより安価な構築を効果的に防いでいる）、実用的な悪意あるコントラクトを開発するのは容易ではありません。具体的には、1段階のネストはデバッグバイナリで3つのホストスタックフレーム（320バイト）、リリースバイナリでは2つ（256バイト、後続2つの呼び出しがインライン化されるため）を消費します。現代のPOSIXオペレーティングシステム上で動作するバリデータノードのデフォルトスタックサイズは8MiBであり、リリースバイナリでは3万以上のネストレベルをサポートできます。したがって、スタックスペースを枯渇させるコントラクトを作成することは依然可能ですが、前述の例に比べてはるかに困難です。
緩和策
本パッチは、Continuationのネスト状況下でのジャンプ挙動を変更しています。Continuationジャンプのシグネチャが変化していることが確認できます。
UntilContを例に示します（他の部分は省略）。
以前は、VmState::jumpを呼び出して次のContinuationにジャンプするという方式で、各Continuation上で三重の再帰的ジャンプを実行し、戻り値が逆方向に伝播するのを待っていました。現在では、Continuationジャンプは次のレベルのContinuationを解析するだけで、制御を直ちに仮想マシンに返します。
仮想マシンは協調的に各レベルのcontinuationを反復的に解析し、NullRefに到達するまで処理を続けます。これはチェーンの解析が完了したことを意味し（OrdContまたはExuQuitContで実装）、この反復プロセス中、ホストスタック上には常に1つのcontinuationジャンプのみが割り当てられるため、スタック使用量は一定に保たれます。
結論
高可用性が求められるサービスにおいて、再帰の使用は潜在的な攻撃ベクトルとなる可能性があります。ユーザ定義のロジックに関与する場合、再帰の強制終了は困難であることがあります。本DoS脆弱性は、リソース制約下（あるいは他の制約下）で正常な機能が予期せず悪用される極端なケースを示しています。ユーザ入力に再帰が依存する場合、同様の問題が発生し得ます。これは仮想マシンの制御フロープリミティブではよく見られる現象です。
本レポートは、TON仮想マシンに存在する主要なDoS脆弱性の技術的詳細、根本原因および可能な攻撃手法について詳細に分析するとともに、TonBitチームが提示した効率的な解決策を紹介しています。仮想マシンの再帰的ジャンプ機構を反復処理に変更することで、TonBitは脆弱性の修復策を成功裏に提案し、ネットワークの停止につながりかねないコア脆弱性の修復を支援しました。これにより、TONエコシステムはより堅牢なセキュリティ体制を獲得しました。今回の事象は、TonBitがブロックチェーン基盤技術のセキュリティ分野において豊富な知見を有していることを示すだけでなく、TON公式Security Assurance Provider (SAP)としての重要な役割を果たしていることも浮き彫りにしています。
TonBitは、TONエコシステムに不可欠なセキュリティパートナーとして、ブロックチェーンネットワークの安定性とユーザー資産の保護において常に業界をリードしています。脆弱性の発見から解決策の設計に至るまで、TonBitは強力な技術力とブロックチェーン発展への深い理解を通じて、TONネットワークの長期的発展の基盤を築いてきました。同時に、TonBitチームはネットワークセキュリティアーキテクチャ、ユーザーデータ保護、ブロックチェーン応用シーンのセキュリティ強化の分野でも継続的に取り組んでいます。今後もTonBitは革新を通じてセキュリティ技術の進歩を推進し、TONエコシステムおよびブロックチェーン業界全体の健全な発展に持続的に貢献していく所存です。今回の脆弱性の発見および修復作業は、TON公式から高い評価を得ており、TonBitのブロックチェーンセキュリティ分野における業界的地位をさらに確固たるものにするとともに、分散型エコシステムの発展を推進するという強い決意を示しています。
TonBit 公式ウェブサイト：https://www.tonbit.xyz/
TonBit 公式Twitter：https://x.com/tonbit_
Telegram：https://t.me/BitsLabHQ
Linkedin: https://www.linkedin.com/company/tonbit-team/
Blog: https://www.tonbit.xyz/#blogs
Telegramでの監査依頼連絡先：@starchou
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@tonbit_
