このレポートでは、TON仮想マシン内の重要なDoS脆弱性の技術的な詳細、根本的な原因、および可能な攻撃方法を詳細に分析し、TonBitチームが提案する効果的な解決策を紹介しています。最近、TONネットワークの仮想マシンシステムは重要なセキュリティのアップグレードを迎えました。BitsLabのセキュリティチームTonBitは、TON仮想マシンのリソース枯渇を引き起こす可能性がある重要な脆弱性を発見し、修復するのに成功しました。この脆弱性は、仮想マシンがContinuationのネスト処理を行う際の再帰メカニズムを悪用する可能性があり、悪意のあるスマートコントラクトによって乱用されると、システムのクラッシュやネットワークの不安定化を引き起こす恐れがあります。この脆弱性が悪用されると、TONを1つも消費することなく、すべての検証ノードがダウンし、ネットワークの可用性が直接的に脅かされる可能性があります。この事件では、TonBitは優れた技術力を持っており、脆弱性を迅速に特定し、仮想マシンの内部制御フローメカニズムを調整することで、再帰の代わりに反復を提案する革新的な解決策を提供し、より安全なエコシステムをTONユーザーに提供しました。TON公式チームは最新の更新公告で、エコシステムのセキュリティへの卓越した貢献に対してTonBitに特別な感謝を述べています。以下の詳細なセキュリティレポートでは、この脆弱性の原因、技術的な詳細、および解決策について詳しく説明します。報告書には、Continuationのデプスネストを利用したリソース枯渇攻撃の再帰的なチェーンの構築方法や、悪意のある契約がスタック空間を使い果たすために拡張呼び出しスタックをどのように利用するかが詳しく記載されています。また、TonBitチームが再帰的なチェーンの設計上の欠陥を解消し、協調的な反復メカニズムに変更することで、この問題を徹底的に解決する方法も紹介します。この修正により、TONネットワークの安定性が大幅に向上し、ブロックチェーン業界の基本的なセキュリティに重要な参考情報が提供されました。ケーススタディ：TON VMのDoS脆弱性と関連する緩和策簡単な紹介このレポートは、TON仮想マシン内のDoS（拒否サービス）の脆弱性とその問題の緩和策について説明しています。この脆弱性は、仮想マシンが契約の実行中にContinuationのネストを処理する方法に起因しています。この脆弱性により、悪意のある契約がContinuationを作成し、特定の方法でデプスのネストを行うことにより、評価プロセス中に深い再帰がトリガーされ、ホストのスタックスペースが枯渇し、仮想マシンが停止します。この問題を緩和するために、仮想マシンはContinuationと制御フローの処理を変更しました。現在、仮想マシンはContinuationチェーンを順次のテールコールではなく、アクティブにイテレーションするようになりました。この方法により、一定のホストスタックスペースのみを使用し、スタックオーバーフローを防止します。概要公式ドキュメントによると、TON VMはスタックベースの仮想マシンであり、Continuation-Passing Style（CPS）を制御フローのメカニズムとして採用しており、内部フローとスマートコントラクトに使用されます。制御フローレジスタはコントラクトからアクセス可能であり、柔軟性を提供します。TVMのContinuationは理論的に3つのタイプに分類できます。実行する必要がある TON ASM フラグメントを含む OrdCont (つまり、vmc\_std) は、TVM の第 1 レベルのオブジェクトです。 コントラクトは、実行時に明示的に作成し、任意の制御フローを実装するために渡すことができます。非普通なContinuation（Extraordinary continuations）は、通常OrdContを含むコンポーネントであり、明示的な反復プリミティブと特殊な暗黙の操作によって作成され、対応する制御フローのメカニズムを処理するために使用されます。他のContinuationをカプセル化して制御データを保存するための追加のArgContExt。契約の実行中、仮想マシンはメインループに入り、契約のフラグメントを1文字ずつデコードし、対応する操作を適切なハンドラにディスパッチします。通常のハンドラは、対応する操作を実行した後、すぐに返します。比較的に、反復命令は提供された継続をコンポーネントとして使用して通常ではない継続を作成し、適切な文脈で非通常の継続にジャンプします。非通常の継続自体がロジックを実装してジャンプし、条件に応じてコンポーネントにジャンプします。例えばWHILE命令を使用する場合、図1に示すようにこのプロセスを示すことができます（可能な中断は省略されています）。図1:非通常のコントリビューションロジック根本原因存在するバグの仮想マシンのバージョンでは、これらのジャンプは連続した動的テールコールを引き起こし、これによりホストスタックは各ジャンプごとにスタックフレームを維持する必要があります（図2参照）。WhileContを例にとって、他の部分は簡潔に省略されています。図2：トリプルジャンプ再帰による深いトラップへの掘り下げ理想的な状況では、これは問題にはならないはずです。なぜなら、通常、コンポーネントはOrdContとして表され、そのジャンプは現在のコンテキストのみを保存し、その後、それが保持する断片を実行する仮想マシンに先立って、残りの契約断片を実行するだけで、より多くの再帰を導入しません。ただし、非OrdContは理論上、そのコンポーネントがTVM内のcc（c0）レジスタ（すなわち、set\_c0ブランチで上記のように）を介してアクセスできることを許可しています。したがって、契約はこの機能を濫用してデプス再帰を実行することができます（後で説明します）。この通常の機能の実装を変更するよりも、非OrdContのジャンププロセス中に再帰を排除することがより明確で容易です。既存の非通常のContinuationを繰り返し使用して、上位の非通常のContinuationを構築することで、デプスネストされたContinuationを反復的に作成することができます。これらのデプスネストされたContinuationは、評価時にホストの利用可能なスタック領域を使い果たす可能性があり、オペレーティングシステムがSIGSEGVシグナルを発行して仮想マシンプロセスを終了することがあります。図3は、ネストプロセスの概念検証（PoC）を提供しています。図3：罠設置プロセス私たちは、各イテレーションで、本体がWhileCont{chkcond=true}を拡張していることを確認しました。前回のイテレーションで生成および保存されたccを実行することで、次のような呼び出しスタックが得られます:スタック領域とネストのレベル（つまり、反復回数）との間には線形の依存関係があることがわかることから、スタック領域の枯渇が引き起こされる可能性があることがわかります。実際の環境での利用について実際のブロックチェーンでは、ガス制限により、悪意のあるスマートコントラクトの構築が非常に困難になります。ネストされたプロセスの線形の複雑さ（TVMの設計により、より安価な構築を自己参照を介して防止する効果的な方法）のため、実際に実行可能な悪意のあるスマートコントラクトを開発することは容易ではありません。具体的には、1つのネストは呼び出しシーケンスを生成し、デバッグバイナリで3つのホストスタックフレーム（320バイト）を消費し、公開バイナリで2つのホストスタックフレーム（256バイト、最後の2つの呼び出しはインラインで1つ）を消費します。現代のPOSIXオペレーティングシステム上で実行される検証ノードのデフォルトのスタックサイズは8MiBであり、これは公開バイナリで30,000層以上のネストをサポートするのに十分です。スタックスペースを使い果たすことができるコントラクトを作成することはまだ可能ですが、前のセクションの例よりもはるかに困難です。緩和 策このパッチでは、Continuationのネストされた場合のジャンプ動作が変更されました。Continuationのジャンプの署名が変更されたことがわかります。UntilContを例にとって、他の部分は簡潔に省略されています。VmState::jumpをもう呼び出さないことで、次のContinuationにジャンプする必要がなくなりました。これは、各Continuationで三重ジャンプを再帰的に実行し、戻り値を後方に伝播することを意味します。現在、Continuationジャンプは単にContinuationの次のレベルを解決し、その後、制御を仮想マシンに返します。仮想マシンは、連続的に各レベルの continuation を協調的に解析し、NullRef に遭遇するまで、つまり、チェーンの解析が完了するまで（OrdCont や ExuQuitCont で実装されているように）、反復的に解析します。この反復の過程で、ホストスタックには常に1つの continuation ジャンプしか割り当てられないため、スタックの使用が一定に保たれます。01928374656574839201結論高可用性のサービスが必要な場合、再帰的な使用は潜在的な攻撃ベクトルとなる可能性があります。ユーザー定義のロジックが関係する場合、強制的な再帰の終了は挑戦的な場合があります。このDoS脆弱性は、リソースが制限された状況（または他の制約条件）で、正常な機能が意図せずに乱用される極端なケースを示しています。再帰がユーザー入力に依存する場合、同様の問題が発生する可能性があり、これは仮想マシンの制御フロー原語では非常に一般的です。本レポートでは、TONの仮想マシンに存在するDoS攻撃の核心的な技術的詳細、根本的な原因、および攻撃方法について詳しく分析し、TonBitチームが提案した効果的な解決法を紹介しています。仮想マシンの再帰ジャンプメカニズムを反復処理に調整することで、TonBitはこの可能性のあるネットワーク障害の原因となる重大な脆弱性を修正することに成功し、TONエコシステムにより強力なセキュリティ保証を提供しています。この事件は、TonBitがブロックチェーンの基盤技術セキュリティ領域で深い経験を持つことを示すだけでなく、TONの公式セキュリティ保証プロバイダー(SAP)としての重要な役割を示しています。TONエコシステムにおいて不可欠なセキュリティパートナーとして、TonBitは常にブロックチェーンネットワークの安定性とユーザー資産の安全性を保護することに取り組んでいます。バグ発見から解決策の設計まで、TonBitは強力な技術力とブロックチェーンの発展に対する深い理解に基づいて、TONネットワークの長期的な発展に堅固な基盤を築いています。同時に、TonBitチームは、ネットワークのセキュリティアーキテクチャ、ユーザーデータの保護、およびブロックチェーンアプリケーションシナリオのセキュリティ向上などの領域で引き続き取り組んでいます。将来、TonBitは革新的な安全技術の進歩を推進し、TONエコシステムおよびブロックチェーン産業全体の健全な発展に持続的なサポートと保証を提供し続けます。今回のバグ発見および修正支援作業は、TON公式から高い評価を受け、TonBitのブロックチェーンセキュリティ分野における業界地位をさらに固め、分散型エコシステムの発展を推進する決意を示しました。TonBit 公式ウェブサイト：TonBit公式ツイッター:電報：Linkedin: ブログ：#blogsTelegramの監査要件については、@starchouにお問い合わせください
BitsLabの子会社TonBitがTON VMのコアバグを発見しました：バグの根本原因と緩和策について詳しく説明します
このレポートでは、TON仮想マシン内の重要なDoS脆弱性の技術的な詳細、根本的な原因、および可能な攻撃方法を詳細に分析し、TonBitチームが提案する効果的な解決策を紹介しています。
最近、TONネットワークの仮想マシンシステムは重要なセキュリティのアップグレードを迎えました。BitsLabのセキュリティチームTonBitは、TON仮想マシンのリソース枯渇を引き起こす可能性がある重要な脆弱性を発見し、修復するのに成功しました。この脆弱性は、仮想マシンがContinuationのネスト処理を行う際の再帰メカニズムを悪用する可能性があり、悪意のあるスマートコントラクトによって乱用されると、システムのクラッシュやネットワークの不安定化を引き起こす恐れがあります。
この脆弱性が悪用されると、TONを1つも消費することなく、すべての検証ノードがダウンし、ネットワークの可用性が直接的に脅かされる可能性があります。この事件では、TonBitは優れた技術力を持っており、脆弱性を迅速に特定し、仮想マシンの内部制御フローメカニズムを調整することで、再帰の代わりに反復を提案する革新的な解決策を提供し、より安全なエコシステムをTONユーザーに提供しました。TON公式チームは最新の更新公告で、エコシステムのセキュリティへの卓越した貢献に対してTonBitに特別な感謝を述べています。
以下の詳細なセキュリティレポートでは、この脆弱性の原因、技術的な詳細、および解決策について詳しく説明します。報告書には、Continuationのデプスネストを利用したリソース枯渇攻撃の再帰的なチェーンの構築方法や、悪意のある契約がスタック空間を使い果たすために拡張呼び出しスタックをどのように利用するかが詳しく記載されています。また、TonBitチームが再帰的なチェーンの設計上の欠陥を解消し、協調的な反復メカニズムに変更することで、この問題を徹底的に解決する方法も紹介します。この修正により、TONネットワークの安定性が大幅に向上し、ブロックチェーン業界の基本的なセキュリティに重要な参考情報が提供されました。
ケーススタディ：TON VMのDoS脆弱性と関連する緩和策
簡単な紹介
このレポートは、TON仮想マシン内のDoS（拒否サービス）の脆弱性とその問題の緩和策について説明しています。この脆弱性は、仮想マシンが契約の実行中にContinuationのネストを処理する方法に起因しています。この脆弱性により、悪意のある契約がContinuationを作成し、特定の方法でデプスのネストを行うことにより、評価プロセス中に深い再帰がトリガーされ、ホストのスタックスペースが枯渇し、仮想マシンが停止します。この問題を緩和するために、仮想マシンはContinuationと制御フローの処理を変更しました。現在、仮想マシンはContinuationチェーンを順次のテールコールではなく、アクティブにイテレーションするようになりました。この方法により、一定のホストスタックスペースのみを使用し、スタックオーバーフローを防止します。
概要
公式ドキュメントによると、TON VMはスタックベースの仮想マシンであり、Continuation-Passing Style（CPS）を制御フローのメカニズムとして採用しており、内部フローとスマートコントラクトに使用されます。制御フローレジスタはコントラクトからアクセス可能であり、柔軟性を提供します。
TVMのContinuationは理論的に3つのタイプに分類できます。
実行する必要がある TON ASM フラグメントを含む OrdCont (つまり、vmc_std) は、TVM の第 1 レベルのオブジェクトです。 コントラクトは、実行時に明示的に作成し、任意の制御フローを実装するために渡すことができます。
非普通なContinuation（Extraordinary continuations）は、通常OrdContを含むコンポーネントであり、明示的な反復プリミティブと特殊な暗黙の操作によって作成され、対応する制御フローのメカニズムを処理するために使用されます。
他のContinuationをカプセル化して制御データを保存するための追加のArgContExt。
契約の実行中、仮想マシンはメインループに入り、契約のフラグメントを1文字ずつデコードし、対応する操作を適切なハンドラにディスパッチします。通常のハンドラは、対応する操作を実行した後、すぐに返します。
比較的に、反復命令は提供された継続をコンポーネントとして使用して通常ではない継続を作成し、適切な文脈で非通常の継続にジャンプします。非通常の継続自体がロジックを実装してジャンプし、条件に応じてコンポーネントにジャンプします。例えばWHILE命令を使用する場合、図1に示すようにこのプロセスを示すことができます（可能な中断は省略されています）。
図1:非通常のコントリビューションロジック
根本原因
存在するバグの仮想マシンのバージョンでは、これらのジャンプは連続した動的テールコールを引き起こし、これによりホストスタックは各ジャンプごとにスタックフレームを維持する必要があります（図2参照）。
WhileContを例にとって、他の部分は簡潔に省略されています。
図2：トリプルジャンプ再帰による深いトラップへの掘り下げ
理想的な状況では、これは問題にはならないはずです。なぜなら、通常、コンポーネントはOrdContとして表され、そのジャンプは現在のコンテキストのみを保存し、その後、それが保持する断片を実行する仮想マシンに先立って、残りの契約断片を実行するだけで、より多くの再帰を導入しません。ただし、非OrdContは理論上、そのコンポーネントがTVM内のcc（c0）レジスタ（すなわち、set_c0ブランチで上記のように）を介してアクセスできることを許可しています。したがって、契約はこの機能を濫用してデプス再帰を実行することができます（後で説明します）。この通常の機能の実装を変更するよりも、非OrdContのジャンププロセス中に再帰を排除することがより明確で容易です。
既存の非通常のContinuationを繰り返し使用して、上位の非通常のContinuationを構築することで、デプスネストされたContinuationを反復的に作成することができます。これらのデプスネストされたContinuationは、評価時にホストの利用可能なスタック領域を使い果たす可能性があり、オペレーティングシステムがSIGSEGVシグナルを発行して仮想マシンプロセスを終了することがあります。
図3は、ネストプロセスの概念検証（PoC）を提供しています。
図3：罠設置プロセス
私たちは、各イテレーションで、本体がWhileCont{chkcond=true}を拡張していることを確認しました。前回のイテレーションで生成および保存されたccを実行することで、次のような呼び出しスタックが得られます:
スタック領域とネストのレベル（つまり、反復回数）との間には線形の依存関係があることがわかることから、スタック領域の枯渇が引き起こされる可能性があることがわかります。
実際の環境での利用について
実際のブロックチェーンでは、ガス制限により、悪意のあるスマートコントラクトの構築が非常に困難になります。ネストされたプロセスの線形の複雑さ（TVMの設計により、より安価な構築を自己参照を介して防止する効果的な方法）のため、実際に実行可能な悪意のあるスマートコントラクトを開発することは容易ではありません。具体的には、1つのネストは呼び出しシーケンスを生成し、デバッグバイナリで3つのホストスタックフレーム（320バイト）を消費し、公開バイナリで2つのホストスタックフレーム（256バイト、最後の2つの呼び出しはインラインで1つ）を消費します。現代のPOSIXオペレーティングシステム上で実行される検証ノードのデフォルトのスタックサイズは8MiBであり、これは公開バイナリで30,000層以上のネストをサポートするのに十分です。スタックスペースを使い果たすことができるコントラクトを作成することはまだ可能ですが、前のセクションの例よりもはるかに困難です。
緩和 策
このパッチでは、Continuationのネストされた場合のジャンプ動作が変更されました。Continuationのジャンプの署名が変更されたことがわかります。
UntilContを例にとって、他の部分は簡潔に省略されています。
VmState::jumpをもう呼び出さないことで、次のContinuationにジャンプする必要がなくなりました。これは、各Continuationで三重ジャンプを再帰的に実行し、戻り値を後方に伝播することを意味します。現在、Continuationジャンプは単にContinuationの次のレベルを解決し、その後、制御を仮想マシンに返します。
仮想マシンは、連続的に各レベルの continuation を協調的に解析し、NullRef に遭遇するまで、つまり、チェーンの解析が完了するまで（OrdCont や ExuQuitCont で実装されているように）、反復的に解析します。この反復の過程で、ホストスタックには常に1つの continuation ジャンプしか割り当てられないため、スタックの使用が一定に保たれます。01928374656574839201
結論
高可用性のサービスが必要な場合、再帰的な使用は潜在的な攻撃ベクトルとなる可能性があります。ユーザー定義のロジックが関係する場合、強制的な再帰の終了は挑戦的な場合があります。このDoS脆弱性は、リソースが制限された状況（または他の制約条件）で、正常な機能が意図せずに乱用される極端なケースを示しています。再帰がユーザー入力に依存する場合、同様の問題が発生する可能性があり、これは仮想マシンの制御フロー原語では非常に一般的です。
本レポートでは、TONの仮想マシンに存在するDoS攻撃の核心的な技術的詳細、根本的な原因、および攻撃方法について詳しく分析し、TonBitチームが提案した効果的な解決法を紹介しています。仮想マシンの再帰ジャンプメカニズムを反復処理に調整することで、TonBitはこの可能性のあるネットワーク障害の原因となる重大な脆弱性を修正することに成功し、TONエコシステムにより強力なセキュリティ保証を提供しています。この事件は、TonBitがブロックチェーンの基盤技術セキュリティ領域で深い経験を持つことを示すだけでなく、TONの公式セキュリティ保証プロバイダー(SAP)としての重要な役割を示しています。
TONエコシステムにおいて不可欠なセキュリティパートナーとして、TonBitは常にブロックチェーンネットワークの安定性とユーザー資産の安全性を保護することに取り組んでいます。バグ発見から解決策の設計まで、TonBitは強力な技術力とブロックチェーンの発展に対する深い理解に基づいて、TONネットワークの長期的な発展に堅固な基盤を築いています。同時に、TonBitチームは、ネットワークのセキュリティアーキテクチャ、ユーザーデータの保護、およびブロックチェーンアプリケーションシナリオのセキュリティ向上などの領域で引き続き取り組んでいます。将来、TonBitは革新的な安全技術の進歩を推進し、TONエコシステムおよびブロックチェーン産業全体の健全な発展に持続的なサポートと保証を提供し続けます。今回のバグ発見および修正支援作業は、TON公式から高い評価を受け、TonBitのブロックチェーンセキュリティ分野における業界地位をさらに固め、分散型エコシステムの発展を推進する決意を示しました。
TonBit 公式ウェブサイト：
TonBit公式ツイッター:
電報：
Linkedin:
ブログ：#blogs
Telegramの監査要件については、@starchouにお問い合わせください