Solana corrige tranquillement un bug qui aurait pu laisser les attaquants menthes et voler certains jetons
La Fondation Solana a divulgué une vulnérabilité auparavant inconnue dans son système de jetons axé sur la confidentialité qui aurait pu permettre aux attaquants de forger de fausses preuves de connaissances zéro, permettant à la vulnérabilité non autorisée ou à des retraits de jetons.
La Vulnerabilité a été signalée pour la première fois le 16 avril par le biais d’Anza’s Github Security Advisory, accompagné par un événement professionnel de la preuve du travail travail. Les ingénieurs des équipes de développement de Solana ANZA, Firedancer et Jito ont vérifié le bogue et ont commencé à travailler immédiatement sur un correctif, selon un post-mortem publié samedi,
Le problème provenant du programme ZK Elgamal, qui vérifie les transferts confidentiels de Zero-Knowled (ZKPS) de Solana. Ces jetons d’extension permettent des soldes et des transferts privés en cryptant les quantités et en utilisant des preuves cryptographiques pour les valider.
ZKPS est une méthode cryptographique qui permet à quelqu’un de prouver qu’ils savent ou ont accès à quelque chose, comme un mot de passe ou un âge, sans révéler la chose elle-même.
Dans les applications cryptographiques, celles-ci peuvent être utilisées pour prouver qu’une transaction est valide sans afficher des quantités ou des adresses spécifiques (qui peuvent autrement être utilisées par des acteurs malveillants pour planifier des exploits).
Le bogue s’est produit parce que certaines composants algébriques manquaient dans le processus de hachage pendant la transformation Fiat-Shamir – une méthode standard pour faire des germes zéro-connaissances. (Non-interactif signifie transformer un processus de va-et-vient en une preuve unique que quiconque peut vérifier.)
Un attaquant sophistiqué pourrait forger des preuves invalides que le vérificateur en chaîne accepterait toujours.
La logique du programme Token-2022 principale
a été distribuée en privé aux opérateurs de validateurs à partir du 17 avril. Un deuxième correctif a été poussé plus tard ce soir-là pour résoudre un problème connexe ailleurs dans la base de codes.
Les deux ont été examinés par des sociétés de sécurité tiers asymétriques Research, Neodyme, et Ottersec. Le 18 avril, une supermajorité de validateurs avait adopté le correctif.
Rien n’indique que le bogue a été exploité, et tous les fonds restent en sécurité, selon le post-mortem.
