SP1 bug exposed Succinct’s own Prover Network

A high-severity soundness bug in Succinct’s zero-knowledge proving system, SP1, exposed the company’s own mainnet Prover Network to invalid proofs.

The network was the only deployment Succinct was aware of that was affected, according to a GitHub security advisory released Oct. 11.

Native Rust verifiers in 6.0.0 through 6.8.0 could accept invalid proofs

The advisory, filed as GHSA-p7v2-jjv3-8p8f, says a malicious prover could submit a proof for an invalid execution and the network’s verifier would accept it. The Prover Network accepted proofs from third-party provers.

To take advantage of the bug, proofs had to be sent directly to SP1’s native Rust verifier. Core and Compressed proofs were exposed on that path.

The Groth16 and Plonk checks were safe because they used wrapped proofs with fixed shapes and never touched the bug’s prover-controlled tensor format.

The Solidity checkers for on-chain Plonk and Groth16 checks were also unaffected. Apps using the verify_sp1_proof function to check Compressed proofs were only safe if proof aggregation ended in a Groth16 or Plonk proof.

The advisory says that from 6.0.0 to 6.8.0, sp1_hypercube, sp1_prover, and sp1_sdk are affected. The fix was sent out by Succinct in version 6.8.1 on September 24, 17 days before the advisory was made public.

Tensors with storage lengths that don’t match are thrown out by version 6.8.1

SP1’s native Rust verifier had the bug. This is the part of the program that checks if a proof is valid.

SP1 stores multidimensional data in a Tensor. A Tensor consists of a buffer of stored values and declared dimensions describing its shape.

Both need to tally for sound verification. The number of stored elements must be the same as the product of the dimensions that were given.

A label on each piece of proof data shows how big it is. The verifier never made sure that what was on the label matched what was inside. It only looked at the label.

So an attacker could send data with a fake label. Different parts of the check would then look at various parts of the same data, which means that a fake proof could pass.

With version 6.8.1, there is now a length check in deserialization. Any tensor that has a number of stored elements not equal to the product of its declared dimensions is rejected.

After 6.8.1 was published, Succinct deployed the fix to the mainnet Prover Network.

People who request proofs from the network don’t have to change anything on their end. Anyone who runs their own native Rust verifier and accepts proofs from provers they don’t trust needs to upgrade to 6.8.1.

Vitalis Salis found the flaw and reported it through Immunefi’s bug bounty program, the advisory says.

Other proof-system soundness bugs, including a soundness bug in Zcash’s Orchard shielded pool, have been reported this year by Cryptopolitan. Cryptopolitan also discussed an exploit at Foom.Cash where an attacker forged zkSNARK proofs because of a verifier misconfiguration.