Partnered With:

Unsolvable compiler vulnerabilities? Runtime Protection implements DeFi on-chain risk control protection.

Read this article in 12 Minutes

"White-box" is unbreakable, how to defend against unknown vulnerabilities?

Original author: Artela Chinese blog

TL; DR

Re-entry attacks remain a challenge, and existing defense measures mainly focus on the protocol source code level, which only takes effect before the contract enters the runtime state.

"Runtime protection" is an important supplement to DeFi security. Its purpose is to "protect execution results" and ensure that protocol execution is consistent with its intended design.

EVM's design does not support "runtime protection" because smart contracts cannot access all runtime state context information.

Artela is exploring a paradigm of EVM+Extension execution layer to enhance the execution layer and eliminate re-entry attacks.

Artela implements on-chain "runtime protection" extension through Aspect Programming.

We gradually demonstrated how to prevent reentrancy attacks on the Curve contract through Aspect.

Why is reentrancy still a challenge despite the existence of risk control measures?

Despite the fact that replay attacks are a well-known issue and many risk control measures have been implemented, security incidents involving such attacks have continued to occur over the past two years:

Curve Finance Attack (July 2023) - $60 million. Curve suffered a re-entry attack due to a compilation flaw in its contract programming language, Vyper.

Origin Protocol Attack (November 2022) - $7 million. The stablecoin project, Origin Dollar (OUSD), was subjected to a reentrancy attack.

Siren Protocol Attack (September 2021) - $3.5 million, AMM pool suffered a re-entry attack.

Cream Finance Attack (August 2021) - $18.8 million, attacker exploited a reentrancy vulnerability for secondary lending.

Currently, the focus of preventing reentrancy attacks is mainly on the source code level of smart contracts. Measures include integrating OpenZeppelin's ReentrancyGuard and conducting security audits on the contract logic code to avoid predefined security risks.

This method is called "white-box" solution, which aims to avoid vulnerabilities at the source code level and minimize logical errors. However, its main challenge is the inability to defend against unknown risks.

Translating a contract from source code to actual runtime is a challenging process. Each step may bring unforeseen issues for developers, and the contract source code itself may not fully cover all potential scenarios. In the case of Curve, due to compiler issues, even if the protocol source code is correct, there may still be differences between the final runtime result and the expected design of the protocol.

We Need Runtime Protection

Unlike existing risk control measures that focus on the protocol source code level and take effect before execution, runtime protection involves protocol developers writing runtime protection rules and operations to handle unforeseen circumstances during execution. This helps to assess runtime execution results in real-time and respond accordingly.

Runtime protection is crucial in enhancing DeFi security and is an important supplement to existing security measures. By protecting the protocol in a "black box" manner, it enhances security by ensuring that the final runtime results are consistent with the protocol's intended design without directly interfering with contract code execution.

Challenges of implementing runtime protection

Unfortunately, the EVM design does not support runtime protection on-chain, as smart contracts cannot access the complete runtime context.

How to overcome this challenge? We believe the following prerequisites are necessary:

A dedicated module that can access all information across smart contracts, including the entire transaction context.

Obtain necessary authorization from smart contracts, allowing modules to have the right to revert transactions as needed.

Ensure that the functionality of the module takes effect after the execution of the smart contract and before the state is submitted.

EVM is currently facing limitations in addressing the above challenges and is struggling to accommodate more innovation. In the paradigm of modular blockchain, the execution layer needs to explore breakthroughs that go beyond EVM.

Artela's approach is EVM + native extension, which achieves go beyond EVM by building a WASM native extension layer for EVM.

Aspect Programming Introduction

We have launched Aspect Programming, a programming framework that supports Artela blockchain and enables native extension on the blockchain.

Aspect is a programmable native extension module used to dynamically integrate custom functionality into the blockchain at runtime. It serves as a modular supplement to smart contracts, enhancing on-chain functionality.

The feature of Aspect is the ability to access system-level APIs of the underlying blockchain and add extension logic at various join points in the transaction lifecycle. Smart contracts can bind to specific Aspects to trigger extension functionality. When a transaction calls a smart contract, it is also processed through the Aspect associated with that contract.

Aspect Programming 如何实现运行时保护

Aspect Programming How to Achieve Runtime Protection

Aspect can record the execution status of each function call and prevent reentry during the execution of the callback function. When a reentry call occurs during the execution of the callback function, Aspect detects it and immediately withdraws the transaction to prevent attackers from exploiting the reentry vulnerability. In this way, Aspect effectively eliminates reentry attacks, ensuring the security and stability of smart contracts.

Aspect key properties for runtime protection:

You can trigger it after the execution of the smart contract and before the submission of the state: The Aspect module can be set to activate after the execution of the smart contract but before the submission of the state.

Complete transaction context access: Aspect can access the complete transaction context, including the entire transaction information (methods, parameters, etc.), call stack (all internal contract calls during execution), state context changes, and all events triggered by the transaction.

System call capability: Aspect can make system calls and initiate transaction rollback when necessary.

Binding and authorization with smart contracts: Smart contracts can be bound to Aspect and granted permission to participate in transaction processing.

Implementing Aspect for Reentry Protection

In this chapter, we will discuss how to implement runtime protection for Aspect on the chain.

You can deploy an actual "contract protection intent" Aspect at the join points of "preContractCall" and "postContractCall" to prevent reentrancy attacks.

preContractCall: Triggered before the execution of cross-contract calls.

postContractCall: Triggered after the execution of a cross-contract call.

In order to provide reentrancy protection, our goal is to prevent contract reentrancy before the call ends. With Aspect, we can achieve this goal by adding specific logic at the cut points of the transaction lifecycle.

In the "preContractCall" join point, the Aspect monitors the contract call stack. If there is any duplicate call in the call stack (which means unexpected reentry occurred in the locked call), the Aspect will roll back the call.