- Un bug de validité de haute criticité dans SP1 a laissé le réseau Prover principal de Succinct ouvert aux preuves invalides.
- La faille résidait dans le vérificateur Rust natif de SP1, dans les versions 6.0.0 à 6.8.0.
- Succinct a déployé la correction de la version 6.8.1 sur son réseau Prover principal.
Un bug de validité de haute criticité dans le système de preuve à connaissance nulle de Succinct, SP1, a exposé le réseau Prover principal de l’entreprise aux preuves invalides.
Selon un avis de sécurité GitHub publié le 11 octobre, ce réseau était le seul déploiement connu de Succinct affecté.
Les vérificateurs Rust natifs des versions 6.0.0 à 6.8.0 pouvaient accepter des preuves invalides
L'avis, enregistré sous GHSA-p7v2-jjv3-8p8f, indique qu'un prouveur malveillant pourrait soumettre une preuve pour une exécution invalide et que le vérificateur du réseau l'accepterait. Le Prover Network a accepté des preuves provenant de prouveurs tiers.
Pour exploiter ce bug, les preuves devaient être envoyées directement au vérificateur Rust natif de SP1. Les preuves Core et Compressed étaient exposées sur ce chemin.
Les vérifications Groth16 et Plonk étaient sûres car elles utilisaient des preuves enveloppées avec des formes fixes et ne touchaient jamais au format de tenseur contrôlé par le prouveur à l'origine du bug.
Les vérificateurs Solidity pour les vérifications on-chain Plonk et Groth16 n'étaient également pas affectés. Les applications utilisant la fonction verify_sp1_proof pour vérifier les preuves Compressed n'étaient sécurisées que si l'agrégation de preuves se terminait par une preuve Groth16 ou Plonk.
L'avis indique que les versions 6.0.0 à 6.8.0 de sp1_hypercube, sp1_prover et sp1_sdk sont concernées. La correction a été publiée par Succinct dans la version 6.8.1 le 24 septembre, soit 17 jours avant la divulgation publique de l'avis.
Les tenseurs dont les longueurs de stockage ne correspondent pas sont rejetés par la version 6.8.1
Le vérificateur Rust natif de SP1 présentait ce bug. Il s'agit de la partie du programme qui vérifie la validité d'une preuve.
SP1 stocke les données multidimensionnelles dans un Tensor. Un Tensor se compose d'un tampon de valeurs stockées et de dimensions déclarées décrivant sa forme.
Les deux doivent correspondre pour une vérification fiable. Le nombre d'éléments stockés doit être égal au produit des dimensions indiquées.
Une étiquette sur chaque élément de preuve indique sa taille. Le vérificateur ne s'est jamais assuré que ce qui était indiqué sur l'étiquette correspondait au contenu. Il ne regardait que l'étiquette.
Un attaquant pouvait donc envoyer des données avec une fausse étiquette. Différentes parties du contrôle examinaient alors différentes parties des mêmes données, ce qui permettait à une fausse preuve de passer.
Avec la version 6.8.1, un contrôle de longueur est désormais effectué lors de la désérialisation. Tout Tensor dont le nombre d'éléments stockés n'est pas égal au produit de ses dimensions déclarées est rejeté.
Après la publication de la version 6.8.1, Succinct a déployé la correction sur le réseau Prover en mainnet.
Les utilisateurs qui demandent des preuves depuis le réseau n'ont rien à modifier de leur côté. Toute personne exécutant son propre vérificateur natif Rust et acceptant des preuves provenant de prouveurs non fiables doit mettre à jour vers la version 6.8.1.
Selon l'avis, Vitalis Salis a découvert la faille et l'a signalée via le programme de prime pour bogues d'Immunefi.
D’autres bugs de validité dans des systèmes de preuve, y compris un bug de validité dans le pool confidentiel Orchard de Zcash, ont été signalés cette année par Cryptopolitan. Cryptopolitan a également évoqué une exploitation sur Foom.Cash où un attaquant a falsifié des preuves zkSNARK en raison d’une mauvaise configuration du vérificateur.
Les esprits les plus brillants du secteur crypto lisent déjà notre newsletter. Vous aussi ? Rejoignez-les.
FAQ
Quelle était la vulnérabilité SP1 ?
Un bug de correction dans le vérificateur Rust natif de SP1 qui permettait à un prouveur malveillant d'obtenir une preuve pour une exécution invalide acceptée.
Quelles versions de SP1 sont concernées et laquelle corrige le problème ?
Les versions 6.0.0 à 6.8.0 sont concernées, et la version 6.8.1 corrige le problème.
Les utilisateurs de SP1 doivent-ils prendre des mesures ?
Les demandeurs sur le réseau Prover principal de Succinct n'ont besoin d'aucun changement. Les équipes exécutant un vérificateur Rust natif séparé qui accepte les preuves de prouveurs non fiables doivent passer à la version 6.8.1.
Avertissement. Les informations fournies ne constituent pas des conseils en matière de trading. Cryptopolitan.com décline toute responsabilité concernant les investissements réalisés sur la base des informations fournies sur cette page. Nous recommandons vivement une recherche indépendante et/ou une consultation avec un professionnel qualifié avant de prendre toute décision d'investissement.
Randa Moses
Randa Moses est rédactrice et journaliste chez Cryptopolitan, couvrant la technologie, l'IA, la robotique, la crypto, les arnaques et les piratages. Elle évolue dans l'espace crypto depuis 2017. Elle a occupé des postes chez Forward Protocol, AmaZix et Cryptosomniac. Randa détient un diplôme en génie électrique et électronique de l'Université de Bradford.
