Storage Proofs

Summary

A critical vulnerability has been identified in the ScrvusdProver contract related to an incorrect storage slot calculation for the balance_of_self parameter. It impacts the contract's ability to correctly verify and extract storage values from the sCRVUSD contract, potentially leading to incorrect price updates and oracle manipulation. This issue affects core functionality of the price oracle system and could significantly impact any financial systems relying on the price data.

Vulnerability Details

The vulnerability is located in the PARAM_SLOTS array declaration, specifically in the calculation for the balance_of_self storage slot:

This calculation is incorrect according to Ethereum's storage layout specifications for mappings. In Solidity, a mapping's storage slot is calculated by taking:

where key is the mapping key (in this case, an address) and mappingSlot is the slot number of the mapping itself.

The current implementation reverses the order of parameters, putting the slot number (18) before the address (SCRVUSD). Additionally, the contract appears to be attempting to access its balance in the sCRVUSD contract, which would require using address(this) as the key, not the sCRVUSD address itself.

The correct calculation for accessing a mapping at slot 18 with the key being the contract's address should be:

Impact

The incorrect storage slot calculation leads to several critical issues:

1. Failed Storage Proofs: The contract will attempt to verify and extract data from incorrect storage locations, causing verification failures and preventing the oracle from updating.

2. Data Corruption: If verification doesn't fail outright, the contract will pass incorrect data to the oracle, resulting in faulty price calculations.

3. Oracle Manipulation: An attacker could exploit this vulnerability to manipulate the oracle by crafting proofs that match the incorrectly calculated storage slot but contain malicious data.

4. Financial Loss: As this contract appears to be part of Curve Finance's sCRVUSD system, incorrect price data could lead to significant financial losses for users and protocols that rely on accurate pricing.

5. System Failure: DeFi protocols that depend on this oracle may experience unexpected behavior, potentially leading to system-wide failures or disruptions.

Tools Used

Manual review

Recommendations

1. Correct the Storage Slot Calculation: Update the storage slot calculation to follow Ethereum's storage layout specifications:

1. Verify Against Contract Implementation: Confirm the actual storage layout of the sCRVUSD contract to ensure all slot calculations are correct. This may require examining the sCRVUSD contract source code or deployed bytecode.

2. Add Unit Tests: Implement comprehensive unit tests to verify storage slot calculations against known values from the live contract.

3. Consider Using Storage Layout Libraries: Use established libraries or tools for calculating storage slots to avoid manual errors.

4. Perform On-Chain Verification: Before deploying, verify the calculations against the live chain to ensure they retrieve the expected values.

5. Implement Safety Checks: Add sanity checks to validate that extracted values are within expected ranges.