The Cosmos ecosystem, renowned globally as one of the largest and most notable blockchain networks, prioritizes blockchain interoperability. This focus is key to facilitating seamless communication among diverse blockchains. The ecosystem is home to several leading projects such as Celestia and dYdX v4, all developed using the Cosmos SDK and IBC protocol. The growing preference of developers for Cosmos’ components has led to a magnified impact of security issues within the ecosystem. A case in point is the Dragonfruit vulnerability in the Cosmos SDK, which disrupted operations in numerous mainstream public blockchains.

Given the decentralized nature of Cosmos’ core components, developers are often required to adapt and extend these components based on specific functional needs. This leads to a fragmentation of security challenges within the Cosmos ecosystem. Consequently, there’s a pressing need for a structured approach to understanding and addressing these security concerns. This article aims to provide a comprehensive analysis of the current security landscape in the Cosmos ecosystem and to outline effective response strategies.

The CertiK team is dedicated to bolstering the security of the Cosmos network and the broader Web3 ecosystem through ongoing research and development. We are excited to share our findings and insights with you through regular security reports and technical research updates. Should you have any inquiries, our team is always available for contact.

Here is the full text of the “Cosmos Ecosystem Security Guide” 👇.

Cosmos Overview

Regarded as one of the world’s most prominent blockchain ecosystems, Cosmos stands out with its open-source, scalable, and cross-chain network capabilities. Developed by the CometBFT team, originally known as Tendermint, Cosmos aims to eliminate information silos and facilitate interoperability among diverse blockchains. In an era where multiple blockchain networks coexist, the need for cross-chain interaction is more pressing than ever.

Cosmos distinguishes itself by offering an efficient cross-chain model, especially beneficial for public chains with specific vertical focuses. Its modular blockchain infrastructure empowers application developers, providing them with the flexibility to select and utilize public chains that align with their specific requirements.

At the heart of the Cosmos ecosystem is the Inter-Blockchain Communication (IBC) Protocol, which connects applications and protocols across different independent blockchains. This facilitates not only the seamless transfer of assets and data but also aligns with Cosmos’s vision of creating an ‘internet of blockchains.’ This concept envisions a vast network of autonomous and easily developed blockchains, interconnected for expansion and interaction.

CertiK’s Involvement and Research in Cosmos Security

For an extended period, CertiK has been deeply involved in researching the Cosmos ecosystem. Our team has gained substantial experience in addressing security challenges within this environment. In this report, we will share our insights and discoveries on Cosmos ecosystem security, focusing on four key areas: Cosmos SDK security, IBC protocol security, CometBFT security, and CosmWasm security. Our discussion will cover everything from the fundamental components of the Cosmos ecosystem to its foundational and application chains. By examining and extrapolating related issues, we aim to present a comprehensive, bottom-up analysis of the critical security aspects within the Cosmos ecosystem.

Given the complexity and diversity of the Cosmos ecosystem, it faces a broad spectrum of security challenges. This report primarily concentrates on the most characteristic and significant threats to the ecological chain of Cosmos. For further information or discussions on other security aspects, we encourage you to reach out to CertiK’s security engineers.

Background

CometBFT: Enhancing Cross-Chain Scalability at Its Core

At the heart of Interchain scalability lies CometBFT, a cutting-edge consensus algorithm integral to ensuring the security, decentralization, and integrity of the Interchain ecosystem. This algorithm is a composite of two primary components: the CometBFT Core, serving as the fundamental consensus engine, and a universal application blockchain interface (ABCI). By combining elements of PBFT (Practical Byzantine Fault Tolerance) and Bonded Proof of Stake (PoS), CometBFT synchronizes nodes to maintain accurate transaction records, thus playing a pivotal role in validator consensus within the Interchain environment.

Cosmos SDK: Accelerating Blockchain Development with Modularity

The Cosmos SDK stands as a powerful toolkit that simplifies and accelerates blockchain development. Its modular design and pluggable features empower developers to build their own blockchains or functional components atop the CometBFT consensus algorithm. This approach not only eases development but also significantly shortens the development cycle. The SDK’s effectiveness is evidenced by its adoption in numerous projects, including Cronos, Kava, and the recently launched dYdX V4. Looking ahead, the Cosmos SDK plans to enhance its modularity and introduce new features, enabling the creation of more sophisticated and modular applications, thereby nurturing a more expansive and robust ecosystem.

IBC Protocol: Driving Interoperability and Scalability Across Blockchains

The Inter-Blockchain Communication (IBC) protocol is pivotal in facilitating secure, decentralized, and permissionless data transfer between blockchains within the Cosmos network. Given that Cosmos is a decentralized network comprising multiple independent and parallel blockchains connected through relay technology, the IBC protocol’s role in enhancing scalability and interoperability is central. The Interchain Foundation’s current focus is on improving these aspects of the IBC protocol, aiming to bolster seamless interactions across blockchains, applications, and smart contracts within the Cosmos ecosystem.

CosmWasm: Facilitating Decentralized Application Deployment

CosmWasm (Cosmos WebAssembly) is a smart contract framework tailored for the Cosmos ecosystem. Based on WebAssembly, it allows developers to deploy decentralized applications without needing specific permissions. This framework enables blockchain developers to decouple product development from blockchain development, reducing the burden on validator upgrades. CosmWasm’s features include a modular architecture, integration with the Cosmos SDK, and cross-chain communication capabilities. Cosmos SDK and the IBC protocol, being relatively mature, are widely utilized in the current Cosmos ecosystem.

Adapting and Customizing within the Cosmos Ecosystem

For chain developers in the Cosmos ecosystem, the Cosmos SDK fulfills most customization needs. During cross-chain activities, chain developers may tailor their IBC modules for special operations or performance optimization. While some chains modify underlying engines like CometBFT Core, space constraints preclude a detailed discussion of such modifications in this report. Therefore, this research primarily focuses on the technical nuances and security considerations of the Cosmos SDK and the IBC protocol.

Cosmos SDK Security Guide

The Cosmos SDK Security Guide provides a comprehensive overview of the security aspects of the Cosmos SDK, an advanced framework for developing blockchain applications and decentralized protocols. Created by the Interchain Foundation, this framework is pivotal to the Cosmos network, which is a sprawling network of interconnected blockchains.

At its core, the Cosmos SDK is designed to streamline the creation of tailored blockchain applications while facilitating seamless interaction among diverse blockchains. Its notable features encompass a modular structure, extensive customizability, integration with the CometBFT Core for consensus, and the implementation of IBC interfaces, all contributing to its appeal to developers. A key strength of the Cosmos SDK is its reliance on the CometBFT Core consensus engine, which provides robust security measures. This engine plays a vital role in defending the network against malicious attacks and in protecting the assets and data of users. The modular nature of the SDK empowers users to craft bespoke modules with ease. However, developers must be vigilant as security vulnerabilities can still arise when deploying applications using the Cosmos SDK.

From the standpoint of security auditing, it’s essential to thoroughly assess potential security threats from multiple perspectives. Contrastingly, in security research, the emphasis shifts to pinpointing vulnerabilities that could have significant repercussions. This approach aims to mitigate major security threats promptly, thereby offering more effective assistance to services integrating the SDK. It’s crucial to identify and scrutinize vulnerabilities that pose severe risks and have widespread implications.

A focal point within the Cosmos SDK is the ABCI interface, which is integral to the Cosmos ecosystem. This interface comprises four key components: BeginBlock, EndBlock, CheckTx, and DeliverTx. BeginBlock and EndBlock are directly involved in the execution logic of individual blocks. In contrast, CheckTx and DeliverTx are concerned with processing sdk.Msg, the foundational data structure for message transmission within the Cosmos ecosystem.

To understand and address the security vulnerabilities mentioned, one must first grasp the transaction life cycle in the Cosmos ecosystem. Transactions originate from user agents, where they are created, signed, and then broadcast to blockchain nodes. The CheckTx method is employed by nodes to validate transaction details such as signatures, the sender’s balance, the transaction sequence, and the gas provided. Valid transactions are queued in the mempool, awaiting inclusion in a block, while invalid ones are rejected, with error messages relayed to the users. During block processing, the DeliverTx method is applied to ensure transactional consistency and determinism.

In the Cosmos SDK, the transaction life cycle is a multi-stage process, encompassing creation, validation, inclusion in a block, state changes, and final commitment. This process can be outlined in the following steps:

1. Transaction Creation: Users generate transactions using various tools such as Command Line Interfaces (CLI) or frontend clients.

2. Addition to the Mempool: Once created, transactions enter the mempool. Here, nodes send an ABCI (Application BlockChain Interface) message, known as CheckTx, to the application layer for validity checking. Transactions undergo decoding from byte format to Tx format. Each sdk.Msg within the transaction is subjected to preliminary stateless checks by the ValidateBasic() function. Additionally, if the application includes an anteHandler, its logic is executed prior to the runTx function, which leads to the RunMsgs() function for processing the sdk.Msg content. Successful CheckTx results in the transaction being queued in the local mempool, poised for inclusion in the next block, and simultaneously broadcasted to peer nodes via P2P.

3. Inclusion in a Proposed Block: During each round’s beginning, the proposer assembles a block containing recent transactions. Validators, who are responsible for maintaining consensus, either approve this block or opt for an empty block.

4. State Changes: Similar to CheckTx, the DeliverTx process iterates through block transactions. However, it operates in ‘Deliver’ mode, executing state changes. The MsgServiceRouter directs different transaction messages to respective modules, where each message is processed in the Msg Server. After message execution, further checks ensure transaction validity. If any check fails, the state reverts to its previous condition. A Gas meter tracks the consumed gas during execution. Gas-related errors, such as insufficient gas, lead to a reversion of state changes, similar to execution failures.

5. Block Commitment: Upon receiving sufficient validator votes, a node commits the new block to the blockchain. This action finalizes the state transitions at the application layer, marking the completion of the transaction process.

)

[This section includes a diagram depicting the life cycle of transactions in the Cosmos ecosystem.]

[The following section provides specific execution logic of key ABCI in Cosmos SDK, useful for understanding and analyzing the vulnerabilities discussed later.]

)

Common Vulnerability Categories

Before understanding the classification of vulnerabilities, we need to have a basic division of the danger level of vulnerabilities. This helps in better identifying high-risk security vulnerabilities and avoiding potential security risks.

)

Considering the level of danger and the scope of impact, we mainly focus on Critical and Major rated security vulnerabilities, which can usually cause the following risks:

1. Chain stopping operation
2. Financial loss
3. Affecting the system state or normal operation

The causes of these dangers are often the following types of security vulnerabilities:

1. Denial of Service
2. Incorrect state settings
3. Lack of or unreasonable verification
4. Uniqueness issues
5. Consensus algorithm problems
6. Logical flaws in implementation
7. Language feature issues

Vulnerability Analysis in the Cosmos Ecosystem

The Cosmos ecosystem, known for its modular structure, often encounters module inter-use and inter-calling within its chains. This complexity leads to scenarios where the vulnerability trigger path and the location variables are inconsistent. In understanding these vulnerabilities, it’s crucial not just to consider the trigger path but also the controllable path of the vulnerability’s critical variables. This dual focus aids in better defining and categorizing the vulnerability model.

Chain Stopping Operation: Causes and Types

Chain stoppages are typically due to issues encountered during the execution of a single block. However, Cosmos’s history includes instances where consensus security vulnerabilities necessitated active chain halts for repairs. These problems fall into two distinct categories.

The first type is commonly seen in Denial of Service Vulnerabilities: These are frequently a result of inadequate crash handling and user-influenced loop boundary operations. Such vulnerabilities can lead to the chain pausing or slowing down significantly.

Cosmos SDK and CometBFT, key infrastructures in the Cosmos ecosystem, are not only used by the base chains in Cosmos but also by various application chains based on their architecture. They all follow the ABCI interface rules of CometBFT. The focus of their attack surface is also on their ABCI interface, and most of the security vulnerabilities that can cause Chain halt are issues that can directly affect block code execution. Therefore, their occurrence paths can generally be traced back to the BeginBlock and EndBlock interfaces.

The second type of situation involves Vulnerabilities Affecting Consensus: These often relate to the implementation across various chains and include issues in logic processing validation, time calibration, and randomness. These vulnerabilities strike at the heart of blockchain’s decentralization principle. While they might not appear severe initially, in the hands of a malicious actor, they pose a substantial security threat.

Examples of the First Type

Example 1: SuperNova Project Vulnerability Analysis

Vulnerability background: In the process of minting distribution within the SuperNova Project, a critical issue arises from the absence of address verification. This oversight can lead to operation failure and, consequently, financial loss. Specifically, the minting module, which is pivotal for token generation, relies on the amount staked. However, this process is susceptible to errors. For instance, if the designated pool is non-existent or if there is an erroneous entry of the contract address, it can lead to malfunctions in the minting module. Such errors have the potential to halt the entire blockchain operation. Additionally, in the rewards pool module, there is a lack of verification for the pool contract address. This oversight means that any failure in the distribution operation could cause an immediate stoppage of the blockchain.

Vulnerability location: SuperNova GitHub Link

Vulnerable code snippet:

Vulnerability trigger path:

BeginBlocker (/x/mint/keeper/abci.go)

Keeper.DistributeMintedCoin

Keeper.distributeLPIncentivePools

PoolIncentiveKeeper.GetAllIncentivePool (/x/mint/keeper/keeper.go)

Vulnerability patch:

https://github.com/Carina-labs/nova/commit/538abc771dea68e33fd656031cbcf2b8fe006be0

The patch is located in the message handling module of poolincentive (x/poolincentive/types/msgs.go), not the mint module. It added address verification to the MsgCreateCandidatePool message to eliminate the possibility of incorrect addresses from the root.

Example 2: Cosmos Interchain Security Project

Project address: Cosmos Interchain Security GitHub Link

Vulnerability background: Validators can slow down the provider chain by submitting multiple AssignConsumerKey messages in the same block. In the x/ccv/provider/keeper/key_assignment.go file, the AssignConsumerKey function allows validators to assign different consumerKeys to approved consumer chains. The consumerAddrsToPrune AddressList increases by one element to perform this operation. Since this AddressList is iterated in the EndBlocker in x/ccv/provider/keeper/relay.go, attackers can exploit it to slow down the provider chain. For this attack, the malicious actor can create transactions with multiple AssignConsumerKey messages and send them to the provider chain. The cardinality of the consumerAddrsToPrune AddressList will be the same as the sent AssignConsumerKey messages. Therefore, the execution of EndBlocker will take more time and resources than expected, slowing down or even stopping the provider chain.

Vulnerability location: Cosmos Interchain Security GitHub Link

Vulnerability Code Segment:

Vulnerability trigger path:

msgServer.AssignConsumerKey

Keeper.AssignConsumerKey

AppModule.EndBlock

EndBlockCIS

HandleLeadingVSCMaturedPackets

HandleVSCMaturedPacket

PruneKeyAssignments

Example 3: Quicksilver Project - Airdrop Module

Vulnerability background: BeginBlocker and EndBlocker are optional methods that module developers can implement in their module. They are triggered at the start and end of each block, respectively. Using crashes to handle errors in the BeginBlock and EndBlock methods may cause the chain to stop in case of errors. The EndBlocker did not consider whether the module had enough tokens to settle unfinished airdrops, which could trigger a crash and stop the chain.

Vulnerability location: Quicksilver GitHub Link

Vulnerability Code Segment:

Vulnerability patch: AppModule.EndBlock

Keeper.EndBlocker

Keeper.EndZoneDrop

Vulnerability patch: https://github.com/quicksilver-zone/quicksilver/blob/20dc658480b1af1cb323b4ab4a8e5925ee79a0ed/x/airdrop/keeper/abci.go#L16

The panic handling code was removed and replaced with error logging.

Example 4: Cosmos Interchain Security Project

Project address: Cosmos Interchain Security GitHub Link

Vulnerability background: Attackers can perform a Denial of Service attack by sending multiple tokens to the reward address of the provider chain. In the consumer chain’s EndBlocker execution flow, the SendRewardsToProvider function defined in x/ccv/consumer/keeper/distribution.go retrieves the balance of all tokens in tstProviderAddr and sends them to the provider chain. To achieve this, it must iterate through all the tokens found in the reward address and send each one via IBC to the provider chain. Since anyone can send tokens to the reward address, attackers can create and send a large number of different denom tokens, for instance, using a chain with a token factory module, to initiate a Denial of Service attack. Therefore, the execution of EndBlocker will take more time and resources than expected, slowing down or even stopping the consumer chain.

Vulnerability location: Cosmos Interchain Security GitHub Link

Vulnerability Code Segment:

Vulnerability trigger path:

AppModule.EndBlock

EndBlock

EndBlockRD

SendRewardsToProvider

Second Type of Situation

This type of consensus issue may not bring immediate severe harm, but when considering the whole blockchain’s fundamental principles and system, or looking at these vulnerabilities from specific scenarios, their impact and harm may not be less than other conventional vulnerabilities. In addition, these vulnerabilities have common characteristics.

Example 1

Vulnerability background: Cosmos SDK Security Advisory Jackfruit

Non-deterministic behavior in the ValidateBasic method of the x/authz module in Cosmos SDK can easily lead to a consensus halt. The MsgGrant message structure in the x/authz module includes a Grant field, which contains the expiration time granted by user-defined authorization. In the validation process of ValidateBasic() in the Grant structure, it compares its time information with the node’s local time information rather than the block time information. Since local time is non-deterministic, timestamps may differ between nodes, leading to consensus issues.

Vulnerability announcement:

• Cosmos Forum Link 1

• Cosmos Forum Link 2

• Cosmos SDK GitHub Security Advisory Link

Vulnerability Code Segment:

Vulnerability patch: Cosmos SDK GitHub Compare Link

Issues like timestamps not only appear in fundamental components like Cosmos SDK but also have occurred in various application chains.

Example 2

Vulnerability background: SuperNova, nova project

Project address: SuperNova GitHub Link

Using time.Now() returns the operating system’s timestamp. Local time is subjective and thus non-deterministic.Since there may be small differences in the timestamps of individual nodes, the chain may not reach consensus. In the ICAControl module, the transaction sending function uses time.Now() to get the timestamp.

Vulnerability location: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/icacontrol/keeper/send_msgs.go#L14

Vulnerability Code Segment:

Vulnerability patch:

Changed from using local timestamp to using block time.

timeoutTimestamp := time.Now().Add(time.Minute * 10).UnixNano() _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp))

timeoutTimestamp := uint64(ctx.BlockTime().UnixNano() + 10*time.Minute.Nanoseconds()) _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp))

Case Three:

Vulnerability Background: Oracle Module in the BandChain Project

Project URL: BandChain GitHub Repository

The comments in the code repository indicate that the oracle module must be executed before staking to implement punishment measures for violators of the oracle protocol. However, in the code, the sequence is reversed: in the SetOrderEndBlockers function, the staking module runs before the oracle module. If the staking module is executed before the oracle module, it would be impossible to enforce penalties based on the verifications completed in the oracle module.

Vulnerability Location: BandChain GitHub Code Snippet

Vulnerability Code Segment:

The vulnerability lies in the actual implementation and comments being contradictory, where the oracle module should be placed before the staking module.

Case Four:

Vulnerability Background: Accesscontrol Module in the Sei Cosmos Project

Project URL: Sei Cosmos GitHub Repository

In multiple instances across Cosmos-related code repositories, there is the use of the Go language’s map type and iteration over it. Due to the non-deterministic nature of Go’s map iteration, this could lead to nodes reaching different states, potentially causing consensus issues and consequently stopping the chain from operating. A more appropriate method would be to sort the map keys into a slice and iterate over the sorted keys. Such issues are common, stemming from the application of language features.

In the implementation of BuildDependencyDag in x/accesscontrol/keeper/keeper.go, there is iteration over anteDepSet nodes. Due to the non-deterministic behavior of map iteration in Go, ValidateAccessOp could result in two different types of errors, potentially leading to a consensus failure.

Vulnerability Location: Sei Cosmos GitHub Code Snippet

Vulnerability Code Segment:

From these cases, it is evident that vulnerabilities causing a chain to stop running passively are often the most harmful. Their causative logic can be traced back to directly affecting the execution flow of individual blocks in a blockchain. In contrast, consensus security vulnerabilities usually result in the chain actively stopping to implement fixes, with their causative logic traced back to affecting the overall operational flow and state of the blockchain. This differs from the focus of vulnerabilities that lead to financial losses, where the specific dangerous impact is not judged based on the logic path of the issue’s occurrence but rather focuses on the owners of the funds, the amount of money involved, the scope, and the methods affecting the funds.

loss of funds

Issues of capital loss are commonly seen in the logical handling of sdk.Msg and IBC messages. Of course, there are also some vulnerabilities that can cause capital loss among the reasons that can halt the operation of a blockchain. The specific impact depends on the particular vulnerability, and here we focus on the former. Additionally, since IBC is a very important component of the Cosmos ecosystem, it inevitably involves some vulnerabilities in IBC. Specifics about IBC’s attack surface and corresponding vulnerabilities will be discussed in the next chapter.

Capital losses are commonly encountered in scenarios such as gas consumption, funds being locked and unable to be withdrawn, loss of funds during transfer, errors in computation logic leading to loss of funds, and failure to ensure the uniqueness of fund storage IDs.

Here, we take the SuperNova project as an example to analyze three related vulnerabilities.

Vulnerability Background: SuperNova Project

Project URL: https://github.com/Carina-labs/nova

If the decimal places in a zone exceed 18, funds may become locked. In this project’s code, there is no upper limit on the decimal places of a zone, which can exceed 18. In ClaimSnMessage, when users want to claim their share tokens, ClaimShareToken is used. However, if the decimal places of the zone exceed 18, the conversion will fail, and it will be impossible to extract assets from the system. Thus, by controlling the decimal places of a zone, it is possible to directly trigger a transaction crash and failure.

Vulnerability Location: https://github.com/Carina-labs/nova/blob/v0.6.3/x/gal/keeper/claim.go#L167

Vulnerability Code Fragment:

Vulnerability trigger path:

msgServer.ClaimSnAsset

Keeper.ClaimShareToken

Keeper.ConvertWAssetToSnAssetDecimal

precisionMultiplier

• Vulnerability background: SuperNova project

Project address: https://github.com/Carina-labs/nova/

The uniqueness of the zone is not verified. On registered regions, use the region ID to check the uniqueness of the base token (BaseDenom). The BaseDenom for each region should be unique. If the value of the base token is set incorrectly, it will result in a loss of funds. Before setting the base token in the RegisterZone, the project did not ensure that the BaseDenom was unique in all main zones. Otherwise, there would be the possibility of users storing funds in another malicious zone containing a BaseDenom with the same name, resulting in loss of funds.

Vulnerability location: https://github.com/Carina-labs/nova/blob/v0.6.3/x/icacontrol/keeper/msg_server.go#L99

Vulnerable code snippet:

Bug patch: Added DenomDuplicateCheck check

In addition, the first case in the first case where the chain stops running is due to a crash that leads to the failure of minting, which is also a form of capital loss.

• Vulnerability background: Supernova project

Project address: https://github.com/Carina-labs/nova/

Missing status updates. In the IcaWithdraw() method, if the transaction fails and the version status is not modified, the WithdrawRecord will be inaccessible and the corresponding funds cannot be withdrawn. A more popular understanding is that the state is set before SendTx, and the state is not modified after the failure, causing the fund withdrawal to fail and cannot be withdrawn again next time.

Vulnerability location: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/gal/keeper/msg_server.go#L356

Vulnerable code snippet:

Based on this excerpt, we can discern that the main logic of operations related to funds mainly depends on the handling of various messages. Of course, there are also cases like the first scenario involving minting operations in the BeginBlock execution process. When these operations fail, they can also lead to financial losses. Overall, by focusing our audit on code modules that involve financial operations, we can significantly increase the likelihood of discovering such vulnerabilities.

Impacting System State or Normal Operation

The range of this category of issues is quite broad. The first two types of risks we discussed can also be considered as subsets of vulnerabilities that affect system state or normal operation. In addition to these, more dangerous are various logical vulnerabilities. To a large extent, these vulnerabilities generate different security risks according to the business logic of the project. However, due to the similarities in the construction of Cosmos SDK components and their modular nature, similar errors often occur in specific code implementations. Here we list some common types of vulnerabilities:

- Incomplete variable validation in sdk.Msg type:

Since various projects have implemented a variety of derived types based on sdk.Msg, not all existing types’ elements have been checked accordingly in Cosmos SDK. This has led to the omission of critical embedded variable checks, thereby posing certain security risks.

Case Study: Cosmos SDK Security Advisory Barberry

Vulnerability background: The MsgCreatePeriodicVestingAccount.ValidateBasic lacks mechanisms for assessing the status of an account, such as whether it’s active. In the x/auth defined PeriodicVestingAccount, an attacker could initialize a victim’s account to a maliciously owned account. This account allows deposits but prohibits withdrawals. When users deposit funds into their account, these funds will be permanently locked, and the user will be unable to withdraw them.

Vulnerability patch:

https://forum.cosmos.network/t/cosmos-sdk-security-advisory-barberry/10825

https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-j2cr-jc39-wpx5

https://github.com/cosmos/cosmos-sdk/compare/v0.47.3-rc.0...v0.47.3

https://github.com/cosmos/cosmos-sdk/pull/16465

Vulnerable code snippet:

In addition to this, problems in the ValidateBasic stage were also present in Cosmos-SDK Security Advisory Elderflower and Cosmos-SDK Security Advisory Jackfruit. The former suffered from a direct omission of the ValidateBasic call, while the latter involved issues with timestamp variable verification within the message. In application chains, such issues are even more common. Projects like ethermint, pstake-native, and quicksilver have all encountered similar security vulnerabilities in their message processing verification measures.

Apart from verification types, there are also issues encountered in the handling logic of sdk.Msg, such as operations involving extensive gas consumption, loops, and unreasonable crash handling. Since the processing chain for messages has corresponding recovery mechanisms, their danger level is somewhat lower than a complete chain shutdown. However, they can still impact the normal operation of the system or lead to loss of funds on the chain.

Common Vulnerability Types

Excluding vulnerabilities unique to specific project operations, there are some more common vulnerability models. For instance, the third case of fund loss is an operation that changes the state before sending a message. This type of vulnerability is similar to those in smart contracts, where changing the state before transferring funds can lead to problems like re-entrance or lingering erroneous states. Scenarios where state setting is closely tied to message transmission are quite common in blockchain, and many significant vulnerabilities originate from such issues. Besides, there are computational security vulnerabilities like division-by-zero errors, gas consumption bypasses, and use of versions with known vulnerabilities, all of which can affect the system’s state or normal operation.

Uniqueness Issues

Due to numerous read and write operations on the blockchain, uniqueness in naming is extremely important in some functionalities. For example, the second case of fund loss mentioned earlier is an issue of uniqueness. Furthermore, the composition of prefixes in variables representing keys, such as strings or byte arrays, can pose risks. A slight oversight could result in names being misconstrued, leading to issues like fund loss or consensus errors.

Language Feature Issues

These are broader but have identifiable characteristics, making them easier to detect. Examples include issues with map iteration in Golang or panic mechanisms in Rust. It’s advisable to list these language-specific risk factors and pay special attention to them during use or audit to minimize such errors.

Summary

From our exploration of underlying security issues in the Cosmos ecosystem, it’s clear that these problems are not unique to Cosmos and can be applied to other blockchain ecosystems as well. Here are some recommendations and conclusions regarding the security issues in the Cosmos ecosystem:

• Pay attention to infrastructure vulnerabilities: Core components like CometBFT and Cosmos SDK might also have vulnerabilities, so regular updates and maintenance are necessary for security.

• Review third-party libraries promptly: Cosmos developers often use third-party libraries to extend their applications’ functionalities. These libraries might contain potential vulnerabilities, thus requiring review and updates to mitigate risks.

• Be wary of malicious node attacks: Consensus nodes are crucial in the Cosmos ecosystem. The Byzantine fault tolerance algorithms of these nodes might be susceptible to attacks, so ensuring node security is essential to prevent malicious behavior.

• Consider physical security: Physical security measures are needed for hardware and servers running Cosmos nodes to prevent unauthorized access and potential attacks.

• Conduct necessary code reviews: Given the openness of the Cosmos SDK and CometBFT ecosystems, developers and auditors should review both the core code and code written in custom modules to identify and correct potential security issues.

• Pay attention to ecosystem tools: The Cosmos ecosystem includes many tools and applications, which also need to undergo security reviews and regular updates to ensure their safety.

IBC Protocol Security Guide

This module focuses on the security aspects of the Inter-Blockchain Communication (IBC) protocol, a crucial component in the Cosmos ecosystem. The IBC protocol serves as a bridge for interactions between different blockchains. While other cross-chain bridges provide solutions for specific, isolated issues, the IBC protocol offers a unified foundational solution and underlying technical support for inter-chain interactions. IBC is a protocol that allows heterogeneous blockchains to transfer any data in a reliable, orderly, and minimally trusted manner.

Since the advent of Bitcoin, the blockchain field has experienced explosive growth. Countless new networks have emerged, each with its unique value proposition, consensus mechanisms, ideologies, supporters, and reasons for existence. Before the introduction of IBC, these blockchains operated independently, like in closed containers, unable to communicate with each other, a fundamentally unsustainable model.

If blockchains are viewed as countries with growing populations and bustling commercial activities, some excel in agriculture, others in livestock farming. Naturally, they seek mutually beneficial trade and cooperation, leveraging their respective strengths. It’s no exaggeration to say that IBC has opened a new world of limitless possibilities, enabling different blockchains to interoperate, transfer value, exchange assets and services, and establish connections, unhampered by the inherent scalability issues of today’s large blockchain networks.

So, how does IBC meet these needs and play such a crucial role? The fundamental reasons are that IBC is:

1. Trust-minimized

2. Capable of supporting heterogeneous blockchains

3. Customizable at the application layer

4. A mature, tested technology

The foundation of the IBC protocol lies in light clients and relayers. Chains A and B communicating through IBC each possess light clients of the other’s ledger. Chain A, without needing to trust a third party, can reach consensus on Chain B’s state by verifying its block headers. Chains interacting through IBC (especially modules) do not directly send messages to each other. Instead, Chain A synchronizes certain messages in a data packet to its state. Subsequently, relayers detect these data packets and transfer them to the target chain.

Overall, the IBC protocol can be divided into two layers: IBC TAO and IBC APP.

• IBC TAO: Defines the standards for data packet transmission, authentication, and ordering, essentially the infrastructure layer. In ICS (Interchain Standards), this consists of core, client, and relayer categories.

• IBC APP: Defines the standards for application handlers of data packets transmitted through the transport layer. These include, but are not limited to, fungible token transfers (ICS-20), non-fungible token transfers (ICS-721), and interchain accounts (ICS-27), and can be found in the application category of ICS.

IBC Protocol (From the Cosmos Developer Portal)

The IBC (Inter-Blockchain Communication) protocol is a cornerstone of the Cosmos ecosystem’s vision of an “Internet of Blockchains.” In this context, the design choices of the IBC are influenced by the TCP/IP standards. Similar to how TCP/IP sets standards for computer communication, IBC specifies a set of universal abstractions that enable blockchains to communicate with each other. Just as TCP/IP does not restrict the content of the data packets relayed through the network, IBC operates in the same way. Moreover, similar to how application protocols like HTTP and SMTP are built on top of TCP/IP, applications such as homogenized asset/non-fungible asset transfers or cross-chain smart contract calls also use the IBC protocol as a foundational layer.

The main issues currently seen with the IBC protocol are related to channel transmission and packet processing. There have been significant problems in proof verification, but these are relatively less common. This article focuses on the common issues of the IBC protocol. Thanks to the modular design of the IBC protocol, IBC application developers do not need to concern themselves with underlying details like clients, connections, and proof verification. However, they need to implement the IBCModule interface and corresponding Keeper handling methods. Therefore, many problems related to the IBC protocol arise in the code paths of the IBCModule interfaces for receiving and processing packets (onRecvPacket, OnAcknowledgementPacket, OnTimeoutPacket, etc.).

Common Vulnerability Classifications

In the Cosmos ecosystem, the IBC protocol serves as a connecting hub. The types of vulnerabilities associated with the IBC protocol are diverse and complex due to the close integration of its implementations with modules like Cosmos-SDK and CometBFT. Additionally, since IBC is primarily used in the Cosmos ecosystem, its main programming language is Golang, as detailed in the ibc-go documentation.

Due to space constraints, this article does not delve into detailed analysis of every aspect and component of the IBC protocol. Instead, it classifies some of the existing security vulnerabilities. For a more detailed and comprehensive analysis, you are welcome to contact our CertiK security engineers for discussion.

Common Vulnerability Classifications:

1. Naming Vulnerabilities

   ① String Handling Vulnerabilities

   ② Bytecode Handling Vulnerabilities

2. Transmission Process Vulnerabilities

   ① Packet Order Vulnerabilities

   ② Packet Timeout Vulnerabilities

   ③ Packet Authentication Vulnerabilities

   ④ Other Packet Vulnerabilities

3. Logical Vulnerabilities

   ① State Update Vulnerabilities

   ② Voting and Consensus Vulnerabilities

   ③ Other Logical Vulnerabilities

4. Gas Consumption Vulnerabilities

The existing IBC protocol, in terms of auditing and analyzing its security, shares many similarities with the audit processes of Web2 protocols. This analysis will dissect some of the security issues and potential risks of the IBC protocol from the perspective of protocol establishment, implementation, and application expansion. Since the formulation of the protocol is often completed by a few individuals and organizations, for various blockchain organizations, more work revolves around the implementation and application expansion of the protocol. Therefore, this article will focus on the security issues of these aspects. This approach stems from the consideration of the wide range of security risks covered by the IBC protocol, enabling better categorization of different types of security issues into corresponding stages and modules.

Vulnerability Analysis

Formulation of the IBC Protocol

Case Study 1: ICS-07 Protocol, Logical Vulnerability

Vulnerability Background: Incorrect Use of Unbinding Period

In the code, the following validation exists:

if currentTimestamp.Sub(consState.Timestamp) >= clientState.UnbondingPeriod

According to the Tendermint security model, for a block (header) at time t, the validators in NextValidators need to operate correctly before t+TrustingPeriod. After that, they may exhibit other behaviors. However, the check here is for UnbondingPeriod, not TrustingPeriod, where UnbondingPeriod > TrustingPeriod. If the deadline of consState is between TrustingPeriod and UnbondingPeriod, then this header will be accepted as a benchmark for validating one of the conflicting headers constituting misconduct. During this period, the validators in consState.NextValidators are no longer considered trustworthy, and hostile former validators can shut down the client without any risk.

Project Address: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007-tendermint-client

Vulnerability Location:

• https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007-tendermint-client#misbehaviour-predicate

• https://github.com/cosmos/cosmos-sdk/blob/6344d626db1fbdba5e0f67425703c1584021bf5b/x/ibc/light-clients/07-tendermint/types/misbehaviour_handle.go#L96

Vulnerable Code Snippet:

protocol definition function

Code

Implementation of the IBC Protocol

The implementation stage of the IBC protocol is a phase where issues are prone to arise, as it plays a critical bridging role. It not only needs to avoid ambiguities in the protocol specifications but also needs to provide basic and convenient interfaces for the subsequent application and expansion of the protocol. Therefore, the main issues in the IBC protocol implementation stage can be further categorized into:

1. Ambiguities and non-standard issues in protocol implementation.

2. Errors in protocol settings.

Ambiguities and Non-Standard Issues in Protocol Implementation

Case Study 1: ICS-20 Protocol, Naming Vulnerability

Vulnerability Background: Custodial address conflict. The GetEscrowAddress() function generates a 20-byte truncated SHA256 (Port ID + Channel ID). This method has three issues:

1. Lack of domain separation between ports and channels. The string concatenation method does not separate the domains of the port and the channel. For example, the port/channel combinations (“transfer”, “channel”) and (“trans”, “ferchannel”) will result in the same custodial address, i.e., the truncated SHA256 (“transferchannel”). If certain modules with library functions are allowed to select port and channel IDs, vulnerabilities may arise.

2. Conflicts between module account addresses. Arbitrary alphanumeric strings are used in the pre-image of SHA-256, with a post-image size of 160 bits. This small post-image combined with a fast hash function makes a birthday attack feasible, as its security is only reduced to 80 bits. It means approximately 2^80 guesses are needed to find a collision between two different custodial account addresses. In 2018, a detailed cost analysis of attacking the truncation of SHA256 in the context of Tendermint was conducted, proving that such an attack is feasible from a cost perspective. Finding a collision means that two different custodial accounts map to the same account address. This could lead to risks of funds being stolen from custodial accounts. For more details, see the ICS20 GetEscrowAddress pre-image domain overlaps with public keysT:BUG.

3. Conflicts between module and non-module account addresses. The construction of public account addresses is the same as the 20-byte SHA-256 of Ed25519 public keys. Although the 160-bit security is sufficient to prevent collision attacks on specific public addresses, the security against birthday attacks is only 80 bits. This situation is akin to a semi-birthday attack mode, where one address is generated by the fast SHA-256, and the other address is generated by the relatively slower Ed25519 public key calculations. Although this situation is more secure, it still poses potential attacks on custodial and public accounts.

Project address: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-020-fungible-token-transfer

Vulnerability location: https://github.com/cosmos/cosmos-sdk/blob/6cbbe0d4ef90f886dfc356979b89979ddfcd00d8/x/ibc/applications/transfer/types/keys.go#L40-L47

https://github.com/cosmos/cosmos-sdk/blob/6cbbe0d4ef90f886dfc356979b89979ddfcd00d8/x/ibc/applications/transfer/keeper/relay.go

Vulnerable code snippet:

Protocol setting error problem

• Case 1: IBC Security Advisory Dragonberry, transmission process vulnerability

Vulnerability background: IBC will use a Packet structure when processing application data packets. According to the timeout mechanism, synchronous and asynchronous confirmation mechanisms and the corresponding certification verification process, the data packet will be divided into two execution processes:

1. Normal situation: Success within timeout

2. Timeout situation: timeout failure

IBC application packet transmission flow chart

When a timeout occurs, it means that the transmission failed, and the IBC protocol will initiate a refund process. It should be noted that IBC has a user-configurable timeout mechanism. The Dragonberry vulnerability originates from ICS-23 (IBC). The root cause of this vulnerability is that users can forge non-existence proofs in the verification process (that is, false proofs that no data packets have been received), thus bypassing security checks and forging A “reasonable” IBC timeout situation is used to deceive the IBC protocol, causing the repeater to send timeout packets with false certificates, and may escalate to an ICS-20 double-spending problem. The specific triggering process of the vulnerability can be seen in the figure below.

Dragonberry vulnerability principle flow chart

Project address: https://github.com/cosmos/ibc-go/tree/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel

Vulnerability location: https://github.com/cosmos/ibc-go/blob/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel/keeper/timeout.go#L117C28-L117C54

Vulnerable code snippet:

• Case 2: IBC Security Advisory Huckleberry, transmission process vulnerability

Vulnerability Background: UnreceivedPackets only constructs a response by finding the corresponding packet receipt for each sequence number included in the query. This only works for out-of-order channels, as ordered channels use nextSequenceRecv instead of packet receipts. Therefore, on an ordered channel, querying the sequence number via GetPacketReceipt will not find the receipt within it.

The severity of this issue is minor because the channel transmitted by the ICS-20 FT is mostly out of order and the repeater does not rely on this grpc endpoint to determine which packets trigger the timeout. However, if there are a large number of packets in the target chain, and the ordered channel is configured for IBC transmission, and the grpc response is not paged, this will create a risk of causing the service node performance to degrade or even crash. The specific triggering process can be seen in the figure below.

Huckleberry vulnerability principle flow chart

Project address: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/

Vulnerability location: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/keeper/grpc_query.go#L408

Vulnerable code snippet:

Application and extension of IBC protocol

• Case 1: stride airdrop vulnerability, logic vulnerability

Vulnerability Background: The function TryUpdateAirdropClaim converts the sender address of an IBC packet into a Stride address named senderStrideAddress, and extracts airdropId and the new airdrop address newStrideAddress from the packet metadata. It then calls UpdateAirdropAddress to update the senderStrideAddress and ClaimRecord. With the update of the ClaimRecord, newStrideAddress will be able to claim the airdrop. However, this update function only verifies whether the sender address of the request is empty, and does not validate newStrideAddress. Since IBC allows solo machine connections to implement IBC-enabled chains, this presents a security risk where it is possible to update any other account address as the airdrop address.

Project address: https://github.com/Stride-Labs/stride/tree/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot

Vulnerability location: https://github.com/Stride-Labs/stride/blob/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot/module_ibc.go#L119

https://github.com/Stride-Labs/stride/blob/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot/keeper/airdrop.go#L17

Vulnerable code snippet:

• Case 2: neutron ibc module vulnerability, gas consumption vulnerability

Vulnerability background: In the context of smart contracts, there’s an issue with how fees are verified for confirming or timing out IBC (Inter-Blockchain Communication) events. This flaw allows malicious smart contracts to trigger an ‘ErrorOutOfGas’ crash. This crash occurs during the processing of ‘OnAcknowledgementPacket’ and ‘OnTimeoutPacket’ messages. When this error happens, it’s not possible to resolve it through the usual ‘outOfGasRecovery’ method. As a result, the affected transactions fail to be included in the blockchain block. This failure can cause IBC relayers to repeatedly attempt to submit these messages. Such repeated submissions could lead to financial losses for the relayers and overload the network with an excessive number of unprocessed (‘abandoned’) packets, which poses a risk to the network’s stability.

Project address: https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/

Vulnerability location:

https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/x/interchaintxs/keeper/ibc_handlers.go#L62

Vulnerable code snippet:

Summary

The analysis and discussion of the security issues pertaining to the Inter-Blockchain Communication (IBC) protocol, as presented in the previous text, highlight the widespread and varied nature of these concerns. The primary challenges seem to originate predominantly from the implementation phase and the expansion of applications utilizing the IBC protocol. As various application chains progressively enhance and refine their traditional module functionalities, they simultaneously incorporate diverse code implementations into their IBC modules. This is done to boost performance and to cater to specific business requirements.

In addition to the earlier mentioned security issues in the IBC component, new challenges are surfacing, particularly in IBC middleware. These evolving concerns are anticipated to become increasingly significant in the future, especially regarding the overall security of the Cosmos ecosystem. This shift indicates a growing emphasis on ensuring robust security measures in the IBC module.

Conclusion

Our investigation into the security of the Cosmos ecosystem, involving detailed audits, summarizations, and categorizations, has centered around its two most critical components: the Cosmos SDK and the IBC protocol. Drawing from our extensive practical experience, we’ve compiled a comprehensive collection of general auditing expertise.

This report underscores the unique challenges posed by a heterogeneous network like Cosmos, especially given its support for cross-chain interactions. The complexity and dispersed nature of its components make the task of ensuring their security formidable. It necessitates not only applying our existing knowledge of security risks but also adapting to new security scenarios to address emerging issues.

Despite these hurdles, we are optimistic. By documenting and analyzing common scenarios and security challenges, as we have done in this report, we are paving the way for progressively enhancing the overall security framework within the diverse Cosmos ecosystem.

Disclaimer：

1. This article is reprinted from [CertiK]. All copyrights belong to the original author [CertiK]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.