Polkadot Top Ten
The Polkadot Top 10 is a document designed to understand in detail the top ten most common and specific security vulnerabilities that can happen in Polkadot SDK development. The goal is to help you understand what are the risks, how they can affect a Substrate-based blockchain, and how to protect against them. Knowing about these vulnerabilities can help make Substrate and Polkadot ecosystem safer for everyone.
The Top Ten vulnerabilities are in constant evolution, new vulnerabilities may be added to the list, and existing ones may be moved to the Polkadot Base as they become less common.
📄️ Insufficient Benchmarking
Benchmarking can be a difficult task. Incorrect or missing benchmarking can lead to overweight blocks, causing network congestion and affecting the overall performance of the blockchain. This typically occurs when the computational complexity or storage access is underestimated, resulting in inaccurately assigned weights for extrinsics.
📄️ Runtime Misconfiguration
Even if a pallet is correctly implemented, if its configuration and integration in the runtime is not properly defined, unexpected behavior can occur. This issue happen commonly with systems composed from multiple pallets and runtime modules such as XCM or bridges.
📄️ Insecure Randomness
On-chain randomness on any public, decentralized, and deterministic system like a blockchain is difficult. The use of weak cryptographic algorithms or insecure randomness in the system can compromise the integrity of critical functionalities, allowing attackers to predict or manipulate outcomes of features that rely on secure randomness.
📄️ Unsafe Math
Incorrect arithmetic operations in the codebase can lead to integer overflows/underflows, divisions by zero, conversion truncation/overflow, and incorrect end results. These issues can be exploited by attackers to manipulate calculations and gain an unfair advantage, primarily involving the use of primitive arithmetic operations.
📄️ Reachable Panics
Panics are dangerous because they can lead to the unintended termination of the runtime, potentially jeopardizing the availability of the entire chain. For example, if a panic occurs in an on_initialize hook, it could disrupt the entire block processing, posing a serious threat to the chain's stability.
📄️ Storage Exhaustion
Your chain can run out of storage! Inadequate charging mechanisms for on-chain storage allow users to occupy space without paying appropriate deposit fees. This loophole can be exploited by malicious actors to fill up the blockchain storage cheaply, affecting network performance and making it unsustainable to run a node.
📄️ Replay Issues
Replay issues, most commonly arising from unsigned extrinsics, can lead to spamming and, in certain scenarios, double-spending attacks. This often occurs when nonces are not managed correctly, enabling transactions to be replayed.
📄️ Outdated Crates
Dependencies can become a nightmare! Using outdated or known vulnerable components, such as pallets or libraries, in a Substrate runtime can expose the system to a broad range of security risks and exploits.
📄️ Data Mishandling
Overview
📄️ Inconsistent Error Handling
Errors and exceptions need to be handled consistently to avoid creating attack vectors in critical parts of the system. In scenarios where processing a collection of items involves handling one or more failures, the entire batch could fail. This situation can be exploited by an attacker aiming to block execution, especially if the processing is occurring in a privileged extrinsic like a hook.