Storage Proofs

Summary

The ScrvusdVerifierV1 and ScrvusdVerifierV2 contracts do not implement sufficient checks to prevent future block submissions or validate block timestamps, which could lead to oracle manipulation.

Vulnerability Details

Both verifier contracts accept block headers or block numbers without validating that:

• The block is not from the future

• The block header timestamp is reasonable

The contracts accept block headers/numbers without verifying if the block is finalized (sufficiently old to prevent chain reorganizations). This allows potential use of recent blocks that might be reorganized, leading to stale or manipulated data.

The block header timestamp is reasonable
Block timestamps are used directly without checking if they are within a reasonable range (e.g., not in the future or excessively old). This could allow manipulation of time-sensitive price calculations.

For example, in the verifyScrvusdByBlockHash function:

There's no validation that block_header.number is not from the future or that the timestamp is reasonable.

the contracts don't add their own checks on the block number's validity (like ensuring it's not too recent) or the timestamp's validity (like being within an acceptable range). This could allow a malicious actor to use a block that's not yet finalized or use old timestamps to affect the price.

Impact

A malicious actor could:

1. Submit a fake future block with crafted parameters to manipulate the scrvUSD price

2. Submit a valid block hash but with a manipulated timestamp to affect pricing calculations, especially in the v1 and v2 price approximations that rely heavily on timestamps

Tools Used

Manual Review

Onchain Simulation

Recommendations

• Add validation that the submitted block is not from the future:

• In the verifyScrvusdByStateRoot method, validate that the timestamp (which is derived from the last_profit_update parameter) is reasonable: