Full Report
Blockchains have a concept known as gas. Like what you put in your car, it calculates how far you have gone. The only difference is that this one is computational complexity versus the distance on a road. In the Cosmos SDK, which is an application-specific blockchain, some of this gas handling becomes complicated and difficult to handle securely. The Cosmos SDK has handlers that run at the beginning and the end of each block - BeginBlock and EndBlock respectively. Since these are not done in a particular transaction, they have unlimited gas. So, it's essential to be mindful of what gets executed in these functions when building your project. The authors of the post created a Cosmos SDK blockchain locally to test how delays in these functions affected the blockchain's uptime. By adding sleeps at determinstic points within these functions, they noticed some funky things happened. Consensus would commonly timeout. Validators would miss voting windows, leading to slashing of stake. A common exploitation method of this is to increase the number of items being processed in a list. Both of their examples are the processing of messages and processing of denoms in a linear list. I also wonder about the practicality of exploiting these types of issues. However, other ways exist to make these functions spend too much time. They have a few suggestions to work around this. First, try to make all operations O(1). In reality, this isn't really possible, though. So, having hard upper bounds on iteration counts or run time limits is the way to go. Another option is having custom gas metered contexts that will eventually expire. Using custom gas meters has its own consequences, such as forcing rollbacks on the state if this happens because of the potential for partial operations. Overall, a good and post on gas meters going wrong in Cosmos.
Analysis Summary
# Vulnerability: Cosmos SDK Unmetered Logic in BeginBlock/EndBlock
## CVE Details
- CVE ID: Not specifically assigned to the architectural flaw; however, a prominent case study relates to the **Cosmos Hub Interchain Security (ICS)** vulnerability identified in January 2024.
- CVSS Score: N/A (Architectural design flaw often categorized as **Major/High** in audits).
- CWE: [CWE-400: Uncontrolled Resource Consumption](https://cwe.mitre.org/data/definitions/400.html)
## Affected Systems
- Products: Cosmos SDK-based blockchains.
- Versions: All versions utilizing standard `BeginBlock` and `EndBlock` handlers without manual gas metering.
- Configurations: Chains that process dynamic lists or perform heavy computation within these hooks, specifically:
- `x/ccv/provider/keeper/relay.go` (Interchain Security)
- `x/ccv/consumer/keeper/distribution.go`
## Vulnerability Description
In the Cosmos SDK, `BeginBlock` and `EndBlock` functions run before and after transaction processing in every block. By design, these functions are not subject to the standard gas metering that limits user transactions. If a developer implements logic with linear time complexity ($O(n)$) that depends on user-influenced data (e.g., a list of addresses to prune or rewards to distribute), an attacker can artificially inflate these lists through spam. Because there is no gas limit to halt execution, the computation can exceed the block time, leading to consensus failures.
## Exploitation
- Status: **PoC available** (Validated through local experimental simulation by Oak Security).
- Complexity: **Low** to **Medium** (Triggered by bloating state/lists via standard transactions).
- Attack Vector: **Network** (Spamming messages such as `AssignConsumerKey` to increase list sizes).
## Impact
- Confidentiality: None
- Integrity: Medium (Potential for partial state operations if manual rollbacks aren't handled).
- Availability: **High** (Consensus timeouts, missed validator voting windows, slashing of honest validators, and full chain halts).
## Remediation
### Patches
- Developers must audit their specific implementations of `BeginBlock` and `EndBlock`. For the Interchain Security case, updates were pushed following the June 2023 Oak Security audit.
### Workarounds
- **Strict Iteration Limits:** Implement hard upper bounds on the number of items processed per block.
- **Complexity Optimization:** Ensure all operations in unmetered hooks are $O(1)$ where possible.
- **Custom Gas Metering:** Manually wrap logic in a custom gas-metered context that expires, though this requires careful handling of state rollbacks.
## Detection
- **Indicators of Compromise:** Unusual increases in block times, frequent consensus "round" increments, and sudden increases in validator slashing for "downtime" despite no network outages.
- **Detection Methods:** Monitor the size of internal lists and the execution duration of the `BeginBlocker` and `EndBlocker` functions in node logs.
## References
- Oak Security Blog: hxxps://medium.com/oak-security/the-hidden-risks-of-cosmos-sdk-unmetered-functions-861bf76078d0
- Cosmos Interchain Security Audit (June 2023): hxxps://github.com/oak-security/audit-reports/blob/main/Cosmos/2023-06-23%20Audit%20Report%20-%20Cosmos%20Interchain%20Security%20v1.0.pdf
- Cosmos SDK Documentation: hxxps://docs.cosmos.network/