Details:
The functions verifyScrvusdByBlockHash, verifyScrvusdByStateRoot, verifyPeriodByBlockHash, and verifyPeriodByStateRoot are declared as external and lack any form of access control. This means that any address can call these functions, potentially supplying valid-looking or even outdated state proofs. These functions ultimately trigger updates to price parameters or profit unlock times by calling external oracle functions (update_price and update_profit_max_unlock_time).

Root Cause:
The absence of access control modifiers (e.g., onlyOwner, role-based restrictions, or any equivalent mechanism) on these externally callable functions allows any user or attacker to invoke them. The design assumes that the validity of the state proofs will solely prevent malicious updates, which might not hold if an attacker can replay or craft proofs that pass the verification checks.

Impact:
An attacker could potentially trigger these updates arbitrarily by submitting malicious or replayed valid state proofs. This could lead to:

• Erroneous updates of price parameters, potentially causing mispricing.

• Unauthorized adjustments to profit unlock times.

• System instability, which might be exploited further for economic gain or to disrupt the intended operation of the protocol.

Recommendation:

• Implement Access Controls: Restrict these update functions to only authorized addresses. Use modifiers such as onlyOwner or role-based access control (e.g., OpenZeppelin's AccessControl) to limit who can invoke these functions.

• Additional Validation: Even if open access is required by design, implement additional checks to ensure that state proofs are timely and non-replayable. This could involve nonce mechanisms or timestamps to ensure that only fresh and valid proofs are accepted.

• Review Trust Model: Reassess the underlying trust model regarding state proofs and oracle updates to ensure that open access does not introduce exploitable risks.

Proof of Concept:

1. An attacker identifies that the functions are callable by any address.

2. They gather or replay a valid state proof (or even an outdated proof that still meets the contract’s verification criteria).

3. The attacker sends a transaction calling, for example, verifyScrvusdByBlockHash with the gathered proof and a corresponding RLP-encoded block header.

4. The function passes its internal checks (blockhash validity and state proof extraction) and subsequently calls the oracle to update price parameters.

5. As a result, the attacker has managed to trigger an update without authorization, potentially manipulating critical system parameters.