Un bug de SP1 dejó la Red Prover mainnet de Succinct expuesta a pruebas inválidas

Un error de solidez de alta gravedad en el sistema de pruebas de conocimiento cero de Succinct, SP1, expuso la red Prover principal de la compañía a pruebas no válidas.

Según una advertencia de seguridad publicada en GitHub el 11 de octubre, esta red fue el único despliegue conocido por Succinct que se vio afectado.

Los verificadores nativos de Rust en las versiones 6.0.0 a 6.8.0 podían aceptar pruebas no válidas

La advisory, registrada como GHSA-p7v2-jjv3-8p8f, indica que un probador malicioso podría enviar una prueba para una ejecución no válida y el verificador de la red la aceptaría. La Prover Network aceptaba pruebas de probadores de terceros.

Para aprovechar este error, las pruebas debían enviarse directamente al verificador nativo de Rust de SP1. Las pruebas Core y Compressed quedaban expuestas en esa ruta.

Las comprobaciones Groth16 y Plonk eran seguras porque utilizaban pruebas envueltas con formas fijas y nunca tocaban el formato de tensor controlado por el probador que contenía el error.

Los verificadores de Solidity para las comprobaciones on-chain de Plonk y Groth16 también resultaron afectados. Las aplicaciones que usaban la función verify_sp1_proof para verificar pruebas Compressed solo eran seguras si la agregación de pruebas terminaba en una prueba Groth16 o Plonk.

La advisory indica que las versiones 6.0.0 a 6.8.0 de sp1_hypercube, sp1_prover y sp1_sdk están afectadas. Succinct publicó la corrección en la versión 6.8.1 el 24 de septiembre, 17 días antes de que se hiciera pública la advisory.

Las tensores con longitudes de almacenamiento que no coinciden son descartados por la versión 6.8.1

El verificador nativo de Rust de SP1 tenía el error. Esta es la parte del programa que verifica si una prueba es válida.

SP1 almacena datos multidimensionales en un Tensor. Un Tensor está compuesto por un búfer de valores almacenados y dimensiones declaradas que describen su forma.

Ambos deben coincidir para una verificación correcta. El número de elementos almacenados debe ser igual al producto de las dimensiones proporcionadas.

Una etiqueta en cada pieza de datos de prueba indica su tamaño. El verificador nunca comprobó que lo indicado en la etiqueta coincidiera con el contenido real; solo miraba la etiqueta.

Por lo tanto, un atacante podría enviar datos con una etiqueta falsa. Diferentes partes de la verificación entonces analizarían distintas secciones de los mismos datos, lo que permitiría que una prueba fraudulenta pasara la validación.

Con la versión 6.8.1, ahora existe una comprobación de longitud durante la deserialización. Se rechaza cualquier tensor cuyo número de elementos almacenados no sea igual al producto de sus dimensiones declaradas.

Después de publicar la versión 6.8.1, Succinct implementó la corrección en la Red Prover de mainnet.

Las personas que solicitan pruebas a la red no necesitan realizar cambios en su lado. Cualquier persona que ejecute su propio verificador nativo en Rust y acepte pruebas de provers no confiables debe actualizar a la versión 6.8.1.

El fallo fue descubierto por Vitalis Salis y reportado a través del programa de recompensas por errores de bug bounty de Immunefi, según indica el aviso.

Este año, Cryptopolitan ha informado sobre otros errores de solidez en sistemas de prueba, incluido un fallo de solidez en el pool protegido Orchard de Zcash. Cryptopolitan también analizó una explotación en Foom.Cash donde un atacante falsificó pruebas zkSNARK debido a una configuración incorrecta del verificador.

No te limites a leer noticias sobre criptomonedas. Entiéndelas. Suscríbete a nuestro boletín. Es gratis.