Storage Proofs

Summary

In the verifyScrvusdByStateRoot function of ScrvusdVerifierV1.sol, the _block_number parameter is not validated. Because of how BlockHashOracle handles unknown blocks (returning a fallback hash instead of reverting), an attacker can submit arbitrarily large or non-existent block numbers. This can corrupt or freeze oracle updates, causing severe economic and operational risks for protocols relying on accurate scrvUSD price data.

Vulnerability Details

The ScrvusdVerifierV1.sol contract contains a critical vulnerability in the verifyScrvusdByStateRoot function. This function accepts an arbitrary _block_number parameter without any validation before passing it to the block hash oracle:

Root Cause

1. Unvalidated _block_number: The contract never checks whether _block_number is valid, it could be far in the future or an otherwise non-existent block.

2. Fallback Hash Mechanism: The BlockHashOracle returns a fallback_hash for any block it doesn’t explicitly track, rather than reverting.

3. Craftable Proofs Against Fake Roots: With control over _block_number and knowledge of fallback_hash, an attacker can craft “valid” RLP proofs for maliciously tailored state roots.

Fake Price Parameters

• The attacker calls verifyScrvusdByStateRoot with a block number that triggers the oracle to return fallback_hash.

• They supply an RLP proof matching this fallback hash but containing malicious parameter values -- artificially high or low “total_debt”, “totalSupply”, etc.

• Because the contract never checks _block_number, it accepts the manipulated state root and updates local parameters in _updatePrice.

• Permanent DoS on Oracle Updates

  • After calling with a huge _block_number (e.g., 2502^{50}250), the oracle sets self.last_block_number to that extremely high value.

  • Any legitimate updates for actual chain blocks (far lower than 2502^{50}250) will revert with "Outdated" or a similar check in the oracle. This effectively freezes all future real updates until that distant block is reached—which might never happen.

Impact

Impact: High - An attacker can manipulate price data in the Curve USD oracle, leading to incorrect pricing of scrvUSD. This price manipulation affects all integrating protocols that rely on this data, potentially causing economic damage across the DeFi ecosystem. Additionally, by setting an extremely high block number, the attacker permanently blocks legitimate updates until that block height is reached.

Likelihood: Medium - The attack requires crafting valid proofs against an invalid state root, which demands technical expertise. However, the absence of any block number validation makes the attack path directly exploitable without dependencies on other conditions.

POC

The attack consists of two main steps:

Manipulate Price

Block legitimate updates:

The key insight is the BlockHashOracleMock shows the expected behavior:

With an invalid block number, it returns fallback_hash rather than reverting, allowing an attacker to generate proofs that work against this known hash.

Recommendations

Implement proper validation of the _block_number parameter in the verifier contract. Add checks to ensure the block number is:

1. Not greater than the current block number

2. Within a reasonable range of the current block -- no more than 256 blocks in the past due to EVM limitations

3. Corresponds to a block that actually exists on-chain

Additionally, modify the oracle to implement its own validation on block numbers, creating a defense-in-depth approach.