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**.

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.