Author: Artela Chinese blog, medium# Abstract

Re-entrancy attacks are still a challenge. Existing defense methods are mainly focused on the source code level of the protocol, which only take effect before the contract enters the runtime state

"Runtime protection" is an important supplement to DeFi security. It aims to "protect the execution results" and ensure that the execution of the protocol is consistent with its expected design

The design of the EVM does not support "runtime protection", because the smart contract cannot access the full context information of the runtime state

Artela explores an EVM+Extension execution layer paradigm, enhances the execution layer to eliminate re-entry attacks

Artela implements on-chain "runtime protection" extensions through Aspect Programming

We show step-by-step how to prevent reentrancy attacks on the Curve contract through Aspect

Why reentrancy attacks are still a challenge despite existing risk controls

Although reentrancy attacks are a well-known problem and many risk controls have been put in place, security incidents involving such attacks have continued to occur over the past two years:

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

Origin Protocol Attack (November 2022) — $7 million Stablecoin project Origin Dollar (OUSD) suffered a reentrancy attack.

Siren Protocol attack (September 2021) — $3.5 million, AMM pool suffers reentrancy attack.

Cream Finance attack (August 2021) - $18.8 million, attackers exploited a reentrancy vulnerability for secondary borrowing.

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

This approach, known as a "white box" solution, aims to avoid vulnerabilities at the source code level to minimize logic errors. However, its main challenge is the inability to defend against unknown hidden dangers.

"Translating" a contract from source code to actual runtime is a challenging process. Each step may bring unforeseen problems for developers, and the contract source code itself may not fully cover all potential situations. In Curve's case, even if the protocol source code is correct, there may still be discrepancies between the final run and the protocol's intended design due to compiler issues.

It is not enough to rely on the security of the protocol at the source code and compilation level. Even if the source code appears to be flawless, vulnerabilities can still appear unexpectedly due to compiler issues.

We need runtime protection

Unlike existing risk control measures that are concentrated at the protocol source code level and take effect before execution, runtime protection involves protocol developers writing runtime protection rules and operations to handle runtime unforeseen circumstances. This facilitates real-time evaluation and response to runtime execution results.

Runtime protection is critical in enhancing DeFi security and is an important addition to existing security measures. By protecting the protocol in a "black box" manner, it enhances security by ensuring that the final operating result is 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 because smart contracts do not have access to the full runtime context.

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

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

The necessary authorization is obtained from the smart contract, giving the module the right to revert transactions as needed.

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

EVM currently faces limitations in addressing the above challenges and cannot accommodate further innovations. Under the paradigm of modular blockchain, the execution layer needs to explore the breakthrough of go beyond EVM.

Artela's idea is EVM + native extension, by building the WASM native extension layer of EVM to realize go beyond EVM.

Aspect Programming Introduction

We launched Aspect Programming, a programming framework for the Artela blockchain that supports native scaling on the blockchain.

Aspect is a programmable native extension module, which is used to dynamically integrate custom functions into the blockchain at runtime, as a modular supplement to smart contracts, and enhance functionality on the chain.

The feature of Aspect is that it can access the system-level API of the blockchain base layer and add extension logic at each join point of the transaction life cycle. Smart contracts can bind specified aspects to trigger extended functions. When a transaction invokes a smart contract, the transaction is also processed by the aspect associated with the contract.

How Aspect Programming implements runtime protection

Aspect can record the execution state of each function call and prevent reentrancy during callback function execution. When a reentrant call occurs during callback function execution, Aspect detects and rolls back the transaction immediately, preventing attackers from exploiting reentrancy vulnerabilities. With this approach, Aspect effectively eliminates reentrancy attacks, ensuring the security and stability of smart contracts.

Aspect implements key properties for runtime protection:

Can be triggered after smart contract execution and before state submission: Aspect modules can be set to activate after smart contract execution but before state submission.

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 transaction-triggered events.

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

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

Implement Aspect for reentrancy protection

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

An actual "Contract Protection Intent" aspect can be deployed in the join point of "preContractCall" and "postContractCall" to prevent re-entry attacks.

preContractCall: Triggered before the execution of the cross-contract call

postContractCall: triggered after the execution of the cross-contract call

For reentrancy protection, our goal is to prevent contract reentrancy until the call is complete. With Aspect, we can achieve this by adding specific logic at pointcuts in the transaction lifecycle.

In the "preContractCall" pointcut, Aspect monitors the contract call stack. If there are any duplicate calls in the call stack (meaning an unexpected reentrancy in our locked call), the aspect will roll back the call.

Deploy the Curve contract and prevent re-entry attacks

We wrote a Curve mock contract and forged a reentrancy attack to reproduce this process in a more understandable way. The contract code is as follows:

It can be seen that both add_liquidity and remove_liquidity of the above contract are protected by the same re-entry lock lock, which means that if the re-entry protection works normally, the protected function cannot be re-entered by changing the lock (for example, in remove _liquidity calls add_liquidity).

Compile the above contract with vyper compiler 0.2.15, 0.2.16 or 0.3.0 (these versions have known reentrancy protection issues).

We then deploy the above victim contract and attack it with the following contract:

To simulate an actual attack, the attack method of this contract tries to re-enter add_liquidity from the remove_liquidity method through its fallback function. If reentrancy actually occurs, it can be observed in the receipt that an AddLiquidity event is logged before the RemoveLiquidity event.

Now let's use Aspect to protect the contract under attack. Before doing the following, please complete the following steps:

1. Deploy Aspect

2. Bind the victim contract with Aspect

If you are not familiar with Aspect operations, you can check out our developer guide first.

Having done the above, let us now try to call the attack method again to check if the operation will be successful.

From the moving picture (you can view the original link at the end of the article), we can see that the reentrant transaction has been reverted, which means that our Aspect is successfully protecting the victim contract from reentry attacks.

in conclusion

The recent attack on Curve demonstrates yet again that no protocol is 100% completely secure. It is not enough to focus on security at the protocol's source and compile levels. Even if the source code appears to be flawless, vulnerabilities can still appear unexpectedly due to compiler issues.

To enhance the security of DeFi, runtime protection becomes critical. By protecting the protocol in a "black box" manner, ensuring that the execution of the protocol is consistent with its intended design, it can effectively prevent re-entry attacks at runtime.

We forked the Curve contract and fully simulated its recent reentrancy attack, and reproduced the whole process in a more understandable way. Using aspect programming as a new approach to on-chain runtime protection, we show step-by-step how to protect victim contracts with aspects. Our goal is to help root out re-entrancy attacks that DeFi protocols like Curve may suffer from, thereby enhancing security across the entire DeFi space.

With Aspect Programming, developers can not only achieve on-chain runtime protection in the security space, but also enable unprecedented innovative use cases such as intents, JIT, and on-chain automation. In addition, this general framework based on the Cosmos SDK will not only support the Artela blockchain, but also support other blockchains to build native extensions based on their own execution layers.