The ScrvusdVerifierV1 and ScrvusdVerifierV2 contracts expose multiple functions (verifyScrvusdByBlockHash, verifyScrvusdByStateRoot, verifyPeriodByBlockHash, verifyPeriodByStateRoot) that lack proper access control, allowing any address to submit block headers or storage proofs.
Although the ScrvusdOracleV2 contract employs access control for functions like update_price and update_profit_max_unlock_time, these functions do not prevent unauthorized users from affecting the contract’s state cause the msg.sender
are the ScrvusdVerifierV1 and ScrvusdVerifierV2 contracts, which could lead to potencial data manipulation or price control vulnerabilities. Even though attackers cannot forge valid storage proofs, they can still submit valid but unauthorized data, leading to potential state manipulation.
The update_price and update_profit_max_unlock_time functions include the check assert self.last_block_number <= _block_number, "Outdated"
, which is intended to prevent outdated block number submissions.
However, attackers can exploit this by repeatedly submitting data with the current block.number. By submitting data before the price is updated (or before the correct block number is processed), an attacker could manipulate the contract by triggering price updates based on old data. (Replay Attacks)
1. Price Manipulation:
Since attackers can repeatedly submit old prices and valid block headers, they can manipulate the price parameters in the contract. This would result in inaccurate pricing, especially in scenarios where the contract is relied upon for price feeds.
2. Arbitrage Opportunities:
By manipulating the prices before the contract correctly updates, attackers can exploit discrepancies between the manipulated price and the true market price. This creates arbitrage opportunities, leading to potential financial losses for liquidity providers and other users relying on the oracle.
Manual Review
Add access control in the verifyScrvusdByBlockHash, verifyScrvusdByStateRoot, verifyPeriodByBlockHash, verifyPeriodByStateRoot functions.
Invalid, all state roots and proofs must be verified by the OOS `StateProofVerifier` inherited as `Verifier`, so there is no proof that a permisionless `verify`functions allow updating malicious prices
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.