BitsLab's TonBit Discovers Core Vulnerability in TON VM: In-Depth Analysis of Root Cause and Mitigation Measures
TechFlow Selected TechFlow Selected
BitsLab's TonBit Discovers Core Vulnerability in TON VM: In-Depth Analysis of Root Cause and Mitigation Measures
This report provides a detailed analysis of the technical details, root causes, and potential attack methods of the core DoS vulnerability in the TON Virtual Machine, while also demonstrating the efficient solution proposed by the TonBit team.
Navigating Web3 tides with focused insightsRecently, the virtual machine system of the TON network underwent a significant security upgrade. TonBit, the security team under BitsLab, successfully discovered and assisted in fixing a critical vulnerability that could have led to resource exhaustion in the TON Virtual Machine (VM). This vulnerability exploited the recursive mechanism used by the VM when handling nested Continuations, potentially allowing malicious contracts to cause system crashes and network instability.
If exploited, this vulnerability could have brought down all validator nodes without requiring an attacker to spend even a single TON, directly threatening the network's availability. In this incident, TonBit leveraged its exceptional technical expertise to quickly identify the flaw and proposed an innovative solution—replacing recursion with iteration in the VM’s internal control flow mechanism—successfully creating a more secure environment for TON users. The official TON team specially acknowledged TonBit’s outstanding contribution to ecosystem security in their latest update announcement.
In the detailed security report below, we will delve into the root cause, technical details, and resolution of this vulnerability. The report explains how the vulnerability constructed recursive chains via deep nesting of Continuations to trigger resource-exhaustion attacks, and how malicious contracts could expand the call stack to exhaust the host's stack space. We will also introduce how the TonBit team eliminated the design flaw in the recursive chain by adopting a cooperative iterative mechanism, effectively resolving the issue. This fix not only significantly enhanced the stability of the TON network but also provided important insights for底层 security across the blockchain industry.
Case Study: DoS Vulnerability in TON VM and Related Mitigation Measures
Introduction
This report describes a Denial-of-Service (DoS) vulnerability in the TON Virtual Machine (VM) and the mitigation measures implemented to resolve it. The vulnerability stemmed from the way the VM handled nested Continuations during contract execution. It allowed malicious contracts to create Continuations and deeply nest them in specific ways, triggering deep recursion during evaluation, exhausting the host's stack space, and ultimately halting the VM. To address this issue, modifications were made to how the VM processes Continuations and control flow. Instead of sequentially tail-calling through a chain of Continuations, the VM now actively iterates through the chain. This approach ensures only constant host stack space is used, preventing stack overflow.
Overview
According to official documentation, the TON VM is a stack-based virtual machine that uses Continuation-Passing Style (CPS) as its control flow mechanism for internal operations and smart contracts. Control flow registers are accessible to contracts, offering flexibility.
Continuations in TVM can theoretically be categorized into three types:
-
OrdCont (i.e., vmc_std), containing TON ASM code fragments to execute, are first-class objects in TVM. Contracts can explicitly create and pass them at runtime to implement arbitrary control flows.
-
Extraordinary continuations, which typically contain OrdCont as components, are created via explicit iteration primitives and special implicit operations to handle corresponding control flow mechanisms.
-
Additional ArgContExt, which encapsulate other continuations to preserve control data.
During contract execution, the VM enters a main loop where it decodes one instruction at a time and dispatches the appropriate handler. Ordinary handlers return immediately after executing their operation.
In contrast, iteration instructions use the provided Continuation to create an extraordinary continuation and jump to it within the proper context. The extraordinary continuation itself implements logic upon jumping and conditionally transfers control to one of its components. For example, using the WHILE instruction, this process can be illustrated as shown in Figure 1 (possible exits omitted).
Figure 1: Extraordinary Continuation Logic
Root Cause
In the vulnerable version of the VM, these jumps resulted in consecutive dynamic tail calls, each requiring the host stack to maintain a stack frame (as shown in Figure 2).
Using WhileCont as an example; other parts are omitted for simplicity.
Figure 2: Recursive triple jump in deep nesting
Ideally, this would not pose an issue because components are usually represented as OrdCont, whose jumps simply save the current context and instruct the VM to execute the held fragment before proceeding with the remaining contract code—without introducing further recursion. However, extraordinary continuations are designed to allow their components to access the cc (c0) register in TVM (i.e., the set_c0 branch mentioned earlier). Therefore, contracts can abuse this feature to perform deep recursion (described later). Rather than altering the implementation of this standard functionality, eliminating recursion directly during the jump process of extraordinary continuations proves clearer and easier.
By repeatedly reusing obtained extraordinary continuations to construct higher-level ones, a deeply nested Continuation structure can be built through iteration. When evaluated, such deeply nested structures may exhaust the available stack space on the host, causing the operating system to send a SIGSEGV signal and terminate the VM process.
Figure 3 provides a proof-of-concept (PoC) demonstration of the nesting process.
Figure 3: Nesting Process
We observe that in each iteration, the body extends a WhileCont{chkcond=true}. Executing the cc generated and saved from the previous iteration results in a call stack resembling:
It is evident that stack usage has a linear dependency on the nesting depth (i.e., number of iterations), indicating potential for stack exhaustion.
Practical Exploitation in Real-World Environments
In real-world blockchain environments, gas limits make constructing malicious contracts considerably difficult. Due to the linear complexity of the nesting process (the TVM design effectively prevents cheaper construction via self-references), developing a practically viable malicious contract is non-trivial. Specifically, one level of nesting generates a call sequence consuming three host stack frames (320 bytes) in debug binaries, or two (256 bytes, with the latter two calls inlined) in release binaries. For validator nodes running on modern POSIX systems with default 8MiB stack size, this allows over 30,000 levels of nesting in release builds. Although it remains possible to build a contract capable of exhausting stack space, doing so is far more challenging than the simplified example described above.
Mitigation Measures
The patch modifies the behavior of jumps in cases involving Continuation nesting. We can see that the signature of Continuation jumps has changed.
Taking UntilCont as an example; others omitted for clarity.
Instead of calling VmState::jump to transfer control to the next Continuation—meaning recursively performing triple jumps on each Continuation and waiting for return values to propagate backward—the new implementation has Continuation jumps resolve only the next level of the Continuation, then return control to the VM.
The VM cooperatively iterates through each level of the Continuation chain until encountering a NullRef, signaling completion of the chain (as implemented in OrdCont or ExuQuitCont). Throughout this iterative process, only a single Continuation jump frame is ever allocated on the host stack, ensuring constant stack usage.
Conclusion
For services requiring high availability, recursion can become a potential attack vector. When user-defined logic is involved, enforcing termination of recursion can be challenging. This DoS vulnerability exemplifies an extreme case where normal functionality is inadvertently abused under resource constraints (or other limitations). Similar issues may arise whenever recursion depends on user input—a common scenario in VM control flow primitives.
This report provides a detailed analysis of the core DoS vulnerability in the TON Virtual Machine, including its technical details, root cause, and potential exploitation methods, while showcasing the efficient solution proposed by the TonBit team. By transforming the VM’s recursive jump mechanism into an iterative processing model, TonBit successfully resolved a critical vulnerability that could have paralyzed the network, delivering stronger security assurances for the TON ecosystem. This incident highlights TonBit’s deep expertise in blockchain底层 technology security and reaffirms its role as an official Security Assurance Provider (SAP) for TON.
As an indispensable security partner within the TON ecosystem, TonBit continues to lead the industry in safeguarding blockchain network stability and user asset security. From vulnerability discovery to solution design, TonBit has laid a solid foundation for the long-term development of the TON network through its robust technical capabilities and profound understanding of blockchain evolution. Additionally, the TonBit team remains committed to advancing cybersecurity architecture, user data protection, and enhancing security across blockchain application scenarios. Going forward, TonBit will continue driving innovation in security technologies, providing sustained support and protection for the healthy growth of both the TON ecosystem and the broader blockchain industry. This vulnerability discovery and remediation effort received high recognition from the official TON team, further solidifying TonBit’s standing in the blockchain security field and demonstrating its firm commitment to advancing decentralized ecosystems.
TonBit Official Website: https://www.tonbit.xyz/
TonBit Official 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 contact for audit requests: @starchou
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@tonbit_
