Storage Proofs

Summary

Both the ScrvusdVerifierV1.sol and ScrvusdVerifierV2.sol contracts use the Verifier.parseBlockHeader() function to parse RLP-encoded block headers without sufficient error handling. If the RLP decoding fails internally, it may not be properly caught and handled by the contracts. This could lead to unexpected behavior, particularly when interacting with the oracle contract (ScrvusdOracleV2.vy), which relies on accurate block timestamps and numbers.

Vulnerability Details

Severity: Low

Files Affected:

• contracts/scrvusd/verifiers/ScrvusdVerifierV1.sol

• contracts/scrvusd/verifiers/ScrvusdVerifierV2.sol

Functions Affected:

• verifyScrvusdByBlockHash()

• verifyPeriodByBlockHash()

In both contracts, block headers are parsed without try/catch error handling:

If the parseBlockHeader function encounters malformed RLP data or other parsing errors, it may revert with a generic error or produce unexpected results. The contracts do perform some basic validation after parsing:

However, this only checks for a zero hash and doesn't fully validate the parsed block header structure or handle potential parsing exceptions.

The risk is elevated when considering how these values are used by the oracle contract (ScrvusdOracleV2.vy):

The oracle uses the block number to enforce a monotonically increasing sequence of updates, so parsing errors could disrupt this mechanism.

Impact

The lack of comprehensive error handling for block header parsing could lead to:

1. Unpredictable Behavior: If parsing fails in unexpected ways, the contract might behave unpredictably, potentially using partially initialized block header data.

2. Lack of Actionable Error Messages: When parsing fails, users would receive generic errors rather than specific, actionable information about what went wrong.

3. Potential DoS Vector: In some scenarios, carefully crafted invalid block headers might cause parsing to fail in ways that consume significant gas without providing useful error feedback.

4. Limited Debugging Information: Without specific error handling, diagnosing issues with block header parsing becomes more difficult.

5. Block Sequence Disruption: If parsing issues cause incorrect block numbers to be sent to the oracle, it could disrupt the monotonicity checks in the oracle contract.

The overall impact is limited because:

• RLP parsing failures typically result in transaction reversion

• The StateProofVerifier library likely has internal validations

• Subsequent validations like the blockhash check would catch some issues

• The oracle's PRICE_PARAMETERS_VERIFIER and UNLOCK_TIME_VERIFIER roles would restrict who can call these functions (assuming appropriate access control is added)

Tools Used

• Manual code review

Recommendations

1. Add Input Validation Before Parsing:

   • Validate the block header RLP data before attempting to parse it:

1. Implement More Comprehensive Block Header Validation:

   • Add additional validation for the parsed block header, especially for fields used by the oracle:

1. Consider Try/Catch for External Library Calls:

   • If the Solidity version supports it (0.6.0+), use try/catch for external calls:

1. Add Logging for Parsing Attempts:

   • Emit events when parsing is attempted to aid in debugging:

1. Align with Oracle's Block Number Requirements:

   • Ensure block number validation aligns with the oracle's expectations:

By implementing these recommendations, particularly the input validation and more comprehensive block header validation, the contracts would be more robust against invalid or malicious block header inputs, providing clearer error messages and improving debugging capabilities.