La Fondation Solana a confirmé la correction d'une vulnérabilité de type zero-day. Cette faille aurait permis à un attaquant de créer certains tokens de manière illimitée, voire de les retirer directement depuis des comptes utilisateurs.
Dans un rapport post-mortem publié le 3 mai, la Fondation Solana explique que cette vulnérabilité, découverte le 16 avril, aurait pu permettre à un attaquant de produire une preuve invalide et ainsi de contourner les mécanismes de vérification liés aux “Token-22”, des tokens confidentiels utilisés pour des transferts privés.
Selon la fondation, aucun piratage connu n’a exploité cette faille. Les validateurs ont désormais adopté la version corrigée du programme.
Les tokens confidentiels Token-22 concernés
La faille de sécurité concernait deux composants du réseau : les programmes Token-2022 et ZK ElGamal Proof. Le premier gère la logique principale des jetons et des comptes, tandis que le second vérifie l’exactitude des preuves à divulgation nulle de connaissance (zero-knowledge proofs) pour afficher des soldes de comptes corrects.
D’après les explications techniques, le problème venait d’une omission de certains éléments algébriques dans le processus de génération de la transformation Fiat-Shamir.
Cette faille aurait pu permettre à un attaquant d'exploiter les composants non hachés en créant une preuve falsifiée qui passe la vérification pour frapper et voler des tokens confidentiels Token-22.
Les “Token-22”, aussi appelés “tokens avec extension”, utilisent les zero-knowledge proofs pour effectuer des transferts privés et proposer des fonctions avancées.
La faille a été détectée le 16 avril. Deux correctifs ont été déployés rapidement. Une large majorité des validateurs Solana a adopté ces mises à jour dans les deux jours.
Les sociétés de développement Anza, Firedancer et Jito ont dirigé la mise en place du correctif. Des entités comme Asymmetric Research, Neodyme et OtterSec ont aussi contribué. La fondation a précisé qu’aucun fonds n’a été compromis.
La fondation a confirmé que tous les fonds sont en sécurité.
Malgré la correction rapide, la manière dont la Fondation Solana a géré cette vulnérabilité en coordination avec les validateurs du réseau a suscité des inquiétudes dans la communauté crypto.
Un contributeur de Curve Finance a notamment exprimé ses doutes quant à la relation étroite entre la fondation et les validateurs.
« Pourquoi une entité détient-elle une liste de tous les validateurs avec leurs coordonnées ? De quoi parlent-ils exactement sur ces canaux privés ? » Il craint qu’une telle proximité puisse mener à une censure ou à des manipulations de la blockchain.
Le PDG de Solana Labs, Anatoly Yakovenko, n’a pas nié ces remarques, mais a rappelé que la communauté Ethereum pourrait elle aussi se coordonner de manière similaire en cas de faille critique.
Yakovenko a argumenté que plus de 70 % des validateurs du réseau Ethereum sont contrôlés par des exchanges ou des opérateurs de staking tels que Lido, Binance, Coinbase ou Kraken.
« Ce sont les mêmes entités qui représentent 70 % sur Ethereum : tous les validateurs de Lido (Chorus One, P2P, etc.), Binance, Coinbase et Kraken. Si geth devait publier un patch, je serais heureux de les aider à le déployer. »
En août dernier, la Fondation Solana et les validateurs avaient déjà résolu une autre faille critique en interne. À l’époque, Dan Albert, directeur exécutif de la Fondation, avait déclaré que cette capacité à se coordonner ne signifiait pas que Solana était centralisé.
Ethereum ne serait pas vulnérable de la même manière, selon un membre de la communauté
Ryan Berckmans, membre actif de la communauté Ethereum, rejette l’idée que le réseau Ethereum présente les mêmes risques de centralisation que Solana. Il souligne la diversité des clients sur Ethereum.
Selon lui, le client Geth ne représente que 41 % des nœuds Ethereum, alors que Solana ne dispose actuellement que d’un seul client en production, Agave.
« Cela signifie que les bugs zero-day dans ce client unique sont, de fait, des bugs du protocole lui-même. Modifier le client, c’est modifier le protocole. Le client fait le protocole »
Meanwhile, Solana is looking to roll out a new client, Firedancer, in the next few months, which is expected to improve the network’s resilience and uptime.
Solana prévoit néanmoins de lancer prochainement un second client, Firedancer, censé améliorer la résilience et la disponibilité du réseau. Cependant, pour Berckmans, il en faudra au moins trois pour atteindre un niveau de décentralisation satisfaisant au niveau des clients.
