Succinct主網Prover Network因SP1漏洞易受無效證明攻擊

Succinct 零知識證明系統 SP1 中的一起高危健全性漏洞，使其主網證明網絡暴露於無效證明的風險之下。

根據 10 月 11 日發佈的 GitHub 安全公告，該網絡是 Succinct 所知受影響的唯一部署實例。

6.0.0 至 6.8.0 版本的原生 Rust 驗證器可能接受無效證明

編號爲 GHSA-p7v2-jjv3-8p8f 的安全公告指出，惡意證明者可以提交針對無效執行的證明，而網絡的驗證器會予以接受。Prover Network 接受了來自第三方證明者的證明。

要利用此漏洞，證明必須直接發送到 SP1 的原生 Rust 驗證器。Core 和 Compressed 類型的證明在該路徑上暴露了出來。

Groth16 和 Plonk 檢查是安全的，因爲它們使用的是具有固定形狀的包裝證明，從未觸及該漏洞所涉及的由證明者控制的張量格式。

用於鏈上 Plonk 和 Groth16 檢查的 Solidity 檢查器也未受影響。使用 verify_sp1_proof 函數來檢查 Compressed 證明的應用程序僅在證明聚合最終生成 Groth16 或 Plonk 證明時纔是安全的。

安全公告指出，從版本 6.0.0 到 6.8.0，sp1_hypercube、sp1_prover 和 sp1_sdk 均受到影響。Succinct 於 9 月 24 日在 6.8.1 版本中發佈了修復程序，比該安全公告公開時間早了 17 天。

存儲長度不匹配的張量會被 6.8.1 版本丟棄。

SP1 的原生 Rust 驗證器存在此漏洞。這是程序中用於檢查證明是否有效的部分。

SP1 將多維數據存儲在張量（Tensor）中。一個張量由存儲值的緩衝區和描述其形狀的聲明維度組成。

兩者必須一致才能進行有效的驗證。存儲的元素數量必須等於所給維度的乘積。

每條證明數據上都有一個標籤，標明其大小。驗證者從未檢查標籤上的內容是否與內部實際數據一致，它僅查看標籤。

因此，攻擊者可以發送帶有僞造標籤的數據。這樣，檢查的不同部分會查看同一數據的各個部分，從而導致僞造的證明可能通過驗證。

在版本 6.8.1 中，反序列化過程現在增加了長度檢查。任何存儲元素數量不等於其聲明維度乘積的張量都將被拒絕。

6.8.1 版本發佈後，Succinct 已將修復程序部署到主網證明者網絡（Prover Network）。

向網絡請求證明的用戶無需在其端進行任何更改。任何運行自己的原生 Rust 驗證器並接受來自不受信任的證明者的證明的人，都需要升級到 6.8.1。

據該安全公告稱，Vitalis Salis 發現了此漏洞，並通過 Immunefi 的漏洞賞金計劃進行了報告。

Cryptopolitan 今年報告了其他證明系統健全性漏洞，包括 Zcash 的 Orchard 隱私池中的健全性漏洞。Cryptopolitan 還討論了 Foom.Cash 上的一個利用案例，攻擊者因驗證器配置錯誤而僞造了 zkSNARK 證明。

最聰明的加密領域人士已經在閱讀我們的通訊。想加入嗎？加入他們。