DelegateCall or Storage Collision Attack on Smart Contracts

The 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 call and delegatecall in Solidity, followed by exploiting the vulnerability of the 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 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 A, and CallA, with the naming convention as below:

• A is the callee,
• CallA is the caller

// 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 (CallA -> callfoo), you can verify that foo() gets called, and the value of ‘x‘ in the callee(A ->x) is set to 15.

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

The above scenario is described in the figure as shown.

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 A and DelegateCallA, with the naming convention as below:

• A is the callee,
• DelegateCallA is the caller

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 (DelegateCallA -> ‘callfoo’), you can verify that foo() gets called and the value of ‘x‘ in the callee(A ->x) is still 0, while the value of x in the caller (DelegateCallA -> x) is 15.

Equipped with the above examples, it is evident that the delegatecall, executes in the caller’s context, while the call executes in the callee context.

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

One use case of 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 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.

Let us write a quick and short proxy, and a logical contract (say V1). For the same, create a file DelegateCall.sol with Proxy and V1 contracts as below.

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.

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 abi.encodedWithSignature("increment_X()"))  is passed as calldata to Proxy (fallback() is triggered), the function increment_X() in V1 is called.

Abi encoding is calculated using the tool,

$ npm install web3-eth-abi

and then

const Web3EthAbi = require('web3-eth-abi');

> Web3EthAbi.encodeFunctionSignature("increment_X()")
'0xeaf2926e'

As discussed above in delegatecall, the storage context of the caller (i.e., Proxy) is used, and the value of 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

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 upgrade() in Proxy as V2 is the new contract we need.

When abi.encodedWithSignature("set_Y(uint256)", 10)) is passed as calldata to proxy, the function increment_Y() in V2 is called.

The value of y is 10, but wait a minute, surprise, surprise!

As there is no y in the 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 0x000000000000000000000000000000000000000A).

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

How to Prevent the Attack

The 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 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 delegatecall can lead to disastrous results with an incorrect understanding or usage.

While using delegatecall, it is vital to keep it in our minds that delegatecall keeps context intact (storage, caller, etc…).

Even though there are certain problems associated with delegatecall, it is very often used in many contracts such as OpenZeppelin, Solidity libraries, EIP2535 diamonds, and many more.

To conclude, use delegatecall, but with care!

---