Storage Proofs

Summary

The Curve Storage Proofs protocol contains a significant vulnerability where proofs lack proper context binding, allowing them to be reused in unintended contexts. This vulnerability enables attackers to repurpose proofs meant for one verification function to be used in another verification function or contract. The absence of context-specific validation creates a security hazard where state updates could be manipulated across different verification contexts, leading to incorrect state updates and potential economic exploitation.

Vulnerability Details

The vulnerability stems from the absence of context binding in the protocol's proof verification system:

1. Lack of Context Identification: The verification functions in ScrvusdVerifierV1.sol and ScrvusdVerifierV2.sol don't bind proofs to specific contexts or functions:

1. Multiple Verification Functions With Similar Structure: The protocol implements multiple verification functions that accept similar proof formats:

1. Cross-Contract Verification: Different contracts verify different aspects of the protocol state using similar proof formats:

Exploitation Scenario:
An attacker could:

1. Capture a legitimate proof meant for updating price parameters

2. Modify the proof structure to match that expected by the period verifier

3. Submit the modified proof to the period verifier

4. Unintentionally or maliciously update the profit max unlock time with incorrect values

Root Cause:
The fundamental issue is that proofs lack explicit binding to:

• The specific function they're intended for

• The type of state update they should trigger

• The contract that should process them

Impact

Economic Impact:
This vulnerability creates several potential attack vectors:

1. Parameter Manipulation: Critical parameters like profit_max_unlock_time could be updated with values derived from proofs intended for price updates, potentially creating economic imbalances.

2. Oracle Poisoning: By replaying proofs in unintended contexts, an attacker could poison oracle data, creating opportunities for arbitrage or manipulation.

3. Cross-Function State Corruption: State corruption across different verification functions could lead to inconsistent protocol state, affecting pricing and economic calculations.

For a protocol with $10M TVL, the impact could include:

• Manipulated unlock periods affecting yield distributions

• Corrupted price data leading to mispriced assets

• Inconsistent states across different protocol components

• Potential for repeated exploitation as new proofs are generated

Technical Impact:

• Breaks the isolation between different verification functions

• Creates unpredictable interactions between multiple state updates

• Undermines the security model of delegated proof verification

User Impact:

• Unexpected parameter changes could affect user yields and expectations

• Price manipulations could lead to unfair trading conditions

• Protocol governance might have to intervene to correct manipulated states

This vulnerability is classified as HIGH severity because:

1. It enables unauthorized or unintended state changes

2. It affects critical protocol parameters

3. It could be exploited repeatedly with minimal resources

4. It breaks fundamental security assumptions about proof context isolation

Tools Used

• Manual code review focusing on proof verification logic

• Cross-function proof validation testing

• Proof modification and replay simulations

• Context binding analysis across verification functions

• State integrity verification across different proof contexts

Recommendations

Immediate Mitigations:

1. Add explicit context parameters to all verification functions:

1. Implement function-specific nonce tracking:

Long-term Fixes:

1. Redesign the proof format to include explicit context identification that cannot be modified without invalidating the proof.

2. Implement distinct proof formats for different verification functions:

1. Add cryptographic binding between proofs and their intended context:

By implementing these mitigations, the protocol can ensure that proofs are only valid in their intended context, preventing cross-context replay and maintaining the integrity of the state update system.