Delegate Call Vulnerability in Smart Contracts Explained

Delegate calls can exploit storage collisions, allowing unauthorized access to contract variables.

### Understanding Delegate Call and Storage Collision Attacks in Smart Contracts
* 🔍 In this sixth part of the smart contract security series, we delve into delegate calls and storage collision attacks, emphasizing the **importance of understanding Solidity's storage mechanisms**.
* 📚 The text begins by explaining the differences between `call` and `delegate call`, highlighting that `call` operates in the **callee's context** while `delegate call` operates in the **caller’s context**.
* 🔗 A proxy contract is introduced as a means for smart contract upgrades, which allows for the **logical contract to be updated** without changing the **user interface**.
* 🛠 The tutorial provides a detailed example of how `call` and `delegate call` function in practice, demonstrating their **effects on contract storage**.
* ⚠ The potential for exploitation through delegate calls is illustrated, particularly when the **storage layout is not managed correctly**, leading to **unintended overwrites of critical variables**.
* 🔒 To mitigate these risks, it is suggested to **avoid using state variables in upgraded contracts** or to ensure that the **storage layout of the calling and called contracts is mirrored**.
* 🛡 The post concludes with a reminder of the importance of **using delegate calls carefully**, given their prevalence in various contract implementations, including those by **OpenZeppelin** and **EIP-2535 diamonds**.
* 💡 "Delegate call keeps the **context of the storage context of the caller intact**," underscoring the critical nature of **understanding this functionality to avoid vulnerabilities**.

Hello, folks! Welcome to part 6 of our smart contract security series. In this part, we will see what is called a delegate call or storage collision attack. So, to start with, I would recommend that you understand how storage works in Solidity. And for the same, you can go

through my previous post on private exploits. In this, I have explained, I have covered a bit of storage structure here and explained how the storage, how the storage is arranged in the form of slots. With this in mind, then we will start with the differences between what is call and

delegate call. So, once you are clear with how call and delegate call works, then we will see how the delegate call causes the exploit or vulnerability. So, we will see the delegate call vulnerability through a proxy contract. So, what exactly is a proxy contract and why is it needed? We will discuss this and

then we will start with the vulnerability. Usually, this proxy contract is used in the smart contract upgrades, or smart contract upgrades. And then finally, we will see the solution for the problem. So, let's begin the journey. So, we, to start with, what is call and what is

delegate call? So, Solidity has support for two low-level interfaces or interaction or sending messages to the contract functions. And these interfaces operate on addresses rather than the contract instance. So, what exactly is this contract instance? Is that we use the keyword called this. So, we have this, uh,

this dot balance or this dot. So, for example, usually we, we use this keyword called this dot balance to get the balance of the current instance of the contract, right? So, what happens is that call and delegate call don't operate using this, but rather they use the address of the

contract, so I have to use address of the contract dot call or address of the contract dot delegate call. So this is what it means to understand the exact differences. Let's go through an example. So what is call? It allows you to call the code of the

callee contract from the caller contract with the storage context of the callee. So to understand this sentence, it looks a bit confusing, this sentence, but let's understand what it means through an example. Let's consider I have two contracts, A and another contract called as call A, so

here, right, the calling convention or the naming convention, what we can use is very simple. Let's call the A as a callee and call A is going to call the contract A, so it's definitely the caller. So we have A as the callee and call A as the caller.

So consider this contract. I am just going to copy paste this code in Remix so that you get a better view of this. So here I am in Remix, I have just copy pasted that code here. So this is the callee contract and this is the

caller contract. So here you can see here I have declared a simple function, oh, and a public variable X and I'm just going to set this variable. You can call this function as any by any name. And here in the call A, I have called this as because I'm going to call this

foo. I have called it as kolfu, and then I have declared exactly another same variable like this, um, like this, what we have declared here, the same thing has been declared here, and I have made. So here you can see I am passing the address of A

to this contract because, as I said, like call operates on addresses and not on the contract instance. So, I can't use this dot call; it's not possible. I have to use the address of the contract, that is whatever I am passing here, and then dot call and here.

as you know, how to call a function in Solidity is usually in the call, right? We can pass the ABI encoding of this function signature. So, I'm just passing this, who unsigned integer 256, I'm just taking the ABI encoding value of that and then

passing the value as 15. So, x should be set to 15. And if there is a problem with this call, right, if there is any, this call returns a boolean variable called success or pulse, and I am capturing that here and then checking if it is successful or not.

So, let's deploy this contract. It has compiled successfully here. You can see the green tick, so everything is fine, and I will just compile and deploy first the contract A. Once I get the address of A, the deployed address of A, I pass it to the

call for function. So, let's do it. So, let's go here to the deployment section. So, here I am first, so here I have selected contract A, so I will just deploy it. So, this is successful. So, here you can see the deployed address A. So, I'm going to copy the

deployed address, and I'm going to now deploy the call A contract, and let me deploy it, right? So, it is deployed here at some address, and now I am going to trigger this call foo function with the address of A. So, we write, and then I will make

call foo right so this is also successful so everything is fine so what exactly happens now is that because I called so because I made a call to this function so this function gets called and I'm inside that I'm setting the value to 15 so this value x rate of the

collie contract that is contract A is set to 15. So let's read the value of the quality contract so let us go to A and let me read x you can see it's set to 15. So initially it will be by default

storage will be 0 and now it is set to 15. And let's read the value of x in the caller that is called A contract it should be 0 right you can see here by default it's 0. So hope this is now clear with what is call

here so when I make a call we are working we have shifted from the context of caller to the callee context so and then we are setting the value of x here to whatever is the value passed now it is possible that in call right I can also send ether

and gas as part of the call using value so what I can do here is that when I'm making a call so I can pass here also value and then I can pass the amount of ether so I can pass ether here and I can also pass the

gas here how much of the gas is needed so this is possible to pass as part of the call function in Solidity so now the above scenario right I have just depicted it in the form of a figure here you can see so is an end user so this is a caller

so call that is the call a contract and this is a variable x and then I have triggered foo and I have set to 15 I get a so I when I make a call the callee this is basically the contract a function foo gets triggered and the

value of x that is this x right is set to 15. so this is what happens in call so now let's go to what is delegate call so delegate call allows you to call the code of the callee contract from the caller like

the same the same thing like the call from the call interface but with the storage context of the caller which means here the context was that of the callee that is it set the value of x here right in delegate call what will happen is we will use the

storage context of the caller that is this storage will be used so now to demonstrate right let's do exactly so I have the same functionality whatever is described uh in call except that instead of call I will just change it to delegate call [Music]

and I will mention here as delegate call was was not successful so everything remains the same only thing is that I have changed the the functionality from call to delegate call so let's now again redeploy this from the beginning and then see what happens here

so let me go to the first I will deploy contract a so let's deploy it so it's successful so we will copy the address of contract a and you can see here now I will just before we go to con before we go to deploy this call here

Right, I can read the variable x, it will be zero by default, right? You can see here it's zero, and now I will go to call a contract, let me deploy it. So this is also successful here, and this is the call a contract, so let's read the value of x.

So by default, it is 0, all is fine. So now we have copied it, I will just paste it here and then make a call to foo. So now, what is your expectation? So because we have made a delegate call, we expect that this x should be set, but

that is not true. We can verify that this x is set. So this x of the call a contract or the caller contract is used, and so basically we are passing the storage context of the caller. So let's read it, let's go to call a contract and read x.

So this will be set, right? You can see here, set to 15, and still the value of x will be zero here. We'll let's read it again, right? You can see it's still zero. So the color, so I mean the caller context, the value

gets set. What does this mean? So with the equipped with the above example, now it is evident that delegate call executes in the caller's context, and for the call, it executes in the callee context. So I have um, I have depicted, I have just put the same thing here in the figure, so

that it is easy, easy to understand. So here is the user and delegate call, so this is the call a, that is the caller contract, and this is the callee, and I make a call to the foo function, that is I trigger the call call for function with the value set, so

as soon as I make a delegate call, so it calls the function, who, but from the context of the caller. So this X rate is not changed at all. What changes is, like as I have depicted here, this X, that is the caller's X, gets changed to 15.

because we are working in the context, complete context of this caller. So what are the use cases of call and delegate call? So one use case of call can be transfer of ether. So usually, you use a call to send ether, like I have mentioned here. You can send ether and

then you can also pass the gas value of. And the use case of delegate call, or when a contract invokes a library with public function, so what where is delegate call used is usually in libraries. So if you are using a library in, so if I declare here a library for

example, the library, then inside this whatever functionality is added, right, this is all getting called as true. So, and if I use this library in this contract, then this is operating as a delegate call. So that is uh one usage of delegate call, and another another usage of delegate call is in the

proxy contract, usually used for the smart contract upgrades. So we will see what exactly is this smart contract upgrades, and then we will see the exploit from delegate call. So let's see now to explain the exploit with the delegate call, let's see what exactly is a proxy contract and why is

it needed. So the most widely adapted technique to upgrade contracts, right, is by utilizing the proxy contract. So proxy contract, right, interposes between the logical contract, so this is our actual contract which has the functionality that we want to upgrade, and proxy stands in between the actual

contract and the DAP interface that is basically the user interface or the front end. So, to update the logical contract with the new version, let's say I want to move from, I want to add some new functionality to this. Let's call this as V1 and this becomes V2 now.

After the upgrade, only the new deployed address of the logical contract is passed to the proxy. So what happens is that in the proxy contract, we just pass the address of the new logical contract that is V2, and then you are, and then through

and to talk to these logical contracts right, or the actual contracts, we use the functionality of the proxy. So we don't alter the functionality here; we change the functionality only inside this logical contract. So what happens is that with this kind of interface right, it's

quite obvious that we have to change, we don't have to change anything inside this user interface or the front end. So this saves us a lot of development time. So what we need to do is we need to only pass the new address of the logical contract to this proxy contract

and that's it. Now that we are clear with the functionality of this proxy and how it is used in the smart contract upgrade, let's now go or move towards our main topic: how the delegate call causes an exploit. So we will create a small proxy contract, we will create a

small V1 contract, and then a V2 contract. So we will upgrade this V1 to V2. So with all that functionality, whatever we discussed, we will just write it in the form of a code and then we will see the exploit. So I am just going to copy this

proxy here in Remix for a better view and also the V1 contract here which is a very simple contract. We will just put it into Remix and then see how the delegate call works here. Now I have copy-pasted it here in Remix so let's go through this proxy contract.

And what is the V1 contract? Let's go through the V1 first. That is our logical contract. It's very simple. I just declare a variable X and just going to increment this variable's value to Y1, so X is equal to increment X, and X plus is equal to 1.

That is our basic V1 contract, or our logical contract, and the proxy. Right, I am declaring three variables here: one is X, then there is an owner, and then there is a logical address. This logical address right will be nothing but the address of the deployed

contract V1. So here I am writing a constructor where, so in the constructor right, I'll just pass the parameter address, and I will, this address will be pointing to the deployed address V1, and the owner will be the message sender. And then if I want to upgrade now, so

I have to give a functionality to upgrade where I can pass the address, the new address here of the logical contract, that is V1. Instead of V1, we will have V2 that time. It, that's why we need an upgrade, and here I am writing this receive

function. It gets called if no message data is passed, and the callback function. It gets called if I pass some message data, right? Then this gets called. So inside this proxy, I'm using, I'm using this callback to trigger the function of the logical contract. So what I do is I

We'll just take this logical address dot delegate call, like we had discussed previously. I can call that on the address of the contract dot delegate call, and then I am passing this message data here. This message data, whatever I pass, so based on this message data,

so if I pass the message data as this ABI encode of this function, then this function gets triggered, like we have seen previously where I am passing this, basically the ABI encoded with signature. So here in the message data, if I call in ABI encode then of this function, then

this gets called. So this, now it is clear on what is proxy and what is V1. So let's deploy it and let's make some tests on this. So the first thing that I do here is that I will clear everything and then I will first go to the V1 contract.

Right, and let me deploy V1 first. So this is fine, right? So let's read the value of X here. It should be 0 by default, right? It's 0. Everything is fine. And now I will go to, I will just copy the address of this V1

contract because we need it when I deploy proxy. So now, now I go to the proxy which I will pass, and then let me deploy the proxy. So this is fine here. You can see everything is tick mark with green, so this means it was successfully deployed.

So this is our proxy contract. So let's read the address, logical address. This should be the address of our V1 contract, which is 358. So let's read it. Yes, you can see here it's 358 or something. Then let's read owner. This will be the address

It's obvious that I am deploying from 0x55b3, something, so that's the address of the owner. And let's read the value of x. It should be 0 because nothing has been, because I'm just using this x and I have

not initialized it to anything else, so by default it is 0. So everything is fine now. So this is the normal case. Everything looks good. In order to pass the ABI encoded with signature of increment x of the function that we defined, it's important that we use a tool called as

web3-eth-abi. So I have already installed this, npm install, I've already done this, so I will not be doing it again. And then we will follow this to get the ABI encoded value of increment x. So let me do it. So what you need to do is just type in

node, we go into node.js, and then because I've already installed this, I will directly, I can copy paste here, and then followed by this because I am encoding the increment x right, so I will just be right. So you can see here the value 0x

eaf2926e. So the same thing is mentioned here. And now if I pass this value right as message data, then, so if I pass to delegate call message data as this value whatever we calculated, 0x eaf, then what happens is that

this incremental x should get called. So let's check it. Let me go to this, you can see here this low level interactions right, so there is call data. This is basically message data. I can just pass in here and say transact. You can see everything is fine.

it worked and now because we have incremented the value of x, I should get the value of x from it. It should move from 0 to 1. Let's check it. So let's read the value of x because we made a delegate call, the context of

the proxy is used. So let's read the value of x here after calling the increment x function. Yeah, you can see here clearly the value of proxy x has increased by 1, and in v1 it should still be 0. It's obviously it's zero.

So far so good. Now this is a good case. Now let's go at, in some point in the future, if I decide to upgrade my contract from v1 to v2 by adding some new functionality. So what I do is that in v2 I create a new

variable called y, and then I will just call a function set y to set this particular value of y. So I have upgraded my contract from v1 to v2. So I will just copy paste this v2 contract like we did in the, in the remix, like we

did previously. So here I am in remix. I have just pasted it here to get a better view. So here we had this previously increment text. So I have added a new function functionality called as set y, and where I am setting this value of this public variable y.

And now again to call this set y right, I need to, because I need to pass the message data again. So I need to calculate the ABI encoded with signature of set y of unsigned integer 256, and I am setting the value to y of the y to 10.

So, this you have to calculate the ABS signature on this whole stuff and I have already done this for you. And like, by using the previous tool that we, we this web3 ETH EBI tool with this, I am able to calculate the encoding value of this set Y with value

set to 10. It's given here, so it will come to around this big value. So this last 0A represents the value set to 10 and this first eight bytes, right, or the first four bytes represents the ABI encoding of that UI. So, I am back to Remix, so I will go to V2

contract. I need to deploy this. This is deployed. Let me copy the, let me read the values of X and Y. It should both should be 0. Yes, and then I will just copy the address of V2 contract. This is needed when I, when I call the upgrade function in

proxy. Now, now because we have changed or we have moved from V1 to V2, it's time to upgrade our proxy contract with by calling the upgrade function and passing the new address that is the V2's address. So, let us do that. Let us go to

proxy. So in the update the address of V2 and let's upgrade it. So this is all fine. I can read the logical address now. It should be that it should be set to the address of V2, that is DDA. It starts with DDE.

Okay, you can see here it's set to DDA. Owner is still obviously 5B 38 and X value is like it was set to previously 1. So, it is still 1. And at this stage in the proxy, right, I will just call

I'll just call this delegate call through fallback function, and I will trigger this increment Y or set Y to a new value. So, because we already calculated the message data, I will just copy here and then paste it here in call data, and if I transact now

this Y is set to the new Y, that that is 10. Let us transact. Yes, this is fine now. This is successful, so Y is set to 10, and Y of what? Surprise, because we have declared Y in V2, but there is no

Y in proxy. In the previously, when we had this X here, we set that value to, we increment that by one, and as we saw, the value of X got incremented by one, and now we have Y here. So, it's obviously a surprise that we don't have Y in the proxy contract. So

what got set in the country in the storage context of proxy? Because we are using the storage contract context of proxy, what has happened is that the new value of, when we set the new value of Y, it is actually going and updating the owner variable of proxy.

So, now if we read the owner of proxy right, it will be set to 10. So, let's read it. You can see clearly it is set to 10. So, this is the surprise here that we added new variable state variable called as Y

and we go and set it to a new value, and in the proxy, we have overwritten the owner variable. That is the second variable here in in the proxy contract. It now it's obvious to guess that with the owner address change, right, the attacker is now in complete control.

of the contract, so this is the setback of the delegate call interface. So, what are the different ways of preventing the attack, or basically the delegate call or the storage collision attack? Well, delegate call is quite tricky to use, and erroneous usage of this right can cause

a disaster that we already saw, and the possible solution is that try to avoid using storage variables or go stateless in the upgraded contract. So, in so if possible, try to avoid using additional state variables like this, or another possible solution would be that you mirror the storage layout in v2.

So, in other words, the contract calling delegate call and the contract being called right must have the same storage layout. So, what you should do is that like in this v2 contract right, we have to mirror the proxy contract's storage. So, what it means is that you should go to proxy, you

should copy this and put it here. So, we are basically mirroring the proxy contract, and then we can add additional variables. Note, this is not also a very good solution or usually used in in practice or in production because obviously again setting y here can cause some other

some other value in proxy to be set. So, this is also not a very recommended, but it's a possible solution, but not recommended in production. And another possible solution is given by Open Zeppelin's proxy. They have implemented something called as unstructured storage in proxy, and for

the same, they have used assembly language code in Solidity, and it's outside the scope of this post, but you can obviously have a look here in the link is given how they have implemented proxy here. You can see here unstructured storage proxy. What they do is this is the

address implementation is the address of the logical contract or the actual contract we want to interact with and this right is given so this is the storage of the proxy and this is the storage of the implementation they use some random pseudo random slot here to assign the value of the address of this implementation or

the logical contract but you can read the details here from this particular link let's make now a quick conclusion so in this post we saw how delegate call can cause a disaster with an incorrect understanding of the usage it's very important that you remember when you use

delegate call is that it keeps the context of this the storage context of the caller intact so that is very important that you remember this now even though there are a lot of such problems associated with delegate call it is quite often used in many contracts such as open Zeppelin

like we already saw then it's also used in Solidity libraries a lot of Solidity libraries right when you make a call to the library internally it uses delegate call and there is something called as EIP-2535 diamonds that also uses delegate call so

and there are many more so to conclude use delegate call but with care thank you

Storage Collision Attack on Smart Contracts - DelegateCall

Finxter

Introduction to Delegate Call and Storage Collision Attacks

Overview of delegate call/storage collision attacks in Solidity smart contracts.

Recommendation to understand Solidity storage mechanisms before proceeding.

Explanation of the role of proxy contracts in smart contract upgrades.

Discussion of the solution to the delegate call vulnerability.

Solidity's low-level interfaces for contract interaction: `call` and `delegateCall`.

Difference between `call` and `delegateCall`

Explanation of the `call` function: operates in the callee's storage context.

Illustrative example using contracts A (callee) and callA (caller) in Remix.

Demonstrates how `call` uses the address of the contract, not `this` keyword.

Explanation of the `delegateCall` function: operates in the caller's storage context.

Illustrative example modifying the previous code to use `delegateCall`.

Exploiting Delegate Call Vulnerability through Proxy Contracts

Introduction to proxy contracts and their use in smart contract upgrades.

Creation of a proxy contract, V1 contract, and V2 contract for demonstration.

Code walkthrough of the proxy contract and V1 contract in Remix.

Deployment and testing of V1 and proxy contracts.

Upgrading from V1 to V2 and Demonstrating the Exploit

Upgrading the contract from V1 to V2 by adding new functionality.

Calculating ABI encoded values for function calls using web3-eth-abi.

Upgrading the proxy contract to use the V2 contract.

Triggering the exploit by calling `set Y` function, which overwrites the owner variable.

Preventing Delegate Call/Storage Collision Attacks

Discussion of methods to prevent delegate call vulnerabilities.

Solution 1: Avoiding storage variables or using stateless contracts.

Solution 2: Mirroring storage layout in upgraded contracts (not recommended).

Solution 3: Using OpenZeppelin's unstructured storage proxy (using assembly).

Recap of key points regarding delegate call usage and vulnerabilities.

Mention of common uses of delegate call (OpenZeppelin, Solidity libraries, EIP-2535 diamonds).

Final advice: use delegate call cautiously.