Ein hochgradiger Soundness-Fehler in SP1, Succincts Zero-Knowledge-Beweissystem, setzte das Mainnet Prover Network des Unternehmens selbst ungültigen Beweisen aus. SP1 ist eine Zero-Knowledge Virtual Machine (zkVM), die Entwicklern ermöglicht, die korrekte Ausführung von Programmen nachzuweisen, ohne sie erneut auszuführen, und Soundness — die Garantie, dass ein Verifizierer nur Beweise für tatsächlich wie behauptet erfolgte Ausführungen akzeptiert — ist die Eigenschaft, von der jede auf solchen Beweisen aufgebaute Anwendung abhängt. Laut einer am 11. Oktober veröffentlichten GitHub-Security-Advisory war das Prover Network die einzige Bereitstellung, von der Succinct wusste, dass sie betroffen war.

Die unter der Kennung GHSA-p7v2-jjv3-8p8f eingereichte Advisory besagt, dass ein bösartiger Prover einen Beweis für eine ungültige Ausführung einreichen konnte und der Verifizierer des Netzwerks diesen akzeptiert hätte. Das Prover Network akzeptiert Beweise von Drittanbieter-Provern, was bedeutet, dass sein Verifizierer jede Einreichung als potenziell feindlich behandeln muss — was den Fehler direkt für seinen Betrieb relevant machte, da die solide Verifizierung das ist, was echte Arbeit von fabrizierten Ergebnissen unterscheidet.

Ausnutzung auf den Pfad des nativen Rust-Verifizierers beschränkt

Der Fehler konnte nur ausgenutzt werden, wenn Beweise direkt an SP1s nativen Rust-Verifizierer gesendet wurden. Core- und Compressed-Beweise waren auf diesem Pfad gefährdet.

Groth16- und Plonk-Prüfungen waren nicht betroffen, da sie auf umhüllten Beweisen mit fester Form beruhen und das prover-kontrollierte Tensor-Format, das im Zentrum des Problems steht, niemals berühren. Die Solidity-Prüfer für On-Chain-Verifikation von Plonk und Groth16 waren ebenfalls sicher. Anwendungen, die die Funktion verify_sp1_proof aufrufen, um Compressed-Beweise zu verifizieren, waren nur geschützt, wenn die Beweisaggregation in einem Groth16- oder Plonk-Beweis endete.

Laut der Advisory sind die Versionen 6.0.0 bis 6.8.0 von sp1_hypercube, sp1_prover und sp1_sdk betroffen. Succinct lieferte den Fix am 24. September in Version 6.8.1 aus, 17 Tage bevor die Advisory öffentlich gemacht wurde, und spielte ihn anschließend auf dem Mainnet Prover Network aus — eine Reihenfolge, die bedeutete, dass ein funktionierender Fix bereits verfügbar war, bevor die technischen Details der Schwachstelle öffentlich wurden.

Falsch deklarierte Tensor-Labels blieben ungeprüft

Die Schwachstelle lag in SP1s nativem Rust-Verifizierer, der Komponente, die dafür verantwortlich ist, ob ein Beweis gültig ist.

SP1 speichert mehrdimensionale Daten in Strukturen namens Tensoren. Ein Tensor kombiniert einen Puffer gespeichertererte mit deklarierten Dimensionen, die seine Form beschreiben, und beide müssen für eine solide Verifizierung übereinstimmen: Die Anzahl der gespeicherten Elemente muss dem Produkt der deklarierten Dimensionen entsprechen.

Jedes Stück Beweisdaten trägt ein Label, das seine Größe angibt, doch der Verifizierer bestätigte nie, dass das Label mit dem tatsächlichen Inhalt übereinstimmte, und konsultierte allein das Label. Ein Angreifer konnte daher Daten mit einem gefälschten Label einreichen. Verschiedene Teile der Prüfung lasen dann unterschiedliche Abschnitte desselben Puffers, was bedeutete, dass ein fabrizierter Beweis bestehen konnte.

Version 6.8.1 führt eine Längenprüfung während der Deserialisierung ein. Jeder Tensor, dessen Anzahl gespeicherter Elemente nicht dem Produkt seiner deklarierten Dimensionen entspricht, wird abgelehnt.

Wer ein Upgrade benötigt

Nutzer, die Beweise vom Mainnet Prover Network anfordern, müssen nichts ändern. Betreiber, die ihren eigenen nativen Rust-Verifizierer betreiben und Beweise von Provern akzeptieren, denen sie nicht vertrauen, müssen auf 6.8.1 upgraden. Da Succincts Advisory nur die bekannten Bereitstellungen erfassen konnte, sind selbst gehostete Betreiber diejenigen, die prüfen müssen, ob ihre eigenen Setups im betroffenen Bereich liegen — mit der Liste der betroffenen Versionen in der Advisory als Referenz.

Offenlegung und verwandte Vorfälle

Vitalis Salis entdeckte die Schwachstelle und meldete sie laut der Advisory über Immunefis Bug-Bounty-Programm.

Die Offenlegung reiht sich in eine Reihe von Soundness-Problemen in Beweissystemen ein, die in diesem Jahr gemeldet wurden. Cryptopolitan berichtete zuvor über einen Soundness-Fehler in Zcashs Orchard Shielded Pool und einen Exploit bei Foom.Cash, bei dem ein Angreifer zkSNARK-Beweise fälschte, weil ein Verifizierer falsch konfiguriert war.