Insufficient Block Number Validation
Description:
In update_price and update_profit_max_unlock_time, there's a check that self.last_block_number <= _block_number, but no upper bound check.
Root Cause:
The code only ensures the provided block number isn't outdated but doesn't prevent future block numbers.
Impact:
This could potentially allow updates with future block numbers, which might lead to incorrect price information.
Recommendation
Ensure block numbers are within reasonable bounds (neither too old nor too far in the future).
Lead Judging Commences
[invalid] finding-block-number-no-input-check
- Anything related to the output by the `BLOCK_HASH_ORACLE` is OOS per \[docs here]\(<https://github.com/CodeHawks-Contests/2025-03-curve?tab=readme-ov-file#blockhash-oracle>). - The PoC utilizes a mock `BLOCK_HASH_ORACLE`which is not representative of the one used by the protocol - Even when block hash returned is incorrect, the assumption is already explicitly made known in the docs, and the contract allows a subsequent update within the same block to update and correct prices - All state roots and proofs must be verified by the OOS `StateProofVerifier` inherited as `Verifier`, so there is no proof that manipulating block timestamp/block number/inputs can affect a price update - There seems to be a lot of confusion on the block hash check. The block hash check is a unique identifier of a block and has nothing to do with the state root. All value verifications is performed by the OOS Verifier contract as mentioned above
Prize pool breakdown
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.