Storage Proofs

Details:
In the _extractParametersFromProof function of ScrvusdVerifierV1, the contract iterates over a set number of proofs to extract storage slot values without verifying that each slot actually exists. If a slot is uninitialized, its value defaults to 0. This can lead to scenarios where critical parameters (such as total_debt, total_idle, or totalSupply) are inadvertently set to 0, which might then be used in price calculations.

Root Cause:
The absence of explicit checks for the existence of each storage slot in the state proof. The contract assumes that missing slots can be read as zero, potentially bypassing necessary validation for proper initialization.

Impact:
If an attacker can craft or manipulate a state proof such that one or more critical storage slots are uninitialized, the contract may pass zero values to the oracle. This could lead to erroneous price updates or miscalculations in the system, potentially destabilizing the financial model and exposing the protocol to further attacks.

Recommendation:
Implement explicit validation to check whether each storage slot exists before using its value. Options include:

• Rejecting proofs where any critical slot is missing or uninitialized.

• Introducing a fallback mechanism that flags uninitialized slots instead of silently defaulting to 0.

• Logging or reverting transactions when unexpected zero values are encountered for critical parameters.

Proof of Concept:
An attacker provides a carefully constructed state proof where one or more proofs corresponding to critical storage slots are deliberately omitted or altered so that their values default to 0. As the contract does not verify the existence of these slots, it assigns the default 0 value. This manipulated input is then passed to the oracle via the update_price function, leading to a miscalculation in the asset’s price update process.