Krytyczny błąd wiarygodności (soundness) w SP1, systemie dowodowym zero-knowledge firmy Succinct, otworzył główną sieć Prover Network firmy na nieprawidłowe dowody. SP1 to maszyna wirtualna zero-knowledge (zkVM), zaprojektowana tak, aby umożliwić programistom dowodzenie poprawnego wykonania programów bez ich ponownego uruchamiania, a wiarygodność — gwarancja, że weryfikator akceptuje wyłącznie dowody wykonania, które rzeczywiście przebiegło tak, jak deklarowano — to właściwość, od której zależy każda aplikacja zbudowana na takich dowodach. Zgodnie z poradnikiem bezpieczeństwa GitHub opublikowanym 11 października, Prover Network było jedynym znanym firmie Succinct dotkniętym wdrożeniem.

Poradnik, zarejestrowany jako GHSA-p7v2-jjv3-8p8f, stwierdza, że złośliwy prover mógł przesłać dowód nieprawidłowego wykonania, a weryfikator sieci zaakceptowałby go. Prover Network przyjmuje dowody od zewnętrznych prowerów, co oznacza, że jego weryfikator musi traktować każde zgłoszenie jako potencjalnie wrogie — co czyniło lukę bezpośrednio istotną dla jego działania, ponieważ wiarygodna weryfikacja to właśnie to, co odróżnia autentyczną pracę od sfabrykowanych wyników.

Wykorzystanie luki ograniczone do ścieżki natywnego weryfikatora Rust

Błąd można było wykorzystać wyłącznie, gdy dowody były wysyłane bezpośrednio do natywnego weryfikatora Rust w SP1. Na tej ścieżce naruszone były dowody Core i Compressed.

Testy Groth16 i Plonk pozostały nietknięte, ponieważ opierają się na opakowanych dowodach o stałym kształcie i nigdy nie dotykają kontrolowanego przez prowera formatu tensora, który stanowi sedno problemu. Bezpieczne były również sprawdzenia Solidity używane do weryfikacji Plonk i Groth16 on-chain. Aplikacje wywołujące funkcję verify_sp1_proof w celu weryfikacji dowodów Compressed były chronione tylko wtedy, gdy agregacja dowodów kończyła się dowodem Groth16 lub Plonk.

Zgodnie z poradnikiem dotknięte są wersje od 6.0.0 do 6.8.0 bibliotek sp1_hypercube, sp1_prover i sp1_sdk. Succinct wydała poprawkę w wersji 6.8.1 24 września, 17 dni przed upublicznieniem poradnika, a następnie wdrożyła ją w sieci mainnet Prover Network — taka sekwencja oznaczała, żeająca poprawka była już dostępna, zanim techniczne szczegóły luki stały się publiczne.

Niezgodne etykiety tensorów nie były weryfikowane

Luka znajdowała się w natywnym weryfikatorze Rust SP1, komponencie odpowiedzialnym za ustalanie, czy dowód jest ważny.

SP1 przechowuje dane wielowymiarowe w strukturach zwanych Tensorami. Tensor łączy bufor przechowywanych wartości z zadeklarowanymi wymiarami opisującymi jego kształt, i oba muszą się zgadzać, aby weryfikacja była wiarygodna: liczba przechowywanych elementów musi być równa iloczynowi zadeklarowanych wymiarów.

Każda porcja danych dowodowych zawiera etykietę wskazującą jej rozmiar, ale weryfikator nigdy nie potwierdzał, że etykieta odpowiada rzeczywistej zawartości, opierając się wyłącznie na etykiecie. Atakujący mógł zatem przesłać dane z sfałszowaną etykietą. Różne części weryfikacji odczytywałyby wtedy różne fragmenty tego samego bufora, co oznaczało, że sfabrykowany dowód mógł przejść weryfikację.

Wersja 6.8.1 wprowadza kontrolę długości podczas deserializacji. Każdy tensor, którego liczba przechowywanych elementów nie jest równa iloczynowi zadeklarowanych wymiarów, jest odrzucany.

Kto musi dokonać aktualizacji

Użytkownicy, którzy żądają dowodów z sieci mainnet Prover Network, nie muszą nic zmieniać po swojej stronie. Operatorzy uruchamiający własny natywny weryfikator Rust i akceptujący dowody od prowerów, którym nie ufają, muszą dokonać aktualizacji do wersji 6.8.1. Ponieważ poradnik firmy Succinct mógł obejmować wyłącznie znane sobie wdrożenia, to operatorzy hostingujący samodzielnie są w pozycji, aby sprawdzić, czy ich konfiguracje mieszczą się w dotkniętym zakresie — punktem odniesienia jest lista wydanych objętych problemem w poradniku.

Ujawnienie i powiązane incydenty

Zgodnie z poradnikiem luka została odkryta przez Vitalisa Salisa, który zgłosił ją w ramach programu bug bounty Immunefi.

To ujawnenie dołącza do serii problemów z wiarygodnością systemów dowodowych zgłoszonych w tym roku. Cryptopolitan wcześniej informował o błędzie wiarygodności w chronionej puli Orchard w Zcash oraz o wykorzystaniu luki w Foom.Cash, w którym atakujący sfałszował dowody zkSNARK z powodu błędnej konfiguracji weryfikatora.