Voir la table des matières Ne plus voir la table des matières
Un réseau de blockchains conçu pour que les jetons circulent librement d’une chaîne à l’autre suppose un protocole commun, et ce protocole devient alors le point de passage obligé de tout l’ensemble. Dans l’écosystème Cosmos, ce rôle revient à IBC, l’Inter-Blockchain Communication protocol, qui relie 42 chaînes et permet de passer d’une blockchain à une autre sans intermédiaire. Cette plomberie partagée fait la force du réseau, elle en concentre aussi le risque.
Le 13 octobre 2022, le cofondateur de Cosmos Ethan Buchman a publié sur le forum de gouvernance du Cosmos Hub un avis de sécurité baptisé Dragonberry. Son objet : une vulnérabilité critique présente dans toutes les versions d’IBC, donc sur toutes les chaînes qui l’ont activé, soit une capitalisation cumulée de 8,18 milliards de dollars selon le site du projet. Comment une seule faille peut-elle exposer un écosystème entier, et pourquoi ses développeurs ont-ils choisi de la corriger en silence avant d’en parler ?
Le vol sur BNB Chain a déclenché l’audit
L’alerte ne naît pas d’une attaque contre Cosmos, mais d’une attaque contre un voisin. Une semaine plus tôt, un attaquant a exploité le pont de BNB Chain et drainé 566 millions de dollars, contraignant les validateurs à suspendre la chaîne le temps de contenir l’hémorragie. L’épisode a marqué le secteur autant par son montant que par la nature du défaut, logé dans la vérification des preuves qui accompagnent les transferts entre chaînes.
Les équipes de Cosmos et d’Osmosis ont repris leur propre code IBC ligne à ligne pour savoir si le même vecteur s’y appliquait. La réponse est venue vite, et elle était mauvaise. Ce réflexe d’audit croisé après le sinistre d’un tiers a très probablement évité un second incident de même ampleur, quatre mois après qu’un autre pont inter-chaînes eut cédé pour 100 millions de dollars.
Le rapprochement entre les deux affaires n’a rien d’anecdotique. Les ponts et les protocoles d’interopérabilité reposent sur un même mécanisme, la vérification cryptographique d’un état venu d’ailleurs, et une erreur dans cette vérification vaut une fausse monnaie. La réaction du secteur à l’arrêt brutal de la chaîne de Binance avait déjà montré combien ce maillon restait fragile.
Un avis de sécurité qui en dit le moins possible
Le message publié le 13 octobre à 14 h 27 UTC tient en quelques paragraphes et ne décrit à aucun moment le fonctionnement de la faille. C’est délibéré : publier le détail technique avant que les chaînes ne soient protégées revient à fournir un mode d’emploi aux attaquants. Le texte se contente d’annoncer la gravité, l’étendue et la marche à suivre.
Les développeurs qui ne se seraient pas encore manifestés étaient invités à écrire directement à l’équipe sécurité de l’Interchain, sans passer par un canal public. Cette discipline de divulgation, formalisée dans la politique du projet, place la protection des utilisateurs avant la transparence immédiate, un arbitrage que tous les écosystèmes ne tranchent pas dans le même sens.
Nous avons découvert une vulnérabilité de sécurité critique qui affecte toutes les chaînes Cosmos compatibles IBC, pour toutes les versions d’IBC.
Ethan Buchman, cofondateur de Cosmos, dans l’avis de sécurité Dragonberry publié le 13 octobre 2022 sur le forum de gouvernance du Cosmos Hub
Ce que le correctif a exigé de chaque chaîne
La mise à l’abri ne se résume pas à télécharger une nouvelle version. Les équipes d’Informal Systems, d’Interchain GmbH et d’Osmosis ont coordonné l’opération avec la majorité des chaînes de l’interchaîne, et la procédure comportait plusieurs étapes distinctes, dont aucune ne pouvait être sautée.
- Le correctif a d’abord circulé en privé auprès des équipes de développement et des validateurs, avant toute communication publique ;
- La version publique est sortie le 14 octobre 2022 à 14 heures UTC dans le Cosmos SDK v0.45.9, avec une variante pour les chaînes restées sur la branche v0.44 ;
- Chaque chaîne devait ajouter une directive de remplacement dans son fichier de dépendances, pour pointer vers la bibliothèque de preuves corrigée ;
- Les projets maintenant leur propre version modifiée du SDK devaient reporter l’intégralité du correctif dans leur code.
Particularité appréciable, le correctif pouvait être déployé validateur par validateur, sans arrêt coordonné de la chaîne. Buchman a néanmoins prévenu que des interruptions restaient possibles pendant la mise à jour, et a demandé aux équipes concernées de signaler tout blocage sans attendre. La consigne valait aussi pour les chaînes déjà corrigées en privé, invitées à repasser sur la version publique.
Un tiers du pouvoir de vote, et pas un de moins
La sécurité d’une chaîne à preuve d’enjeu ne se mesure pas au nombre de serveurs mis à jour, mais au poids qu’ils représentent. Une chaîne devenait hors d’atteinte de la vulnérabilité dès qu’un tiers de son pouvoir de vote avait appliqué le correctif, ce seuil correspondant à la part nécessaire pour empêcher la validation d’un bloc frauduleux.
Le projet a malgré tout recommandé de pousser jusqu’aux deux tiers aussi vite que possible, une fois le correctif officiel disponible. L’écart entre les deux seuils dit assez bien la réalité opérationnelle d’un réseau décentralisé : on protège d’abord, on consolide ensuite, et la coordination prend plus de temps que le code. Reste que toutes les chaînes n’étaient pas exposées de la même façon.
Les chaînes qui avaient débranché IBC
Le périmètre de l’alerte couvrait Cosmos Hub, Osmosis, Cronos et Evmos, parmi les 42 chaînes recensées comme compatibles IBC. D’autres réseaux de premier plan, comme OKX Chain, Luna Classic ou Thorchain, avaient intégré le protocole par le passé sans jamais l’activer complètement, ou l’avaient désactivé depuis : ils échappaient mécaniquement à la faille.
BNB Chain figurait précisément dans cette catégorie, ce qui rend l’enchaînement des événements assez ironique. La chaîne victime du vol qui a déclenché l’audit n’utilisait pas la brique dont l’audit a révélé le défaut. Le vecteur d’attaque, lui, voyageait d’une implémentation à l’autre parce que les deux partageaient une même famille de preuves cryptographiques.
Cette géographie du risque intéresse quiconque détient des jetons sur ces réseaux, souvent sans savoir quelle plomberie les fait circuler. Le fonctionnement d’IBC est documenté depuis longtemps par le projet, et les guides consacrés à l’architecture générale de Cosmos ou à la place d’Osmosis dans cet ensemble aident à situer ce qui dépend de quoi. Savoir sur quelle chaîne dorment ses actifs fait partie de la gestion du risque, au même titre que le choix du portefeuille.
Ce que l’interchaîne apprend de ses propres alertes
Dragonberry laisse derrière lui une question qui dépasse Cosmos. Un protocole partagé par des dizaines de chaînes offre à chacune la liquidité et les usages des autres, et il leur transmet aussi, sans discussion, chacun de ses défauts. La promesse d’interopérabilité se paie d’une surface d’attaque commune, et le secteur n’a pas encore trouvé de façon élégante de découpler les deux.
Les équipes de Cosmos ont annoncé la poursuite des audits internes et l’organisation d’examens par des tiers, en plus du programme de primes aux bugs ouvert sur HackerOne. Ces dispositifs ne suppriment pas le risque, ils réduisent le délai entre la découverte d’un défaut et sa correction. Sur un réseau où la valeur circule plus vite que l’information, ce délai est devenu le vrai indicateur de solidité, bien avant le nombre de chaînes connectées.
