## Summary and Impact The OpenVM STARK backend has a critical vulnerability where the verifier fails to validate the shape of proof structures before using them in the verification process. Specifically, the verifier does not ensure that arrays like `exposed_values_after_challenge` have the expected dimensions, lengths, and phase counts before passing them to crucial verification functions. This vulnerability allows a user to submit proofs with malformed data structures that bypass critical constraint checks. By manipulating these structures (e.g., providing empty arrays where non-empty ones are expected), a user can effectively "turn off" verification for interaction constraints. This completely undermines the security guarantees of the zero-knowledge verification system. The impact is severe because it breaks a fundamental assumption of the STARK verification process: that all constraints are properly evaluated against the correct data. If exploited, users could generate "proofs" for invalid computations that appear valid to the verifier, breaking the soundness property of the proof system. ## Vulnerability Details The vulnerability exists in the `verify_raps` function in the verifier module. This function processes a STARK proof and verifies it against a verifying key, but it doesn't validate that the proof structures have the expected shape before using them in verification logic. Here's the vulnerable code in the `verify_raps` function: ```rust pub fn verify_raps( &self, challenger: &mut SC::Challenger, mvk: &MultiStarkVerifyingKeyView, Com>, proof: &Proof, ) -> Result<(), VerificationError> { let public_values = proof.get_public_values(); // Challenger must observe public values for pis in &public_values { challenger.observe_slice(pis); } // [...] // Verification of challenge phase (except openings, which are done next). let rap_phase = self.config.rap_phase_seq(); let exposed_values_per_air_per_phase = proof .per_air .iter() .map(|proof| proof.exposed_values_after_challenge.clone()) .collect_vec(); let permutation_opened_values = proof .opening .values .after_challenge .iter() .map(|after_challenge_per_matrix| { after_challenge_per_matrix .iter() .map(|after_challenge| { vec![after_challenge.local.clone(), after_challenge.next.clone()] }) .collect_vec() }) .collect_vec(); assert!( proof.commitments.after_challenge.len() <= 1, "at most one challenge phase currently supported" ); let (after_challenge_data, rap_phase_seq_result) = rap_phase.partially_verify( challenger, proof.rap_phase_seq_proof.as_ref(), &exposed_values_per_air_per_phase, &proof.commitments.after_challenge, &permutation_opened_values, ); // [...] } ``` The key issue is that before passing `exposed_values_per_air_per_phase` to `rap_phase.partially_verify()`, the code never checks if the shape of this data matches what's expected based on the verifying key. The function simply assumes that the arrays have the proper dimensions and lengths. The FRI LogUp phase verification logic (used in the `partially_verify` method) relies heavily on these arrays having the correct shape: ```rust fn partially_verify( &self, challenger: &mut Challenger, _partial_proof: Option<&Self::PartialProof>, exposed_values_per_phase_per_air: &[Vec>], commitment_per_phase: &[Commitment], _permutation_opened_values: &[Vec>>], ) -> (RapPhaseVerifierData, Result<(), Self::Error>) where Challenger: CanObserve, { if exposed_values_per_phase_per_air .iter() .all(|exposed_values_per_phase_per_air| exposed_values_per_phase_per_air.is_empty()) { return ( RapPhaseVerifierData { challenges_per_phase: vec![], }, Ok(()), ); } // [...] verification logic that assumes correct shapes } ``` The FRI LogUp implementation has an early return for empty arrays, which a malicious user can exploit by providing empty arrays to bypass critical verification steps. ## Tools Used - Manual Review ## Recommendations To fix this vulnerability, explicit shape validation should be added at the beginning of the `verify_raps` method. The validation should check that the proof's structure matches exactly what's expected based on the verifying key.

Contest	Date	Submissions	Payout
Mighty Finance	Apr 15, 2025	4	$0
OP Labs	Mar 24, 2025	3	$0
BadgerDAO	Mar 5, 2025	1	$15
ThreeS	Mar 3, 2025	2	$101
DefiApp	Feb 10, 2025	2	$12
OpenVM	Jan 27, 2025	2	$0
Daao	Jan 27, 2025	9	$263
Chorus One	Jan 13, 2025	1	$0
Silo Finance	Jan 13, 2025	1	$0
FarcasterAttestation	Jan 13, 2025	3	$223

chainsentry

Public reviews