Full Report
Substrate is a framework for building application specific blockchains within the Polkadot ecosystem written in Rust. Each new chain inherits the security of the main chain, which is why it's a good choice. It's used by Manta, Band protocol and many others. Since the substrate layer requires a lot of code to be written, there are common security issues that occur. Some of these are covered in this article. Some of these, such as insecure randomness, are the same on other chains so I won't cover these in my notes. Substrate requires a model for charging for the usage of storage. If the rental rate for the space isn't expensive enough then it's possible to make the system sluggish. In particular, hackers should check that the gas costs are corresponding to the storage that was used. There is a similar issue for Insufficient Benchmarking on external calls as well. The second interesting issue is an arbitrary decoding vulnerability. When passing in data, if it can decode to anything, then a highly nested structure can cause performance issues. Cross Consensus Messaging (XCM) is a mechanism for communicating with different substrate systems, similar to IBC in Cosmos. If the actions being used in this sink are not carefully sanitized and considered then arbitrary Transact instructions could be executed. In theory, this would lead to unauthorized actions or system disruptions. The other issues that are mentioned are integer related issues, replay attacks from not checking nonces and various other things. My biggest takeaway is that this is functionality very similar to Cosmos but in a different ecosystem. I wish actual findings from substrate blockchain audits were referenced here though.
Analysis Summary
# Vulnerability: Critical Design Flaws in Substrate-based Blockchains
## CVE Details
- **CVE ID**: N/A (The article describes architectural patterns and common weaknesses rather than a single tracked CVE).
- **CVSS Score**: Estimated 7.5 - 9.8 (High to Critical depending on the specific vulnerability implemented).
- **CWE**: CWE-20 (Improper Input Validation), CWE-400 (Uncontrolled Resource Consumption), CWE-338 (Use of Cryptographically Weak PRNG).
## Affected Systems
- **Products**: Substrate Blockchain Framework.
- **Versions**: Various (Dependent on specific pallet implementations).
- **Configurations**: Blockchains utilizing the `Randomness Collective Flip` pallet, XCM (Cross-Consensus Messaging) without origin validation, and pallets with missing benchmarking or saturating math.
## Vulnerability Description
The article outlines several critical technical flaws inherent in the Substrate/Rust development ecosystem:
1. **Insecure Randomness**: Use of the `Randomness Collective Flip` pallet relies on previous block hashes (81 blocks). This is deterministic and susceptible to manipulation by block producers/validators.
2. **Unbounded Decoding**: Use of the `Decode` trait on types like `Vec<T>` without size limits. Maliciously crafted, highly nested, or massive data structures can cause memory exhaustion or CPU spikes during the decoding phase.
3. **Storage Exhaustion & Benchmarking**: If gas costs (weights) do not accurately reflect the disk I/O and storage space used, attackers can spam the state trie at low cost, leading to "sluggish" nodes and permanent bloat.
4. **XCM Arbitrary Execution**: Improperly sanitized XCM "sinks" allow the `Transact` instruction to be executed from untrusted origins, potentially allowing unauthorized calls to sensitive pallet functions.
5. **Arithmetic Errors**: Lack of `saturating_` or `checked_` math in Rust logic leads to integer overflows/underflows, which in a blockchain context can result in unauthorized minting or balance corruption.
## Exploitation
- **Status**: PoC logic identified in the article; common patterns frequently found in audits.
- **Complexity**: Medium to High (Requires understanding of Substrate's SCALE encoding and XCM instruction sets).
- **Attack Vector**: Network (Remote execution via transactions or cross-chain messages).
## Impact
- **Confidentiality**: Low
- **Integrity**: Critical (Potential for unauthorized transactions and logic bypass).
- **Availability**: High (DoS via storage exhaustion or unbounded resource consumption).
## Remediation
### Patches
- **Substrate Framework**: Ensure integration with the latest versions of the Substrate repository (Parity Technologies).
- **BABE Pallet**: Migrating from `Collective Flip` to `Pallet BABE` for VRF-based randomness.
### Workarounds
- **Safe Decoding**: Use `DecodeLimit` or `MaxEncodedLen` to enforce bounds on incoming data.
- **Saturating Math**: Replace all standard operators (`+`, `-`, `*`) with `saturating_add`, `saturating_sub`, etc.
- **XCM Barriers**: Implement strict adherence to the `AllowUnpaidExecutionFrom` and `AllowKnownQueryResponses` barriers.
## Detection
- **Indicators of Compromise**: Rapid increase in blockchain state size; nodes failing to keep up with block production; unexpected calls from the `Parachain` or `Relay` origins.
- **Detection Tools**:
- **Substrate-sidewinder**: For static analysis.
- **Benchmarking**: Use the `frame-benchmarking` CLI to identify weight-to-actual-cost discrepancies.
## References
- **Vendor Advisory**: hxxps://forum[.]polkadot[.]network/t/common-vulnerabilities-in-substrate-polkadot-development/3938
- **Documentation**: hxxps://docs[.]substrate[.]io/main-terrace/build/runtime-development/secure-coding/
- **Framework Source**: hxxps://github[.]com/paritytech/polkadot-sdk