Критическая уязвимость достоверности (soundness) в SP1 — системе zero-knowledge-доказательств компании Succinct — оставила собственную основную Prover Network компании открытой для недействительных доказательств. SP1 — это zero-knowledge виртуальная машина (zkVM), созданная, чтобы позволять разработчикам доказывать корректное выполнение программ без их повторного запуска, а достоверность (soundness) — гарантия того, что верификатор принимает только доказательства вычислений, которые действительно произошли так, как заявлено, — это свойство, от которого зависит каждое приложение, построенное на таких доказательствах. Согласно advisory по безопасности на GitHub, опубликованному 11 октября, Prover Network была единственным известным Succinct затронутым развертыванием.

В advisory с идентификатором GHSA-p7v2-jjv3-8p8f говорится, что злоумышленный prover мог отправить доказательство недействительного вычисления, и верификатор сети принял бы его. Prover Network принимает доказательства от сторонних provers, а значит её верификатор должен рассматривать каждую отправку как потенциально враждебную — что делало уязвимость напрямую значимой для её работы, поскольку достоверная верификация отличает настоящую работу от подделанных результатов.

Эксплуатация ограничивалась путём нативного Rust-верификатора

Уязвимость можно было эксплуатировать только при отправке доказательств напрямую в нативный Rust-верификатор SP1. На этом пути были уязвимы доказательства Core и Compressed.

Проверки Groth16 и Plonk не пострадали, поскольку они опираются на обёрнутые доказательства фиксированной формы и никогда не затрагивают контролируемый prover формат тензоров, находящийся в центре проблемы. Solidity-проверки, используемые для верификации Plonk и Groth16 on-chain, также были в безопасности. Приложения, вызывающие функцию verify_sp1_proof для проверки доказательств Compressed, были защищены только если агрегация доказательств завершалась доказательством Groth16 или Plonk.

Согласно advisory, уязвимы версии 6.0.0–6.8.0 пакетов sp1_hypercube, sp1_prover и sp1_sdk. Succinct выпустила исправление в версии 6.8.1 24 сентября, за 17 дней до публикации advisory, и затем развернула его в основной Prover Network — такая последовательность означала, что рабочее исправление уже было доступно до того, как технические детали уязвимости стали публичными.

Несовпадающие метки тензоров не проверялись

Уязвимость находилась в нативном Rust-верификаторе SP1 — компоненте, ответственном за определение валидности доказательства.

SP1 хранит многомерные данные в структурах, называемых тензорами (Tensor). Тензор объединяет буфер сохранённых значений с объявленными размерностями, описывающими его форму, и для достоверной верификации оба должны совпадать: количество сохранённых элементов должно равняться произведению объявленных размерностей.

Каждый фрагмент данных доказательства несёт метку с указанием его размера, но верификатор никогда не проверял, соответствует ли метка фактическому содержимому, полагаясь только на метку. Поэтому злоумышленник мог отправить данные с поддельной меткой. Разные части проверки затем читали разные участки того же буфера, из- чего подделанное доказательство могло пройти.

Версия 6.8.1 вводит проверку длины при десериализации. Любой тензор, у которого количество сохранённых элементов не равно произведению объявленных размерностей, отклоняется.

Кому нужно обновиться

Пользователи, запрашивающие доказательства из основной Prover Network, не должны ничего менять на своей стороне. Операторы, использующие собственный нативный Rust-верификатор и принимающие доказательства от недоверенных provers, обязаны обновиться до 6.8.1. Поскольку advisory Succinct могло охватить только известные компании развертывания, именно самостоятельно размещённые операторы должны проверить, попадают ли их конфигурации в затронутый диапазон, ориентируясь на список затронутых версий из advisory.

Раскрытие и связанные инциденты

Виталис Салис обнаружил уязвимость и сообщил о ней через программу багбаунти Immunefi, говорится в advisory.

Это раскрытие пополняет серию проблем достоверности систем доказательств, о которых сообщалось в этом году. Cryptopolitan ранее рассказывал об уязвимости достоверности в shielded pool Orchard в Zcash и об эксплойте в Foom.Cash, где злоумышленник подделал доказательства zkSNARK из-за неправильной конфигурации верификатора.