Un bug di soundness ad alta gravità in SP1, il sistema di dimostrazione a conoscenza zero di Succinct, ha lasciato aperta a prove non valide la Prover Network mainnet della stessa azienda. SP1 è una macchina virtuale a conoscenza zero (zkVM), progettata per permettere agli sviluppatori di dimostrare la corretta esecuzione di programmi senza doverli rieseguire, e la soundness — la garanzia che un verificatore accetti solo prove di esecuzioni realmente avvenute come dichiarato — è la proprietà da cui dipende ogni applicazione costruita su tali prove. Secondo un avviso di sicurezza GitHub pubblicato l'11 ottobre, la Prover Network era l'unico deployment interessato di cui Succinct fosse a conoscenza.

Classificato come GHSA-p7v2-jjv3-8p8f, l'avviso dichiara che un prover malintenzionato avrebbe potuto inviare una prova di un'esecuzione non valida e il verificatore della rete l'avrebbe accettata. La Prover Network accetta prove da prover di terze parti, il che significa che il suo verificatore deve trattare ogni invio come potenzialmente ostile — rendendo la falla direttamente rilevante per il suo funzionamento, poiché è la verifica corretta a distinguere il lavoro autentico dai risultati fabbricati.

Sfruttabilità limitata al percorso del verificatore Rust nativo

Il bug poteva essere sfruttato solo quando le prove venivano inviate direttamente al verificatore Rust nativo di SP1. Le prove Core e Compressed erano esposte su quel percorso.

I controlli Groth16 e Plonk non erano interessati, perché si basano su prove incapsulate con forme fisse e non toccano mai il formato tensor controllato dal prover al centro del problema. Anche i checker Solidity utilizzati per la verifica on-chain Plonk e Groth16 erano al sicuro. Le applicazioni che chiamano la funzione verify_sp1_proof per verificare le prove Compressed erano protette solo se l'aggregazione delle prove terminava con una prova Groth16 o Plonk.

Secondo l'avviso, le versioni da 6.0.0 a 6.8.0 di sp1_hypercube, sp1_prover e sp1_sdk sono interessate. Succinct ha rilasciato la correzione nella versione 6.8.1 il 24 settembre, 17 giorni prima che l'avviso fosse reso pubblico, e successivamente l'ha distribuita alla Prover Network mainnet — una sequenza che significava che una correzione funzionante era già disponibile prima che i dettagli tecnici della falla diventassero pubblici.

Etichette tensor non corrispondenti non erano verificate

La falla risiedeva nel verificatore Rust nativo di SP1, il componente responsabile determinare se una prova è valida.

SP1 memorizza dati multidimensionali in strutture chiamate Tensor. Un Tensor combina un buffer di valori memorizzati con dimensioni dichiarate che ne descrivono la forma, ed entrambi devono coincidere per una verifica corretta: il numero di elementi memorizzati deve corrispondere al prodotto delle dimensioni dichiarate.

Ogni porzione di dati di prova porta un'etichetta che ne indica la dimensione, ma il verificatore non ha mai confermato che l'etichetta corrispondesse al contenuto effettivo, consultando solo l'etichetta. Un attaccante poteva quindi inviare dati con un'etichetta falsificata. Diverse parti del controllo leggevano così porzioni diverse dello stesso buffer, il che significava che una prova fabbricata poteva passare.

La versione 6.8.1 introduce un controllo della lunghezza durante la deserializzazione. Qualsiasi tensor il cui numero di elementi memorizzati non corrisponde al prodotto delle dimensioni dichiarate viene rifiutato.

Chi deve effettuare l'aggiornamento

Gli utenti che richiedono prove alla Prover Network mainnet non devono apportare modifiche. Gli operatori che eseguono il proprio verificatore Rust nativo e accettano prove da prover non fidati devono aggiornare alla versione 6.8.1. Poiché l'avviso di Succinct poteva tenere conto solo dei deployment di cui era a conoscenza, gli operatori self-hosted sono quelli chiamati a verificare se le proprie configurazioni rientrano nell'intervallo interessato, usando l'elenco delle release impattate contenuto nell'avviso come riferimento.

Divulgazione e incidenti correlati

Vitalis Salis ha scoperto la falla e l'ha segnalata tramite il bug bounty program di Immunefi, secondo l'avviso.

La divulgazione si aggiunge a una serie di problemi di soundness dei sistemi di prova segnalati quest'anno. Cryptopolitan aveva precedentemente trattato un bug di soundness nello shielded pool Orchard di Zcash e un exploit su Foom.Cash in cui un attaccante aveva fabbricato prove zkSNARK a causa di una configurazione errata del verificatore.