Summary

The ScrvusdVerifier contracts demonstrate inadequate validation of timestamps used in oracle updates, potentially allowing manipulation of price data through inaccurate temporal references.

Vulnerability Details

In the verifyScrvusdByStateRoot function of ScrvusdVerifierV1, the contract uses a storage parameter as a timestamp surrogate without proper validation:

The issue is that params[5] represents last_profit_update from the scrvUSD contract's storage, which is being used as the timestamp for the oracle update. This parameter is:

1. Extracted directly from the provided proof without verification

2. Not validated against any time boundaries

3. Not checked for consistency with the block's actual timestamp

Additionally, the contract fails to ensure the timestamp is recent enough or not set in the future, nor does it compare this value with the actual timestamp from the block being referenced.

Impact

This vulnerability could allow an attacker to:

1. Submit proofs with manipulated timestamp data

2. Cause oracle updates to use incorrect temporal references

3. Potentially influence price calculations that depend on time-weighted values

4. Create opportunities for arbitrage by exploiting temporal inconsistencies in price data

The severity depends on how the Oracle contract uses this timestamp in its price calculations, but it represents a significant risk to the integrity of time-sensitive price data.

Recommendations

1. Add Timestamp Boundary Checks:

1. Use Block Header Timestamp When Available:

   • In the verifyScrvusdByBlockHash function, the block header timestamp is available and should be preferred over storage parameters

2. Cross-validate Time Parameters:

   • Compare timestamp with other temporal indicators (block number, etc.)

   • Implement consistency checks between multiple time-related parameters

3. Time Window Requirements:

   • Define explicit time windows during which updates are valid

   • Reject updates with timestamps outside acceptable ranges

By implementing these recommendations, the contract would significantly reduce the risk of timestamp manipulation and improve the temporal integrity of the oracle system.