Succinctのゼロ知識証明システムSP1における高深刻度の健全性バグにより、同社自身のメインネットProver Networkが無効な証明の受理に晒されていました。SP1はゼロ知識仮想マシン(zkVM)であり、開発者がプログラムの正しい実行を再実行なしで証明できるよう設計されたもので、健全性—検証器が実際に主張どおり行われた実行の証明のみを受理するという保証—は、こうした証明の上に構築されるすべてのアプリケーションが依存する性質です。10月11日に公開されたGitHubセキュリティアドバイザリによると、Prover NetworkはSuccinctが把握している限りで唯一影響を受けたデプロイでした。

GHSA-p7v2-jjv3-8p8fとして提出されたこのアドバイザリは、悪意ある証明者が無効な実行の証明を提出でき、ネットワークの検証器がそれを受理してしまうと述べています。Prover Networkはサードパーティの証明者から証明を受理するため、検証器はすべての提出を潜在的に敵対的なものとして扱わなければなりません。健全な検証こそが正規の作業と捏造された結果を区別するものであるだけに、この欠陥は同ネットワークの運用に直結するものでした。

悪用はネイティブRust検証器の経路に限定

このバグは、証明がSP1のネイティブRust検証器に直接送られた場合にのみ悪用可能でした。この経路では、Core証明とCompressed証明が晒されていました。

Groth16およびPlonkのチェックは影響を受けませんでした。これらは固定形状のラップされた証明に依存し、問題の中心である証明者制御のテンソル形式には決して触れないためです。オンチェーンのPlonkおよびGroth16検証に使用されるSolidityチェッカーも安全でした。verify_sp1_proof関数を呼び出してCompressed証明を検証するアプリケーションは、証明集約がGroth16またはPlonk証明で終わる場合にのみ保護されていました。

アドバイザリによると、sp1_hypercube、sp1_prover、sp1_sdkのバージョン6.0.0〜6.8.0が影響を受けています。Succinctは9月24日、アドバイザリ公開の17日前にバージョン6.8.1で修正を出荷し、その後メインネットProver Networkに展開しました。この順序により、欠陥の技術的詳細が公前に、機能する修正がすでに利用可能になっていました。

不一致のテンソルラベルが検証されずに放置

欠陥は、証明が有効かどうかを判定する役割を担うSP1のネイティブRust検証器にありました。

SP1は多次元データをTensorと呼ばれる構造に格納します。Tensorは格納値のバッファと、その形状を記述する宣言済み次元を組み合わせたものであり、健全な検証には両者の一致が求められます。格納要素の数は宣言された次元の積と等しくなければなりません。

各証明データにはサイズを示すラベルが付いていますが、検証器はラベルが実際の内容と一致することを確認せず、ラベルのみを参照していました。そのため、攻撃者は偽装ラベルを付けたデータを提出できました。チェックの異なる部分が同じバッファの別々の部分を読み取るため、捏造された証明が通過する可能性がありました。

バージョン6.8.1では、デシリアライズ時の長さチェックが導入されています。格納要素の数が宣言された次元の積と等しくないテンソルはすべて拒否されます。

アップグレードが必要な対象

メインネットProver Networkに証明を要求するユーザーは、自身の環境で何かを変更する必要はありません。独自のネイティブRust検証器を運用し、信頼しない証明者からの証明を受理しているオペレーターは、6.8.1へのアップグレードが必要です。Succinctのアドバイザリは把握しているデプロイしか説明できないため、セルフホストのオペレーターが、アドバイザリの影響リリース一覧を参考に、自身のセットアップが影響範囲内かどうかを確認する立場にあります。

開示と関連事案

アドバイザリによると、この欠陥はVitalis Salis氏が発見し、Immunefiのバグバウンティプログラムを通じて報告しました。

今回の開示は、今年報告された一連の証明システムの健全性問題に加わるものです。Cryptopolitanは以前、ZcashのOrchardシールドプールにおける健全性バグと、検証器の設定ミスにより攻撃者がzkSNARK証明を偽造したFoom.Cashのエクスプロイトを取り上げました。