Details:
The contract ScrvusdVerifierV1 implements two functions for verifying state proofs:

• verifyScrvusdByBlockHash uses the block header’s timestamp directly from the RLP-encoded block header.

• verifyScrvusdByStateRoot uses a timestamp surrogate extracted from the state proof, specifically from params[5], which corresponds to last_profit_update.

This discrepancy means that, depending on the verification path chosen, the oracle update may be based on two different time sources. If the state proof’s value is outdated or manipulated, it can cause the price update to use an incorrect timestamp.

Root Cause:
The root cause is the inconsistency in how the timestamp is sourced across the two verification functions. While one function directly uses the block header’s trusted timestamp, the other repurposes a value (last_profit_update) from the state proof as a timestamp surrogate without ensuring its integrity against manipulation.

Impact:
If an attacker can influence the state proof data (for example, by submitting an outdated or malicious proof), they might manipulate the timestamp used in the oracle update. This could lead to erroneous or exploitable price updates, potentially compromising any time-dependent logic within the oracle, and thereby causing financial losses or system instability.

Recommendation:

• Standardize Timestamp Source: Use the same, trusted timestamp source (preferably the block header’s timestamp) in both verification functions.

• Verification Checks: If a state proof must be used, implement strict validation to ensure that the timestamp surrogate matches or is within an acceptable range of the block header’s timestamp.

• Code Refactoring: Refactor the verification logic so that both functions extract the timestamp from a reliable source, reducing the risk of discrepancies.

Proof of Concept:

1. Setup: An attacker targets the verifyScrvusdByStateRoot function.

2. Manipulated Proof Submission: The attacker crafts a state proof where the last_profit_update (params[5]) is intentionally set to a timestamp that deviates significantly from the actual block timestamp.

3. Execution: The manipulated state proof is submitted, causing the oracle update function (_updatePrice) to use the tampered timestamp surrogate.

4. Outcome: The oracle processes the update with an erroneous timestamp, potentially triggering unexpected behavior in time-dependent pricing logic, leading to incorrect price calculations.