Cosmos-SDK is a framework for building blockchain applications that use Tendermint Core as the consensus and networking layer. IBC, implemented by Cosmos-SDK, is a protocol that allows blockchains to communicate, such as transferring tokens and assets across different chains.
In this post, we will share a critical vulnerability in Cosmos-SDK that could have enabled an attacker to steal billions of dollars in digital assets from the Cosmos ecosystem. Verichains independently discovered and privately reported to Cosmos maintainer this ICS-23 vulnerability in early October last year, together with several other issues in IAVL proof verification (VSA-2022-100 & VSA-2022-101).
Background
In early October 2022, Verichains researchers discovered a critical vulnerability that affects the Inter-Blockchain Communication (IBC) protocol implemented by Cosmos-SDK.
The root cause of this vulnerability was the lack of soundness in the ICS-23 specification, which defines the language and format of Merkle proofs for IBC. Merkle proofs are cryptographic evidence that proves the existence or absence of data in a Merkle tree, which is a data structure used by many blockchains to store and verify transactions. The ICS-23 specification did not ensure that the Merkle proofs were consistent with the original Merkle tree and therefore allowed for false proofs to be generated and accepted by the IBC protocol.
All IBC channels across Cosmos networks were affected by this vulnerability. This means that funds in digital assets across Cosmos networks were at risk of being exploited if not patched, which amounts to billions of dollars.
Disclosure
Verichains immediately reported this vulnerability to Cosmos maintainers with detailed technical analysis and proof-of-concept code. Cosmos maintainers acknowledged the vulnerability but mentioned that they had also discovered the same issue via an internal security review. They informed us that they were working on patches and upgrades for affected chains.
Following the request from Cosmos maintainers, Verichains agreed to hold off on the public release of this vulnerability until the Cosmos ecosystem was sufficiently upgraded. We also refrained from disclosing this issue to any third parties or media outlets.
On December 2022, Cosmos project published a retrospective post, detailing security advisories Dragonberry and Elderflower related to Cosmos-SDK and IBC vulnerabilities, respectively.
However, the retrospective provided very brief information on the issues without disclosing any technical details or impact analysis. Additionally, there was also no credit for our vulnerability report that we submitted to them in October 2022.
Release
Cosmos released patches that added more validation checks on leaf/inner-node prefix/suffix length when an input Merkle membership proof conforms to the IAVL spec. However, these checks help mitigate the attack for IAVL and Cosmos-SDK only. It is important to note that other projects relying on ICS-23 might still suffer from this vulnerability.
As part of our commitment to security and responsible disclosure, Verichains now release the detail of this vulnerability to the public following our vulnerability disclosure policy. We believe this approach can encourage responsible disclosure and improve the overall security of the ecosystem.
We also recommend that any project using ICS-23 should re-audit its code and ensure that they are not vulnerable to this attack.
Analysis
The standard Cosmos ICS-23 IAVL and Tendermint specs define the serialization of a leaf, which is essentially a key-value pair, to be a concatenation of a leaf prefix, key length (variable length encoding), key, the byte 32 (SHA256 digest size) and the SHA256 digest of value).
The weirdest thing is that a Merkle proof is allowed to carry specs parameters:
Here, `ExistenceProof.Leaf` contains the leaf prefix, specifies which hash functions to use, how integers are encoded, … These parameters are actually used to compute the Merkle root. Later on, they are checked against the standard spec for consistency. However, the input leaf prefix is only required to contain the one in the standard spec as its prefix:
Therefore, if a key-value pair is already stored in a Merkle tree and the key has a suffix of the form `len(subkey) | subkey`, then a membership proof for the subkey-value pair can be forged via forging a leaf as in the following figure:
Exploitation
Here’s a PoC demonstrating this attack:
Affected Products
Cosmos-SDK version 0.45.9 and earlier
All IBC-enabled Cosmos chains, for all versions of IBC released before Oct 16, 2022
Patches
Cosmos released patches that include extra checks for the length of both prefix and suffix in the nodes/leaves, specifically to the way Cosmos-SDK generates a Merkle membership proof. Some notes on the patches as below:
Updates on Oct 16, 2022
Cosmos released a patch for Cosmos-SDK, in which they replaced the use of ICS-23 implementation at `github.com/confio/ics23` with their own implementation at `github.com/cosmos/cosmos-sdk/ics23`
replace github.com/confio/ics23/go => github.com/cosmos/cosmos-sdk/ics23/go v0.8.0
Compared with the original version, they have added more checks on leaf/inner-node prefix/suffix length when an input Merkle membership proof conforms to the IAVL spec:
Here, g(spec) returns true if spec equals IavlSpec:
And the function `z` is responsible for performing the additional checks. These checks help mitigate the attack for IAVL and Cosmos-SDK only. Other projects relying on `github.com/confio/ics23` might still suffer from this vulnerability.
Updates on Oct 20, 2022
BNB Chain applied the same fix at https://github.com/bnb-chain/ics23/commit/746bd0bfbc977a00d9a7884147caad240632c322
Updates on Nov 28, 2022
Cosmos also applied the patch to `github.com/confio/ics23` (https://github.com/cosmos/ics23/commit/ecbe025cb2450f73f2eacf90b507f0850028ca73) and renamed the project to `cosmos/ics23` (https://github.com/cosmos/ics23/commit/39702c6510089683fc6a7c8a81b3bd3ec2be1e0).
However, only `IavlSpec` (used by Cosmos-SDK) is protected. As a result, other projects depending on this library might still be vulnerable. We recommend that any project using ICS-23 should re-audit its code and ensure that they are not vulnerable to this attack.
—
Verichains is dedicated to finding and reporting vulnerabilities in the blockchain industry. We offer security audits, penetration testing, bug bounty programs, and consulting services for blockchain projects. If you are interested in working with us or learning more about our work, please visit our website or contact us at info@verichains.com.
You are the real deal friends.
Unfortunately I have to believe you about the issues that you had getting recognition for your report because I've had the same on a bunch of stuff. I think we should talk.