➡️Vulnerabilities Due to Missing EIP-1967 in Proxy Contracts

When using proxy contracts to upgrade smart contract logic without redeploying the entire contract, proper storage management is critical to avoid storage collisions between the proxy and the implementation contract. EIP-1967 introduces a standard for handling storage slots in upgradeable proxy contracts, ensuring that important variables like the proxy’s implementation address and admin do not overlap with storage slots in the implementation contract.

Failure to adopt EIP-1967 can lead to storage collisions, where storage variables in the proxy and implementation contracts are overwritten, causing unintended behavior or security vulnerabilities. In this tutorial, we will explain the purpose of EIP-1967, the risks of not implementing it, and how to properly adopt it to avoid storage conflicts.

Understanding EIP-1967: Storage Collision Prevention in Proxy Contracts

Proxy contracts are a common design pattern for upgradeable contracts. They work by separating contract logic (in the implementation contract) from data storage (in the proxy contract). This enables developers to upgrade the contract logic without losing data or redeploying the contract.

However, proxy contracts share storage layouts with their implementation contracts. This introduces the risk of storage collisions—where variables in the proxy contract overlap with variables in the implementation contract, potentially causing critical variables to be overwritten or misinterpreted.

EIP-1967 was introduced to solve this problem by defining fixed storage slots for key proxy variables, such as the implementation address and admin. This ensures that these variables do not conflict with storage in the implementation contract, preventing accidental overwriting.

EIP-1967 assigns specific storage slots based on hashed values. For example, the storage slot for the proxy’s implementation address is defined as:

bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;

This ensures that the implementation address is stored in a specific location, preventing it from colliding with other variables.

Vulnerability: Missing EIP-1967 Leads to Storage Collisions

Without implementing EIP-1967, the proxy contract and its implementation may share overlapping storage slots. For example, if the proxy contract inherits from Ownable, the _owner variable may occupy the first storage slot. If the implementation contract also has variables that use the same storage slots, this can lead to storage collisions, where important data is overwritten or corrupted.

In the example below, the proxy contract does not use EIP-1967 to define storage slots for the implementation address, leading to the possibility of storage collisions:

contract CoreProxy is Ownable {
    address private immutable _implement;

    // Proxy logic here...
}

In this case, the proxy’s _owner variable from the Ownable contract could occupy the same storage slot as variables in the implementation contract, causing unintended behavior and security risks.

Impact of Missing EIP-1967

Overwriting Critical Variables: Variables in the proxy and implementation contract can collide and overwrite each other. For example, the proxy’s admin address or implementation address could be overwritten by variables in the implementation contract, breaking the contract’s ability to function or upgrade.
Unintended Behavior: If storage slots are overwritten, the contract might exhibit unexpected behavior, such as unauthorized access to sensitive functions, loss of ownership, or inability to upgrade the implementation contract.
Security Vulnerabilities: In cases where sensitive variables like the owner or admin addresses are overwritten, attackers could exploit this to take control of the contract or perform malicious upgrades.

Tutorial: Vulnerabilities Due to Missing EIP-1967 in Proxy Contracts

Understanding EIP-1967: Storage Collision Prevention in Proxy Contracts

EIP-1967 assigns specific storage slots based on hashed values. For example, the storage slot for the proxy’s implementation address is defined as:

solidityCopy codebytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;

This ensures that the implementation address is stored in a specific location, preventing it from colliding with other variables.

Vulnerability: Missing EIP-1967 Leads to Storage Collisions

In the example below, the proxy contract does not use EIP-1967 to define storage slots for the implementation address, leading to the possibility of storage collisions:

solidityCopy codecontract CoreProxy is Ownable {
    address private immutable _implement;

    // Proxy logic here...
}

Impact of Missing EIP-1967

Overwriting Critical Variables: Variables in the proxy and implementation contract can collide and overwrite each other. For example, the proxy’s admin address or implementation address could be overwritten by variables in the implementation contract, breaking the contract’s ability to function or upgrade.
Unintended Behavior: If storage slots are overwritten, the contract might exhibit unexpected behavior, such as unauthorized access to sensitive functions, loss of ownership, or inability to upgrade the implementation contract.
Security Vulnerabilities: In cases where sensitive variables like the owner or admin addresses are overwritten, attackers could exploit this to take control of the contract or perform malicious upgrades.

Proof of Concept: Storage Collision Example

In the following example, a proxy contract is deployed without using EIP-1967. The _implement variable stores the address of the implementation contract, but because it is not stored in a fixed, isolated storage slot, it may overlap with variables in the implementation contract.

solidityCopy codecontract CoreProxy is Ownable {
    address private immutable _implement;

    function _delegate(address implementation) internal {
        // Delegate call logic
    }
}

If the implementation contract uses the same storage slot (e.g., slot 0 for _owner), the address of the implementation contract could be overwritten by a variable in the implementation logic, leading to malfunction or loss of control.

Mitigation: Implementing EIP-1967 to Avoid Storage Collisions

To avoid storage collisions, the proxy contract should implement EIP-1967 and use predefined storage slots for critical variables like the implementation address and admin address. These storage slots are calculated using hashed values, ensuring they do not overlap with storage in the implementation contract.

Conclusion

Using EIP-1967 to manage storage in proxy contracts is essential to avoid storage collisions between the proxy and implementation contracts. Failure to implement EIP-1967 can result in variables like the implementation address, admin address, and ownership being overwritten, causing serious security vulnerabilities and breaking the upgrade functionality of the contract.

By following this tutorial and using fixed storage slots for critical variables, you can ensure that your proxy contracts are safe from storage collisions and work as intended when upgrading the implementation logic.

PreviousVulnerabilities of Missing EIP-155 Replay Attack Protection NextVulnerability of Design Preventing EIP-165 Extensibility

Last updated 1 month ago