Guide de sécurité de l'écosystème Cosmos : Analyse des différents scénarios de sécurité dans l'écosystème Cosmos
TechFlow SélectionTechFlow Sélection
Guide de sécurité de l'écosystème Cosmos : Analyse des différents scénarios de sécurité dans l'écosystème Cosmos
Cet article inclut non seulement une analyse des principales failles de sécurité passées dans l'écosystème Cosmos, mais classe également les vulnérabilités courantes selon leur cause, leur effet, leur emplacement dans le code, etc.
Dédié à des analyses Web3 approfondiesRédaction : CertiK
En tant qu'un des écosystèmes blockchain les plus grands et les plus renommés au monde, Cosmos se concentre sur l'amélioration de l'interopérabilité entre blockchains afin de permettre une communication efficace entre différentes blockchains. Une série de projets majeurs, notamment Celestia et dYdX v4, sont construits sur le SDK Cosmos et le protocole IBC.
À mesure que les composants de développement de Cosmos gagnent en popularité auprès des développeurs, la sécurité de l'écosystème Cosmos aura inévitablement un impact plus large. Par exemple, précédemment, la vulnérabilité Dragonfruit du SDK Cosmos a affecté le fonctionnement normal de plusieurs blockchains publiques majeures. En raison de la nature décentralisée des composants fondamentaux de l'écosystème Cosmos, les développeurs doivent utiliser ou étendre différents composants selon leurs besoins fonctionnels spécifiques, ce qui entraîne une dispersion et une diversité des problèmes de sécurité dans l'écosystème Cosmos. Un rapport aidant les développeurs à comprendre structurellement l'état actuel de la sécurité de l'écosystème Cosmos et ses solutions devient donc particulièrement nécessaire.
Le « Guide de Sécurité de l’Écosystème Cosmos », publié exclusivement par l’équipe CertiK, analyse minutieusement les scénarios de sécurité des différents composants de l’écosystème Cosmos avec une classification claire et accessible aux lecteurs. Ce rapport inclut non seulement l'analyse des principales failles de sécurité passées dans l'écosystème Cosmos, mais classe également les vulnérabilités courantes selon leur cause, effet et emplacement dans le code, fournissant ainsi un maximum d'orientation en matière de sécurité aux développeurs de l'écosystème Cosmos, ainsi qu’un référentiel utile pour les auditeurs de sécurité lors de l’apprentissage et de l’audit des problèmes liés à la sécurité de Cosmos.
Depuis toujours, l'équipe CertiK s'efforce continuellement, par la recherche et l'exploration approfondies, d'améliorer la sécurité de l'écosystème Cosmos et de tout l'écosystème Web3. Nous publierons régulièrement divers rapports de sécurité de projets et recherches techniques ; n'hésitez pas à suivre nos actualités ! Si vous avez des questions, veuillez nous contacter à tout moment.
Voici ci-dessous le texte intégral du « Guide de Sécurité de l’Écosystème Cosmos » 👇.
Aperçu général
Cosmos est un réseau blockchain transversal open source, ouvert et hautement évolutif, et constitue l'un des écosystèmes blockchain les plus connus au monde. Cosmos est un réseau hétérogène prenant en charge la communication inter-chaînes, lancé par CometBFT (anciennement Tendermint), composé d’un réseau décentralisé de multiples blockchains indépendantes et parallèles. Son objectif est de briser l’isolement informationnel et d’assurer l’interopérabilité entre différentes blockchains. À l’ère actuelle de la multi-chaîne, la mise en œuvre de l’interaction inter-chaînes est devenue une exigence urgente de l’industrie blockchain.
Cosmos propose un modèle inter-chaînes efficace, particulièrement adapté aux blockchains publiques spécialisées dans des domaines verticaux précis. En fournissant une infrastructure blockchain modulaire, Cosmos facilite grandement les développeurs d'applications, leur permettant de choisir et d'utiliser la blockchain publique correspondant à leurs besoins.
Les applications et protocoles au sein de l’écosystème Cosmos utilisent le protocole IBC (Inter-Blockchain Communication) pour assurer la communication inter-chaînes, permettant ainsi aux actifs et aux données de circuler librement entre différentes blockchains indépendantes. La vision de Cosmos est de créer un « internet des blockchains », offrant des possibilités d'extension et d'interaction à un grand nombre de blockchains autonomes et faciles à développer.
CertiK suit et étudie attentivement depuis longtemps l’environnement de l’écosystème Cosmos. Nous avons accumulé une solide expérience sur les questions de sécurité de cet écosystème. Dans ce rapport de recherche, nous présenterons notre exploration et nos découvertes concernant la sécurité de l’écosystème Cosmos, en mettant principalement l’accent sur quatre axes : la sécurité du SDK Cosmos, celle du protocole IBC, celle de CometBFT et celle de CosmWasm. Notre champ d’étude s’étendra des composants fondamentaux de Cosmos aux chaînes de base ou aux chaînes applicatives de Cosmos. Grâce à une analyse descendante et à une extension progressive, nous exposerons progressivement aux lecteurs les points essentiels de sécurité relatifs aux chaînes elles-mêmes dans l’écosystème Cosmos.
En raison de la complexité et de la diversité de l’écosystème Cosmos, les problèmes de sécurité existants présentent eux aussi un caractère varié. Par conséquent, ce rapport de recherche ne couvre pas toutes les catégories possibles de vulnérabilités, mais se concentre uniquement sur celles qui sont typiques et potentiellement les plus dommageables pour les chaînes de l’écosystème Cosmos. Pour toute question supplémentaire sur d'autres problèmes de sécurité, veuillez contacter un ingénieur de sécurité CertiK.
Contexte
-
CometBFT : la pierre angulaire de l’extensibilité inter-chaînes
CometBFT est un algorithme de consensus innovant comprenant deux composants principaux : le moteur de consensus sous-jacent (CometBFT Core) et l’interface générique d’application de blocs (ABCI). Son algorithme de consensus repose sur une combinaison PBFT + PoS garantie (Bonded PoS), assurant que les nœuds enregistrent simultanément les transactions. En tant que composant central de l’extensibilité inter-chaînes, CometBFT maintient, via le consensus des validateurs, la sécurité, la décentralisation et l’intégrité de l’écosystème Interchain.
-
SDK Cosmos : modularité et nouvelles fonctionnalités
Le SDK Cosmos est un ensemble d'outils conçu pour accélérer le processus de développement des développeurs. Il offre des caractéristiques modulaires et interchangeables. En utilisant le SDK Cosmos, les développeurs peuvent construire leurs propres blockchains ou composants fonctionnels basés sur l'algorithme de consensus CometBFT, facilitant ainsi un développement rapide et réduisant le cycle de développement. Il est déjà adopté par de nombreux projets blockchain tels que Cronos, Kava et le récent dYdX V4. Les plans futurs porteront sur l’amélioration de la modularité et l'introduction de nouvelles fonctionnalités, permettant aux développeurs de créer des applications plus complexes et modulaires, et favorisant ainsi un écosystème plus vaste et puissant.
-
Protocole IBC : renforcement de l’interopérabilité et de l’extensibilité
Le protocole IBC (Inter-Blockchain Communication) permet un transfert sécurisé, décentralisé et sans autorisation de données entre blockchains. Étant donné que Cosmos est un réseau décentralisé constitué de multiples blockchains indépendantes et parallèles, utilisant une technologie de relais pour assurer la communication inter-chaînes, IBC peut être considéré comme l'élément le plus central du projet. La Fondation Interchain se concentre actuellement sur deux thèmes : l’extensibilité et la disponibilité. En améliorant l’extensibilité et l’interopérabilité d’IBC, Cosmos renforcera davantage la capacité de son écosystème, rendant possible une interaction transparente entre blockchains, applications et contrats intelligents.
-
CosmWasm : libération du déploiement décentralisé et sans permission
CosmWasm (Cosmos WebAssembly) est un cadre de contrat intelligent basé sur WebAssembly, spécialement conçu pour l’écosystème Cosmos. Il permet aux développeurs de déployer des applications décentralisées sans avoir besoin d’autorisation, et permet également aux développeurs de chaînes de découpler leur cycle de développement produit du cycle de développement de la blockchain, réduisant ainsi le coût des mises à jour des validateurs. De plus, il dispose d'une architecture modulaire, d'une intégration avec le SDK Cosmos, de capacités de communication inter-chaînes, etc.
À ce jour, le SDK Cosmos et le protocole IBC sont relativement matures et largement utilisés dans l’écosystème Cosmos actuel.
Du point de vue des développeurs de chaînes, la plupart des fonctionnalités personnalisées nécessaires aux chaînes dans l’écosystème Cosmos peuvent être réalisées via le SDK Cosmos. Cependant, pour effectuer certaines opérations spéciales pendant les opérations inter-chaînes ou pour des raisons d’optimisation des performances, les développeurs de chaînes personnalisent souvent leurs propres modules IBC. Quelques chaînes modifient même occasionnellement des moteurs de base tels que CometBFT Core. En raison de contraintes de place, ces cas ne seront pas abordés ici. Ce rapport se concentrera principalement sur l’analyse technique et les problèmes de sécurité liés au SDK Cosmos et au protocole IBC.
Guide de sécurité du SDK Cosmos
Le SDK Cosmos est un cadre puissant et flexible destiné à la construction d’applications blockchain et de protocoles décentralisés. Développé par la Fondation Interchain, il constitue un composant central du réseau Cosmos, un réseau décentralisé de blockchains interconnectées.
Le SDK Cosmos vise à simplifier le développement d'applications blockchain personnalisées et à permettre une interopérabilité transparente entre différentes blockchains. Ses principales caractéristiques sont : architecture modulaire, personnalisation, fondée sur CometBFT, implémentation des interfaces correspondantes à IBC, convivialité pour les développeurs. Le SDK Cosmos exploite le moteur de consensus sous-jacent CometBFT Core pour assurer une sécurité robuste, protégeant ainsi le réseau contre les attaques malveillantes et garantissant la protection des actifs et des données des utilisateurs. De plus, sa modularité permet aux utilisateurs de concevoir facilement des modules personnalisés. Malgré ces avantages, des vulnérabilités de sécurité peuvent encore apparaître lorsque les développeurs utilisent le SDK Cosmos pour implémenter leurs propres applications.
D’un point de vue d’audit de sécurité, nous devons examiner minutieusement tous les aspects de la cible, en tenant compte de tous les risques potentiels. Toutefois, du point de vue de la recherche en sécurité, nous devons plutôt nous concentrer sur les vulnérabilités pouvant causer des impacts majeurs, afin d’éviter au maximum les risques les plus élevés dans un délai court, apportant ainsi une aide plus efficace aux parties prenant en charge le service. Dans cette optique, classer les vulnérabilités dangereuses et à large portée d’impact et analyser leurs modèles est une démarche nécessaire et précieuse.
Dans l’interface ABCI, omniprésente dans tout l’écosystème Cosmos, nous accordons une attention particulière aux quatre interfaces suivantes : BeginBlock, EndBlock, CheckTx et DeliverTx. Les deux premières sont directement liées à la logique d’exécution d’un bloc unique, tandis que les deux dernières concernent le traitement spécifique des sdk.Msg (la structure de données fondamentale des messages transmis dans l’écosystème Cosmos).
Étant donné que la logique d’implémentation des diverses chaînes applicatives dans l’écosystème Cosmos peut suivre des modèles similaires à ceux des modules et exemples du SDK Cosmos, une compréhension de base du flux d’exécution des modules du SDK Cosmos est nécessaire pour analyser les vulnérabilités de sécurité décrites ci-après.
Dans l’écosystème Cosmos, une transaction est initialement créée dans un agent utilisateur, puis signée et diffusée aux nœuds du réseau blockchain. Les nœuds utilisent la méthode CheckTx pour valider divers détails de la transaction, tels que la signature, le solde de l’expéditeur, la séquence de transaction et le gaz fourni. Si la transaction passe la validation, elle est ajoutée au mempool, en attente d'être incluse dans un bloc. Sinon, un message d’erreur est envoyé à l’utilisateur et la transaction est rejetée. Pendant l’exécution du bloc, une vérification supplémentaire est effectuée via la méthode DeliverTx, garantissant cohérence et déterminisme.
Dans le SDK Cosmos, le cycle de vie d’une transaction peut être brièvement décrit comme suit :
1. Création de la transaction : la transaction est créée côté client à l’aide de divers outils, CLI ou interfaces frontales.
2. Ajout au mempool : la transaction est ajoutée au mempool. Les nœuds envoient alors un message ABCI - CheckTx à la couche applicative pour vérifier sa validité et recevoir le résultat abci.ResponseCheckTx. Dans CheckTx, la transaction est décodée du format octet vers le format Tx, puis ValidateBasic() est appelée pour chaque sdk.Msg de la transaction afin d’effectuer une vérification préliminaire sans état. Si l’application possède un anteHandler correspondant, sa logique interne est d’abord exécutée, puis la fonction runTx est appelée, aboutissant finalement à RunMsgs() pour traiter le contenu spécifique de sdk.Msg. Si CheckTx réussit, le message est ajouté au mempool local comme candidat pour le prochain bloc, et diffusé via P2P aux nœuds pairs.
3. Inclusion dans un bloc proposé : au début de chaque tour, le proposant crée un bloc contenant les transactions les plus récentes. Ce bloc est ensuite soumis à la validation par les validateurs, qui décident soit d’accepter le bloc, soit de voter pour un bloc vide.
4. Changement d’état : DeliverTx est invoqué pour itérer sur les transactions du bloc. Similaire à CheckTx, mais exécuté en mode « Deliver », appelant runTx et appliquant les modifications d’état. Le routeur MsgServiceRouter est utilisé pour diriger les différents messages de la transaction vers les modules appropriés, puis exécuter chaque message correspondant dans le serveur de messages. Après l’exécution, des vérifications sont effectuées. En cas d’échec, l’état est restauré. Un compteur de gaz est utilisé pour suivre la consommation de gaz. En cas d’erreur de gaz (ex. : gaz insuffisant), les conséquences sont identiques à un échec d’exécution : les changements d’état sont annulés.
5. Validation du bloc : lorsque les nœuds reçoivent suffisamment de votes des validateurs, ils valident un nouveau bloc à ajouter à la blockchain, finalisant ainsi la transition d’état au niveau applicatif.
Cycle de vie d'une transaction dans l'écosystème Cosmos
Voici la logique d'exécution concrète du SDK Cosmos, utile pour comprendre les chemins de déclenchement des vulnérabilités décrits plus loin :
Logique d'exécution des interfaces ABCI clés du SDK Cosmos
Classification des vulnérabilités courantes
Avant d’aborder la classification des vulnérabilités, nous devons définir une échelle de gravité de base afin d’identifier plus efficacement les failles de sécurité critiques et ainsi minimiser les risques potentiels.
En tenant compte de la gravité et de la portée d’impact, nous nous concentrons principalement sur les vulnérabilités classées Critique (Critical) et Majeure (Major), qui peuvent généralement entraîner les risques suivants :
1. Arrêt complet de la chaîne
2. Perte de fonds
3. Impact sur l’état système ou le fonctionnement normal
Ces dangers proviennent souvent des types de vulnérabilités suivants :
1. Déni de service
2. Configuration incorrecte de l’état
3. Absence ou invalidité de la validation
4. Problèmes d’unicité
5. Problèmes liés à l’algorithme de consensus
6. Failles logiques dans l’implémentation
7. Problèmes liés aux particularités du langage
Analyse des vulnérabilités
En raison de la modularité particulière de l’écosystème Cosmos, les chaînes applicatives implémentent fréquemment des cas d'utilisation croisée entre modules et des appels internes aux modules. Il arrive donc que le chemin de déclenchement d'une vulnérabilité ne coïncide pas avec le chemin contrôlable de la variable critique impliquée. Lors de l'analyse des causes exactes de vulnérabilités, nous ne devrions pas seulement nous concentrer sur le chemin de déclenchement, mais aussi sur le chemin contrôlable de la variable critique, ce qui nous aidera à mieux définir et classifier les modèles de vulnérabilités.
Arrêt de la chaîne
La cause principale de l’arrêt d’une chaîne est souvent un problème survenu lors de l’exécution d’un bloc individuel. Toutefois, au cours de l’évolution historique de Cosmos, il y a eu des cas où des vulnérabilités de consensus ont forcé l’arrêt volontaire de la chaîne pour procéder à une correction. Ainsi, nous incluons ici les vulnérabilités affectant le consensus dans la catégorie des effets entraînant l’arrêt de la chaîne. Nous allons examiner ces deux types de problèmes séparément.
Le premier type concerne principalement les vulnérabilités de type déni de service, dont les causes principales sont un traitement inapproprié des plantages et des boucles d’itération dont les limites peuvent être influencées par l’utilisateur. Ces vulnérabilités conduisent généralement à l’arrêt ou au ralentissement de la chaîne.
Comme mentionné précédemment, le SDK Cosmos et CometBFT, en tant qu’infrastructures clés de l’écosystème Cosmos, sont utilisés non seulement par les chaînes de base de Cosmos, mais aussi par diverses chaînes applicatives qui mettent en œuvre leur propre logique sur cette architecture. Elles respectent donc toutes les règles de l’interface ABCI de CometBFT, et leur surface d’attaque se concentre donc principalement sur cette interface ABCI. Les vulnérabilités pouvant entraîner un arrêt de la chaîne touchent majoritairement l’exécution du code des blocs, et leurs chemins d’occurrence remontent généralement aux interfaces BeginBlock et EndBlock.
Le deuxième type concerne les vulnérabilités affectant le consensus, généralement liées à l’implémentation de diverses chaînes. On les retrouve fréquemment dans des validations logiques, des problèmes de synchronisation temporelle ou de génération aléatoire. Ces vulnérabilités touchent fondamentalement le principe de décentralisation de la blockchain. Bien que leurs effets immédiats soient peu visibles, si elles sont exploités intentionnellement, elles peuvent poser des risques de sécurité importants.
Premier type de cas
-
Exemple 1 : Projet SuperNova
Contexte de la vulnérabilité : absence de validation d’adresse lors de l’opération de distribution de jetons, entraînant une panne d’opération et une perte de fonds. Dans le module de frappe de jetons, chaque création de token dépend du montant misé. Cependant, si le pool n’existe pas ou si l’adresse du contrat est erronée, le module de frappe peut connaître un dysfonctionnement imprévu, entraînant l’arrêt de la blockchain. Dans le module de pool de récompenses, l’adresse du contrat du pool n’est pas validée. Si l’opération de distribution échoue, la chaîne s’arrête directement.
Emplacement de la vulnérabilité : https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/mint/keeper/keeper.go#L175
Extrait du code vulnérable :
Chemin de déclenchement de la vulnérabilité :
BeginBlocker (/x/mint/keeper/abci.go)
Keeper.DistributeMintedCoin
Keeper.distributeLPIncentivePools
PoolIncentiveKeeper.GetAllIncentivePool (/x/mint/keeper/keeper.go)
Correctif :
https://github.com/Carina-labs/nova/commit/538abc771dea68e33fd656031cbcf2b8fe006be0
Le correctif se trouve dans le module de traitement des messages de poolincentive (x/poolincentive/types/msgs.go), et non dans le module mint.
Une validation d’adresse a été ajoutée lors du traitement du message MsgCreateCandidatePool (création de pool), afin d’éliminer dès l’origine la possibilité d’adresses erronées.
-
Exemple 2 : Projet Cosmos Interchain Security
Adresse du projet : https://github.com/cosmos/interchain-security
Contexte de la vulnérabilité : un validateur peut ralentir la chaîne fournisseur en soumettant plusieurs messages AssignConsumerKey dans un même bloc. La fonction AssignConsumerKey, définie dans x/ccv/provider/keeper/key_assignment.go, permet aux validateurs d’attribuer différentes clés consumerKey aux chaînes de consommation approuvées. Pour cela, l’AddressList consumerAddrsToPrune voit son élément augmenter. Comme cette AddressList est parcourue dans EndBlocker, défini dans x/ccv/provider/keeper/relay.go, un attaquant peut l’exploiter pour ralentir la chaîne fournisseur. Pour mener cette attaque, un acteur malveillant peut créer des transactions contenant plusieurs messages AssignConsumerKey et les envoyer à la chaîne fournisseur. La taille de consumerAddrsToPrune sera alors égale au nombre de messages AssignConsumerKey envoyés. Ainsi, l’exécution d’EndBlocker prendra plus de temps et de ressources que prévu, ralentissant voire arrêtant la chaîne fournisseur.
Emplacement de la vulnérabilité : https://github.com/cosmos/interchain-security/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/provider/keeper/key_assignment.go#L378
Extrait du code vulnérable :
Chemin de déclenchement de la vulnérabilité :
msgServer.AssignConsumerKey
Keeper.AssignConsumerKey
AppModule.EndBlock
EndBlockCIS
HandleLeadingVSCMaturedPackets
HandleVSCMaturedPacket
PruneKeyAssignments
-
Exemple 3 : Projet Quicksilver – Module Airdrop
Contexte de la vulnérabilité : BeginBlocker et EndBlocker sont des méthodes facultatives que les développeurs de modules peuvent implémenter dans leurs modules. Elles sont respectivement déclenchées au début et à la fin de chaque bloc. L’utilisation de plantages (crash) pour gérer les erreurs dans les méthodes BeginBlock et EndBlock peut entraîner l’arrêt de la chaîne en cas d’erreur. EndBlocker, lors du nettoyage des airdrops incomplets, ne vérifie pas si le module dispose de suffisamment de jetons, ce qui peut provoquer un crash et donc l’arrêt de la chaîne.
Emplacement de la vulnérabilité : https://github.com/quicksilver-zone/quicksilver/blob/b4aefa899e024d60f4047e2f2f403d67701b030e/x/airdrop/keeper/abci.go#L15
Extrait du code vulnérable :
Chemin de déclenchement de la vulnérabilité :
AppModule.EndBlock
Keeper.EndBlocker
Keeper.EndZoneDrop
Correctif : https://github.com/quicksilver-zone/quicksilver/blob/20dc658480b1af1cb323b4ab4a8e5925ee79a0ed/x/airdrop/keeper/abci.go#L16
Suppression du code de gestion panic, remplacé par un enregistrement d’erreur dans les journaux.
-
Exemple 4 : Projet Cosmos Interchain Security
Adresse du projet : https://github.com/cosmos/interchain-security
Contexte de la vulnérabilité : un attaquant peut réaliser une attaque par déni de service en envoyant plusieurs jetons à l’adresse de récompense de la chaîne fournisseur.
Dans le flux d’exécution d’EndBlocker de la chaîne de consommation, la fonction SendRewardsToProvider, définie dans x/ccv/consumer/keeper/distribution.go, récupère le solde de tous les jetons dans l’adresse tstProviderAddr et les envoie à la chaîne fournisseur. Pour cela, elle doit parcourir tous les jetons trouvés dans l’adresse de récompense et les envoyer un par un via IBC à la chaîne fournisseur. Comme n’importe qui peut envoyer des jetons à cette adresse, un attaquant peut créer et envoyer un grand nombre de jetons de différents denom, par exemple en utilisant une chaîne disposant d’un module d’usine de jetons, pour lancer une attaque par déni de service. Ainsi, l’exécution d’EndBlocker prendra plus de temps et de ressources que prévu, ralentissant voire arrêtant la chaîne de consommation.
Emplacement de la vulnérabilité : https://github.com/cosmos/interchain-security/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/consumer/keeper/distribution.go#L103
Extrait du code vulnérable :
Chemin de déclenchement de la vulnérabilité :
AppModule.EndBlock
EndBlock
EndBlockRD
SendRewardsToProvider
Deuxième type de cas
Ces problèmes de consensus peuvent ne pas sembler causer des dommages directs graves, mais en examinant les principes fondamentaux de la blockchain ou des scénarios spécifiques, leur impact peut être aussi important que celui des autres vulnérabilités conventionnelles. De plus, ces vulnérabilités partagent des points communs.
-
Exemple 1
Contexte de la vulnérabilité : Avis de sécurité Cosmos SDK Jackfruit
Le comportement non déterministe de la méthode ValidateBasic dans le module x/authz du Cosmos SDK peut facilement entraîner un arrêt du consensus. La structure de message MsgGrant du module x/authz contient un champ Grant, qui inclut la date d’expiration définie par l’utilisateur. Dans le traitement ValidateBasic() de la structure Grant, la comparaison se fait entre cette date et l’heure locale du nœud, et non avec l’horodatage du bloc. Comme l’heure locale est non déterministe, les horodatages des différents nœuds peuvent varier, causant ainsi des problèmes de consensus.
Annonce de la vulnérabilité :
https://forum.cosmos.network/t/cosmos-sdk-security-advisory-jackfruit/5319
https://forum.cosmos.network/t/cosmos-sdk-vulnerability-retrospective-security-advisory-jackfruit-october-12-2021/5349
https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-2p6r-37p9-89p2
Extrait du code vulnérable :
Correctif :
https://github.com/cosmos/cosmos-sdk/compare/v0.44.1...v0.44.2
Des problèmes liés à l’horodatage apparaissent non seulement dans des composants de base comme le SDK Cosmos, mais aussi dans diverses chaînes applicatives.
-
Exemple 2
Contexte de la vulnérabilité : projet SuperNova, nova
Adresse du projet : https://github.com/Carina-labs/nova/tree/v0.6.3
Utilisation de time.Now() pour obtenir l’horodatage du système d’exploitation. L’heure locale est subjective, donc non déterministe. En raison des légères différences possibles entre les horodatages des nœuds, la chaîne pourrait ne pas atteindre un consensus. Dans le module ICAControl, la fonction d’envoi de transaction utilise time.Now() pour récupérer l’horodatage.
Emplacement de la vulnérabilité : https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/icacontrol/keeper/send_msgs.go#L1
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
CertiK
