Open c4-bot-5 opened 6 months ago
I don't see that the upgradability feature is seriously damaged by the lack of a gap, given this is an ERC20. Potential issues like storage corruption should be caught during governance testing. QA is appropriate.
alcueca changed the severity to QA (Quality Assurance)
alcueca marked the issue as grade-a
alcueca marked the issue as grade-b
Lines of code
https://github.com/code-423n4/2024-04-renzo/blob/1c7cc4e632564349b204b4b5e5f494c9b0bc631d/contracts/Bridge/xERC20/contracts/optimism/OptimismMintableXERC20.sol#L11
Vulnerability details
Note on Risk Classification:
While automated tools classify the absence of a storage gap in upgradeable contracts as a low-risk issue, I believe that the specific circumstances and potential consequences in our case warrant a higher risk classification. This reassessment is based on several factors:
Contract Value and Functionality: The contracts in question manage significant assets and facilitate critical functionalities within their respective ecosystems. Any disruption caused by storage collisions could therefore lead to disproportionately high impacts.
Complexity of Inheritance: Given that
XERC20
serves as a base for other contracts such asOptimismMintableXERC20
, the propagation effect of this vulnerability could affect multiple derived contracts, thus amplifying potential security threats.Future Upgradeability: The expected frequency and complexity of future upgrades increase the likelihood that the absence of a storage gap could result in serious issues, making proactive mitigation crucial.
Impact
The lack of explicit storage gaps in
XERC20
, which is a base contract forOptimismMintableXERC20
, may lead to storage collisions when new state variables are added toXERC20
in future upgrades. This issue can cause data corruption or incorrect data mapping, severely impacting the contract's integrity and functionality.Proof of Concept
The
XERC20
contract is inherited byOptimismMintableXERC20
. IfXERC20
has new state variables added, without reserved storage spaces (gaps), these new variables would displace the storage mapping ofOptimismMintableXERC20
.Test Case (Foundry)
Test output
Tools Used
Recommended Mitigation Steps
Strategic Structural Changes
OptimismMintableXERC20
as an independent upgradeable contract, separate fromXERC20
. This approach reduces dependency risks and isolates upgrades, significantly mitigating the potential for storage collisions across dependent contracts.Technical Improvements
Introduce Storage Gaps: Ensure future-proofing by modifying the
XERC20
contract to include reserved storage slots that accommodate additional variables in future upgrades:uint256[50] private __gap; // Reserve 50 storage slots for future use
Specify Gap Usage: Clearly define how these gaps should be utilized in future contract versions to prevent misuse or misalignment of the storage structure.
Best Practices Manual: Create a comprehensive guide on best practices for upgrading contracts within your ecosystem, focusing on maintaining the integrity of the storage layout.
Assessed type
Upgradable