- Ein schwerwiegender Fehler in der mathematischen Korrektheit von SP1 ließ das eigene Mainnet-Prover-Netzwerk von Succinct für ungültige Beweise offen.
- Der Fehler befand sich im nativen Rust-Verifier von SP1 in den Versionen 6.0.0 bis 6.8.0.
- Succinct hat die Version 6.8.1 zur Behebung des Problems in sein Mainnet-Prover-Netzwerk bereitgestellt.
Ein schwerwiegender Fehler in der mathematischen Korrektheit im nullwissensbasierten Beweissystem SP1 von Succinct machte das eigene Mainnet-Prover-Netzwerk des Unternehmens anfällig für ungültige Beweise.
Das Netzwerk war laut einer am 11. Oktober veröffentlichten GitHub-Sicherheitsberatung die einzige bekannte Bereitstellung von Succinct, die betroffen war.
Native Rust-Verifier in den Versionen 6.0.0 bis 6.8.0 konnten ungültige Beweise akzeptieren
Die Advisory, eingereicht als GHSA-p7v2-jjv3-8p8f, besagt, dass ein bösartiger Prover einen Beweis für eine ungültige Ausführung einreichen könnte und der Verifier des Netzwerks diesen akzeptieren würde. Das Prover Network akzeptierte Beweise von Drittanbieter-Provern.
Um den Fehler auszunutzen, mussten Beweise direkt an den nativen Rust-Verifier von SP1 gesendet werden. Core- und Compressed-Beweise waren auf diesem Pfad exponiert.
Die Groth16- und Plonk-Prüfungen waren sicher, da sie umschlossene Beweise mit festen Formen verwendeten und niemals das vom Prover kontrollierte Tensorformat berührten.
Die Solidity-Checker für On-Chain-Plonk- und Groth16-Prüfungen waren ebenfalls nicht betroffen. Apps, die die Funktion verify_sp1_proof zur Überprüfung von Compressed-Beweisen verwendeten, waren nur dann sicher, wenn die Beweisaggregation in einem Groth16- oder Plonk-Beweis endete.
Laut der Advisory sind sp1_hypercube, sp1_prover und sp1_sdk in den Versionen 6.0.0 bis 6.8.0 betroffen. Die Korrektur wurde von Succinct in Version 6.8.1 am 24. September bereitgestellt, also 17 Tage bevor die Advisory öffentlich gemacht wurde.
Tensoren mit Speicherlängen, die nicht übereinstimmen, werden von Version 6.8.1 verworfen.
Der native Rust-Verifier von SP1 hatte den Fehler. Dies ist der Teil des Programms, der überprüft, ob ein Beweis gültig ist.
SP1 speichert mehrdimensionale Daten in einem Tensor. Ein Tensor besteht aus einem Puffer mit gespeicherten Werten und deklarierten Dimensionen, die seine Form beschreiben.
Beides muss für eine korrekte Überprüfung übereinstimmen. Die Anzahl der gespeicherten Elemente muss dem Produkt der angegebenen Dimensionen entsprechen.
Ein Label auf jedem Teil der Beweisdaten zeigt dessen Größe an. Der Verifizierer hat nie überprüft, ob das auf dem Label angegebene Maß mit dem tatsächlichen Inhalt übereinstimmt. Er hat sich ausschließlich auf das Label verlassen.
Ein Angreifer könnte daher Daten mit einem gefälschten Label senden. Verschiedene Teile der Prüfung würden dann unterschiedliche Bereiche derselben Daten betrachten, wodurch ein gefälschter Beweis bestehen könnte.
Mit Version 6.8.1 gibt es nun eine Längenprüfung bei der Deserialisierung. Jeder Tensor, bei dem die Anzahl der gespeicherten Elemente nicht dem Produkt seiner deklarierten Dimensionen entspricht, wird abgelehnt.
Nach der Veröffentlichung von 6.8.1 hat Succinct die Korrektur im Prover Network der Mainnet bereitgestellt.
Anforderer von Beweisen aus dem Netzwerk müssen nichts ändern. Alle, die ihren eigenen nativen Rust-Verifizierer betreiben und Beweise von nicht vertrauenswürdigen Providern akzeptieren, müssen auf Version 6.8.1 aktualisieren.
Laut der Advisory hat Vitalis Salis den Fehler entdeckt und ihn über das Bug-Bounty-Programm von Immunefi gemeldet.
Andere Fehler in der mathematischen Korrektheit von Beweissystemen, darunter ein Fehler in der mathematischen Korrektheit im Orchard-Shielded-Pool von Zcash, wurden dieses Jahr von Cryptopolitan gemeldet. Cryptopolitan diskutierte zudem einen Exploit bei Foom.Cash, bei dem ein Angreifer zkSNARK-Beweise aufgrund einer Fehlkonfiguration des Verifiers gefälscht hat.
Wenn Sie dies lesen, sind Sie bereits einen Schritt voraus. Bleiben Sie mit unserem Newsletter auf dem Laufenden.
Häufig gestellte Fragen
Was war die SP1-Sicherheitslücke?
Ein Fehler in der Korrektheit des nativen Rust-Verifiers von SP1, der es einem böswilligen Prover ermöglichte, einen Beweis für eine ungültige Ausführung akzeptiert zu bekommen.
Welche SP1-Versionen sind betroffen und welche behebt das Problem?
Die Versionen 6.0.0 bis 6.8.0 sind betroffen; Version 6.8.1 behebt den Fehler.
Müssen SP1-Benutzer Maßnahmen ergreifen?
Anforderer im mainnet-Prover-Netzwerk von Succinct müssen keine Änderungen vornehmen. Teams, die ein separates natives Rust-Verifier-System betreiben, das Beweise von nicht vertrauenswürdigen Provern annimmt, sollten auf Version 6.8.1 aktualisieren.
Haftungsausschluss. Die bereitgestellten Informationen stellen keine Anlageberatung dar. Cryptopolitan.com übernimmt keine Haftung für Investitionen, die auf den auf dieser Seite bereitgestellten Informationen basieren. Wir empfehlen dringend, vor der Entscheidung für eine Anlage unabhängige Recherchen durchzuführen und/oder sich mit einem qualifizierten Fachmann beraten zu lassen.
Randa Moses
Randa Moses ist Redakteurin und Reporterin bei Cryptopolitan, wo sie über Technologie, KI, Robotik, Krypto, Betrug und Hacks berichtet. Sie arbeitet seit 2017 im Krypto-Bereich. Zuvor war sie bei Forward Protocol, AmaZix und Cryptosomniac tätig. Randa besitzt einen Abschluss in Elektrotechnik und Elektronik der University of Bradford.
