Storage Proofs

Summary

Both the ScrvusdVerifierV1.sol and ScrvusdVerifierV2.sol contracts retrieve state roots from an external block hash oracle but do not validate that these state roots are non-zero or otherwise valid before using them for proof verification. This could lead to processing invalid proofs if the state root is unavailable or incorrect, potentially affecting the accuracy of the price and period updates in the scrvUSD oracle system.

Vulnerability Details

Severity: Medium

Files Affected:

• contracts/scrvusd/verifiers/ScrvusdVerifierV1.sol

• contracts/scrvusd/verifiers/ScrvusdVerifierV2.sol

  Functions Affected:

• verifyScrvusdByStateRoot()

• verifyPeriodByStateRoot()

In both contracts, state roots are retrieved from the block hash oracle without validation:

The contracts then proceed to use these potentially invalid state roots for Merkle proof verification:

If the block hash oracle returns a zero state root (which can happen if the requested block is not available), the subsequent proof verification might behave unexpectedly, potentially allowing invalid proofs to be processed.

This is particularly concerning when examining the oracle contract (ScrvusdOracleV2.vy), which relies on accurate parameter updates for its price calculations:

The oracle trusts that these parameters are correctly extracted from valid state proofs, but without proper state root validation, there's a risk of providing incorrect parameters.

Impact

The lack of state root validation could lead to several issues:

1. Processing Invalid Proofs: If the state root is zero or invalid, the Merkle proof verification might still proceed but with incorrect results, potentially extracting invalid parameters.

2. Parameter Manipulation: An attacker could potentially exploit this to manipulate the extracted parameters by providing carefully crafted proofs that work with a zero or invalid state root.

3. Price Calculation Errors: Since the oracle uses these parameters for complex price calculations, invalid inputs could lead to incorrect price determinations:

   # From ScrvusdOracleV2.vy

   def _raw_price(ts: uint256, parameters_ts: uint256) -> uint256:

   parameters: PriceParams = self._obtain_price_params(parameters_ts)

   return self._total_assets(parameters) * 10**18 // self._total_supply(parameters, ts)

4. Oracle Reliability Issues: The contract implicitly trusts the block hash oracle without verifying its output, which could lead to incorrect price or period updates if the oracle malfunctions.

5. Potential DOS: If the state root retrieval consistently fails but doesn't revert, the contract might continue operating with incorrect data, potentially disrupting protocol operations.

Tools Used

• Manual code review

Recommendations

1. Add Explicit State Root Validation:

   • Add a requirement to check that the retrieved state root is non-zero.

1. Implement Block Recency Check:

   • Add validation to ensure the block number is within a reasonable range to prevent using outdated or far-future blocks, which aligns with the oracle's block number validation.

1. Add Event for State Root Retrieval:

   • Emit an event when retrieving a state root to facilitate monitoring and debugging.

1. Parameter Validation:

   • Add validation for the extracted parameters before passing them to the oracle to ensure they're within reasonable bounds based on the oracle's expectations.

By implementing these recommendations, particularly the explicit state root validation and parameter validation, the contracts would be more robust against invalid or malicious inputs and less susceptible to potential exploitation through invalid state roots.