Reverts on Unknown Blocks Without Fallback Handling
Summary
The functions get_block_hash(_number) and get_state_root(_number) revert when queried with unknown block numbers. This behavior can cause unintended failures in contracts that rely on these functions but do not implement proper error handling.
Vulnerability Details
The oracle functions get_block_hash(_number) and get_state_root(_number) assume that the requested block data is always available. However, if the oracle lacks the requested block information, these functions revert without providing a fallback mechanism.
This design choice can introduce unexpected failures in dependent contracts that expect a return value rather than a transaction failure. If an external contract calls these functions without proper try/catch handling (such as try get_block_hash(_number) {...} catch {...} in Solidity), it may disrupt contract execution, leading to broader protocol disruptions.
Impact
Potential Disruptions: Contracts relying on the oracle may unexpectedly fail, affecting transaction processing and dependent functionalities.
Possible Exploits: Attackers may trigger these failures deliberately in protocols that rely on consistent oracle availability.
Tools Used
Manual code review
Static analysis
Recommendations
Modify the functions to return a default value (e.g.,
bytes32(0)) instead of reverting.Introduce an event log to track failed lookups instead of failing silently.
Encourage dependent contracts to implement proper error handling when querying the oracle.
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.