Full Report
A while ago, Jacob reported a bug named p2p storms that ICF deemed wasn't worth fixing. If the blocks are 20mb each and the mempool is full, then the chain liveness are severely impacted. The author claims that this affects all chains and can be done cheaply with lots of large MsgUpdateClientArchway, it's a p2p networking problem rather than a block size thing; it's important to have the capability to have large. blocks for CosmWasm contract uploads. Overall, an interesting bug with a real world showcase.
Analysis Summary
# Vulnerability: Cosmos SDK P2P Storms (Resource Exhaustion)
## CVE Details
- **CVE ID:** Not yet assigned (Currently tracks as a known issue within the Interchain Foundation (ICF) ecosystem).
- **CVSS Score:** Estimated 7.5 (High)
- **CWE:** CWE-400: Uncontrolled Resource Consumption ("Resource Exhaustion")
## Affected Systems
- **Products:** Cosmos SDK-based blockchains, CometBFT/Tendermint core.
- **Versions:** Broadly affects versions utilizing the default P2P networking stack where large block sizes are enabled.
- **Configurations:** Chains configured with large block size limits (e.g., 20MB+) and heavy mempool traffic. Specifically noted to affect chains supporting large `MsgUpdateClient` or CosmWasm contract uploads.
## Vulnerability Description
The flaw stems from how the Cosmos P2P networking layer handles the propagation of large data packets across the gossip network. When the mempool is saturated and the block size is large (e.g., 20MB), the peer-to-peer gossip protocol becomes overwhelmed by the volume of data it must synchronize across nodes.
This creates a "P2P Storm" where network bandwidth and CPU resources are consumed by overhead and re-transmissions rather than consensus. This effectively stalls chain liveness because validators cannot synchronize state or reach consensus fast enough to keep up with the block production window.
## Exploitation
- **Status:** Exploited in the wild (Verified by Jacob Gadikian against Sentinel DVPN and other Cosmos-based chains).
- **Complexity:** Low
- **Attack Vector:** Network (Remote)
## Impact
- **Confidentiality:** None
- **Integrity:** None
- **Availability:** High (Can lead to total chain halt/denial of service).
## Remediation
### Patches
- At the time of the report, the Interchain Foundation (ICF) had deemed the issue "not worth fixing," implying no official consensus-level patch is standard. However, individual chains like Sentinel have begun implementing custom logic to mitigate the storm.
### Workarounds
- **Reduce Max Block Size:** Decreasing the maximum block size significantly reduces the gossip load.
- **Mempool Size Limits:** Lowering the maximum number of transactions allowed in the mempool.
- **Rate Limiting:** Implementing stricter P2P peer rate limiting and message filtering.
- **Validator-only Sentry Nodes:** Obfuscating validator nodes to prevent direct P2P saturation.
## Detection
- **Indicators of compromise:**
- Rapid spikes in P2P bandwidth consumption.
- Large numbers of `MsgUpdateClient` or `MsgStoreCode` (CosmWasm) transactions in the mempool.
- Sudden increase in block times or failing consensus rounds.
- **Detection methods and tools:**
- Prometheus/Grafana monitoring of CometBFT P2P metrics (e.g., `p2p_peers`, `p2p_message_receive_bytes_total`).
- Monitoring mempool depth and transaction size distribution.
## References
- **Twitter Thread:** hxxps[://]x[.]com/Senpai_Gideon/status/1792797141901140223
- **Proof of Concept Demonstration:** hxxps[://]video[.]twimg[.]com/ext_tw_video/1792796947251941376/pu/pl/w7Y0s3JpXXZHpzCz[.]m3u8?tag=12&v=16b