[Tut] DelegateCall or Storage Collision Attack on Smart Contracts

[xSicKxBot]

DelegateCall or Storage Collision Attack on Smart Contracts

5/5 – (1 vote)



The post is part 6 and continues our Smart Contract Security Series:

• Ownership Exploit
  
  
• Private Variable Exploit
  
  
• Reentrancy Attack
  
  
• tx.origin Phishing Attack
  
  
• Denial of Service Attack
  
  
• Storage Collision Attack
  

The

Code:

DelegateCall

attack or storage collision is expounded in this post.

Before you can grasp this exploit, you must first understand how Solidity saves state variables as explained here. 

We start with the differences between

Code:

call

and

Code:

delegatecall

in Solidity, followed by exploiting the vulnerability of the

Code:

delegatecall

using the proxy contracts (mostly in smart contract upgrades), and then a solution for the attack.

Let’s start the journey!

Call VS DelegateCall

Solidity supports two low-level interfaces for interaction or sending messages to the contract functions.

These interfaces operate on addresses rather than contract instances (using

Code:

this

keyword). The key differences are highlighted with an example.

Call

It allows you to call the code of the callee contract from the caller with the storage context of the callee.

In order to understand this confusing sentence, let’s consider two contracts

Code:

A

, and

Code:

CallA

, with the naming convention as below:

• Code:

  A
  is the callee,
  
  
• Code:

  CallA
  is the caller
  

Code:

// Callee contract A { uint256 public x; function foo(uint256 _x) public { x = _x; } } // Caller contract CallA { uint256 public x; function callfoo(address _a) public { (bool success,) = _a.call(abi.encodeWithSignature("foo(uint256)", 15)); require(success, "Call was not successful"); } }

To test, deploy the contracts on Remix, and when you execute the caller (

Code:

CallA -> callfoo

), you can verify that

Code:

foo()

gets called, and the value of ‘

Code:

x

‘ in the

Code:

callee(A ->x)

is set to

Code:

15

.

Note: It is also possible to send Ether and gas as part of the call using

Code:

value

and

Code:

gas

as params.

The above scenario is described in the figure as shown.

Fig: call flow

DelegateCall

It allows you to call the code of the callee contract from the caller with the storage context of the caller.

As previously mentioned, let’s consider two contracts

Code:

A

and

Code:

DelegateCallA

, with the naming convention as below:

• Code:

  A
  is the callee,
  
  
• Code:

  DelegateCallA
  is the caller
  

Code:

contract A { uint256 public x; function foo(uint256 _x) public { x = _x; } } contract DelegateCallA { uint256 public x; function callfoo(address _a) public { (bool success,) = _a.delegatecall(abi.encodeWithSignature("foo(uint256)", 15)); require(success, "Delegate Call was not successful"); } }

To test, deploy the contracts on Remix, and when you execute the caller (

Code:

DelegateCallA -> ‘callfoo’

), you can verify that

Code:

foo()

gets called and the value of

Code:

‘x‘

in the

Code:

callee(A ->x)

is still 0, while the value of

Code:

x

in the caller (

Code:

DelegateCallA -> x

) is

Code:

15

.

Equipped with the above examples, it is evident that the

Code:

delegatecall

, executes in the caller’s context, while the

Code:

call

executes in the callee context.

A picture speaks a thousand words. The above scenario is in the below figure.

Fig:

Code:

delegatecall

flow

One use case of

Code:

call

is the transfer of Ether to a contract, and it passes all the gas to the receiving function, while the use cases of the

Code:

delegatecall

are when a contract invokes a library with public functions or uses a proxy contract to write smart upgradeable contracts.

Exploit with delegatecall

The most widely adopted technique to upgrade contracts is utilizing a proxy contract.

A proxy interposes the actual logical contract and the dapp interface. To update the logical contract with a new version (say V2), only the new deployed address of the logical contract is passed to the proxy.

This helps achieve minimal or no changes in the dapp/web3 interface, saving a lot of development time.

Fig: Contract upgrade with proxy

Let us write a quick and short proxy, and a logical contract (say V1). For the same, create a file

Code:

DelegateCall.sol

with Proxy and V1 contracts as below.

Code:

contract Proxy { uint256 public x; address public owner; address public logicalAddr; constructor(address _Addr) { logicalAddr = _Addr; owner = msg.sender; } function upgrade(address _newAddr) public { logicalAddr = _newAddr; } // To call any function of the logical contract fallback() external payable { (bool success, ) = logicalAddr.delegatecall(msg.data); require(success , " Error calling logical contract"); } }

V1, This represents version 1 of the logical contract.

Code:

contract V1 { uint256 public x; // abi.encodedWithSignature("increment_X()") = 0xeaf2926e function increment_X() public { x += 1; } }

Compile, deploy and run the contracts in Remix with the constructor param in proxy as the address of the V1 contract.

You can observe that, when the

Code:

abi.encodedWithSignature("increment_X()"))

  is passed as

Code:

calldata

to Proxy (

Code:

fallback()

is triggered), the function

Code:

increment_X()

in V1 is called.

Abi encoding is calculated using the tool,

Code:

$ npm install web3-eth-abi

and then

Code:

const Web3EthAbi = require('web3-eth-abi'); > Web3EthAbi.encodeFunctionSignature("increment_X()") '0xeaf2926e'

As discussed above in

Code:

delegatecall

, the storage context of the caller (i.e., Proxy) is used, and the value of

Code:

x

in Proxy is incremented by 1.

So far, this is all good.

At some point in the future, it is decided to upgrade the V1 contract with new functionality, let’s call it V2.

Create a new contract V2

Code:

contract V2 { uint256 public x; uint256 public y; function increment_X() public { x += 1; } // abi.encodedWithSignature("set_Y(uint256)", 10) //0x1675b4f5000000000000000000000000000000000000000000000000000000000000000a function set_Y(uint256 _y) public { y = _y; } }

Compile and deploy V2.

Pass the address of V2, to

Code:

upgrade()

in Proxy as V2 is the new contract we need.

When

Code:

abi.encodedWithSignature("set_Y(uint256)", 10))

is passed as

Code:

calldata

to

Code:

proxy

, the function

Code:

increment_Y()

in V2 is called.

The value of

Code:

y

is 10, but wait a minute, surprise, surprise!

As there is no

Code:

y

in the

Code:

Proxy

contract, and as the storage context of Proxy is used, it has overwritten the second param in Proxy (i.e., owner) with 10 (or

Code:

0x000000000000000000000000000000000000000A

).

With the owner address changed, the attacker is now in complete control of all the contracts.

How to Prevent the Attack

The

Code:

delegatecall

is tricky to use, and erroneous usage might have disastrous consequences.

For example, possible solutions to the above problem can be

1. If possible, avoid using additional storage variables or go stateless in the upgraded contract – V2.
   
   
2. Mirror the storage layout in V2, in other words, the contract calling
   Code:

   delegatecall
   and the contract being called must have the same storage layout.
   
   
3. By implementing unstructured storage in proxy with the help of assembly code as in OpenZeppelins proxy and not having any storage variables in proxy apart from the logical contract address.
   

Outro

In this tutorial, we saw how

Code:

delegatecall

can lead to disastrous results with an incorrect understanding or usage.

While using

Code:

delegatecall

, it is vital to keep it in our minds that

Code:

delegatecall

keeps context intact (storage, caller, etc…).

Even though there are certain problems associated with

Code:

delegatecall

, it is very often used in many contracts such as OpenZeppelin, Solidity libraries, EIP2535 diamonds, and many more.

To conclude, use

Code:

delegatecall

, but with care!