BitsLab's TonBit discovered TON VM core vulnerability: detailed explanation of the root cause of the vulnerability and mitigation measures

This report provides a detailed analysis of the technical details, root causes, and possible attack methods of the core DoS vulnerabilities in the TON Virtual Machine, while demonstrating the efficient solution proposed by the TonBit team.

Recently, the Virtual Machine system of the TON network has undergone a major security upgrade. The security team TonBit under BitsLab successfully discovered and assisted in fixing a critical vulnerability that could lead to TON Virtual Machine resource exhaustion. This vulnerability exploits the recursive mechanism of the Virtual Machine in processing Continuation nesting, which could be abused by malicious contracts, leading to system crashes and network instability.

If this vulnerability is maliciously exploited, it may cause all validating Nodes to crash without consuming a TON, directly threatening the availability of the network. In this incident, TonBit quickly identified the vulnerability with its excellent technical capabilities and proposed an innovative solution by adjusting the internal control flow mechanism of the Virtual Machine, replacing recursion with iteration, successfully creating a safer ecosystem for TON users. The TON official team particularly thanks TonBit for its outstanding contribution to ecosystem security in its latest update announcement.

In the following detailed security report, we will analyze in depth the causes, technical details, and solutions of this vulnerability. The report describes in detail how the vulnerability is exploited to trigger resource exhaustion attacks through the recursive chain built by Depth nesting of Continuation, and how malicious contracts deplete the host's stack space by extending the call stack. At the same time, we will also introduce how the TonBit team thoroughly resolves this issue by eliminating the design flaws of the recursive chain and using a collaborative iteration mechanism. This fix not only significantly improves the stability of the TON network, but also provides important reference for the underlying security of the blockchain industry.

Case Study: DoS Vulnerability in TON VM and Related Mitigation Measures

Introduction

This report describes a DoS (Denial of Service) vulnerability in the TON Virtual Machine and the mitigation measures to address the issue. The vulnerability is caused by the way the Virtual Machine handles Continuation nesting during contract execution. This vulnerability allows malicious contracts to trigger deep recursion during evaluation by creating Continuations and nesting Depth in a specific way, depleting the host's stack space and causing the Virtual Machine to stop running. To mitigate this issue, the Virtual Machine has modified its handling of Continuations and control flow. Now, the Virtual Machine no longer performs sequential tail calls through the Continuation chain, but actively iterates the chain. This approach ensures the use of a constant host stack space, preventing stack overflow.

Overview

According to the official documentation, TON VM is a stack-based Virtual Machine that uses Continuation-Passing Style (CPS) as its control flow mechanism for internal processes and Smart Contracts. The control flow registers are accessible to contracts, providing flexibility.

In TVM, Continuation can theoretically be divided into three categories:

OrdCont (i.e. vmc_std), which contains TON ASM segments that need to be executed, is a first-class object in TVM. Contracts can explicitly create and pass them at runtime to achieve arbitrary control flow.

Non-ordinary Continuation (Extraordinary continuations), typically containing OrdCont as a component, created through explicit iteration primitives and special implicit operations, used to handle the corresponding control flow mechanism.

Additional ArgContExt, encapsulates other Continuations to save control data.

During the contract execution process, the Virtual Machine enters the main loop, decodes one character of the contract fragment each time, and dispatches the corresponding operation to the appropriate handler. The ordinary handler returns immediately after executing the corresponding operation.

Relatively speaking, the iterative instruction will use the provided Continuation as a component to create a non-ordinary Continuation, and jump to a non-ordinary Continuation in the appropriate context. The non-ordinary Continuation itself implements logic when jumping, and jumps to a component based on conditions. For example, when using the WHILE instruction, we can demonstrate this process in Figure 1 (omitting possible exits).

Figure 1: Non-ordinary Continuation Logic

root cause

In vulnerable versions of the Virtual Machine, these jumps result in consecutive dynamic tail calls, requiring the host stack to maintain a stack frame for each jump (as shown in Figure 2).

Taking WhileCont as an example, the other parts are omitted for brevity.

Figure 2: Triple jump recursion to delve into nested trap

Ideally, this should not be a problem because components are typically represented as OrdCont, which only saves the current context and then instructs the Virtual Machine to execute the fragment it holds before the remaining contract fragments, without introducing further recursion. However, non-ordinary Continuations are theoretically 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 Depth recursion (described later). Instead of changing the implementation of this regular feature, it is clearer and easier to eliminate recursion directly in the jump process of non-ordinary Continuations.

By repeatedly using the obtained non-ordinary Continuations to construct the higher-level non-ordinary Continuations, a Depth-nested Continuation can be iteratively created. When evaluating these Depth-nested Continuations, it may exhaust the available stack space of the host, causing the operating system to issue a SIGSEGV signal and terminate the Virtual Machine process.

Figure 3 provides the concept validation (PoC) for the nesting process.

Figure 3: Embedding trap process

We see that in each iteration, the main body expands a WhileCont{chkcond=true}. By executing the cc generated and saved in the last iteration, a call stack like this can be obtained:

It can be seen that the stack space is linearly dependent on the nesting level (i.e., the number of iterations), which indicates that it may lead to stack space exhaustion.

The utilization in practical environment

In the actual Block chain, the gas fee limit makes it quite difficult to construct malicious contracts. Due to the linear complexity of the nesting process (TVM effectively prevents cheaper construction through self-reference), it is not easy to develop practical malicious contracts. Specifically, one layer of nesting will generate a call sequence, consuming three host stack frames (320 bytes) in the debugging binary file, and consuming two (256 bytes, the last two calls are inlined into one) in the published binary file. For the verification Node running on a modern POSIX operating system, the default stack size is 8MiB, which is enough to support nesting of over 30,000 layers in the published binary file. Although it is still possible to construct a contract that exhausts the stack space, this is much more difficult than the example in the previous section.

Relief measures

The patch modifies the behavior of jumping in the case of nested Continuations. We can see that the signature of Continuation jumping has changed.

Taking UntilCont as an example, other parts are omitted for simplicity.

No longer call VmState::jump to jump to the next Continuation, which means recursively executing triple jumps on each Continuation and waiting for the return value to propagate backward. Now, Continuation jumps only resolve the next level of Continuation and then return control to the Virtual Machine.

The Virtual Machine iteratively parses each level of continuation through collaboration until it encounters a NullRef, indicating that the chain parsing is complete (implemented in OrdCont or ExuQuitCont). During this iterative process, only one continuation jump is allocated on the host stack, ensuring constant stack usage.

Conclusion

For services that require high availability, recursive use may become a potential Attack Vector. When involving user-defined logic, enforcing recursive termination may be challenging. This DoS vulnerability demonstrates an extreme case of normal functionality being inadvertently abused under resource-constrained conditions (or other constraints). Similar issues may occur if recursion relies on user input, which is very common in the control flow primitives of the Virtual Machine.

This report details the technical details, root causes, and possible attack methods of the core DoS vulnerability in TON Virtual Machine, while demonstrating the efficient solution proposed by the TonBit team. By adjusting the recursive jump mechanism of the Virtual Machine to iterative processing, TonBit successfully proposed a solution to fix the vulnerability, assisting in repairing this core vulnerability that could potentially cause network paralysis, providing a more robust security guarantee for the TON ecosystem. This incident not only reflects TonBit's deep accumulation in the security field of blockchain underlying technology, but also demonstrates its important role as the official Security Assurance Provider (SAP) for TON.

As an indispensable security partner in the TON ecosystem, TonBit has always been at the forefront of protecting the stability of the blockchain network and the security of user assets. From vulnerability discovery to solution design, with its strong technical capabilities and profound understanding of blockchain development, TonBit has laid a solid foundation for the long-term development of the TON network. At the same time, the TonBit team continues to make efforts in areas such as network security architecture, user data protection, and the improvement of security in blockchain application scenarios. In the future, TonBit will continue to drive security technology innovation and provide continuous support and guarantee for the healthy development of the TON ecosystem and the entire blockchain industry. The vulnerability discovery and assistance in the repair work have been highly recognized by the TON official, further consolidating TonBit's industry position in the field of blockchain security and demonstrating its steadfast commitment to promoting the development of the Decentralization ecosystem.

TonBit official website:

TonBit Official Twitter:

Telegram:

Linkedin:

Blog: #blogs

Telegram audit requirement contact: @starchou