Each standard vulnerability is made possible by one of the features of smart contracts. We unite types of vulnerabilities into groups by the corresponding features. We unite several groups into the same class if their features have the same nature. Here is the list of classes and groups with some standard vulnerabilities categorized by this classification.
Vulnerabilities caused by blockchain nature of the system.
Miner assembles block and thus can influence its contents (included transactions, their order, other block parameters).
- Front-running / transaction reordering (SWC-114, DASP-7, SP-10)
- Timestamp manipulation (SWC-116, DASP-8, SP-12)
- Random with blockhash (SWC-120, DASP-6, SP-6)
- Transaction censorship (link)
Ethereum allows smart contracts to interact with each other. The following vulnerabilities are based on the fact that one contract cannot rely on the behaviour of an arbitrary contract.
- Unchecked low-level call (SWC-104, DASP-4, SP-9)
- Reentrancy (SWC-107, DASP-1, SP-1)
- DoS with revert (SWC-113, SP-11)
- DoS with selfdestruct (DASP-5)
Blockchains require some payment for a transaction execution. In Ethereum, fee is proportional to the computational complexity of the code being executed. Vulnerabilities of this category are based on the fact that the amount of gas available for the transaction is limited.
- Infinite loops (SWC-129)
- Transfer provides too little gas: receiving contract has only 2300 gas for its fallback function, which is not enough for external call, writing to storage, etc
Ethereum allows accounts to send messages to each other. This data is converted to function calls according to specific rules.
- Signature collisions: two different functions may have the same signature
- Short address attack (DASP-9, SP-8)
Generally, all ETH transfers invoke contract’s fallback function and, thus, can be detected by the contract. However, there are several ways of ETH transfer that cannot be detected by the contract. Mostly, they are described in (SP-3).
- Ether transfer with selfdestruct: contract cannot handle incoming Ether sent by
selfdestructfunction - Ether transfer with mining: contract cannot handle incoming Ether sent as a reward for block mining
- Pre-sent Ether: contract cannot handle Ether sent to its address prior to the deploy
Vulnerabilities caused by the insecure use of Solidity language (or any other language used for smart contracts).
Solidity operates only with integer numbers and does not check the correctness of arithmetic operations.
In some cases, state variables can point to an incorrect storage slot.
- Uninitialized storage pointer (SWC-109, SP-14)
- Delegatecall and storage layout (SWC-112, SP-4)
- Overlap attack (SWC-124)
Some features of Solidity can lead to overcomplicated control flow graph.
- Multiple inheritance (SWC-125)
- Arbitrary jump with function type variable (SWC-127)
- Assembly return in constructor: this trick tampers with standard deployment process; as a result, actually deployed bytecode has little in common with the source code
Vulnerabilities caused by mistakes in the model (architecture) of the system.
Vulnerabilities connected with the insufficient or incorrect authorization implementation (DASP-2).
- Generous contracts (SWC-105)
- Suicidal contracts (SWC-106)
- Authorization with tx.origin (SWC-115, SP-16)
- Constructor name (SWC-118, SP-13)
Ethereum was designed as a trustless system. However, many smart contracts are built so that users have to trust the owner/administrator. This part of the system can be compromised or used in an undesirable way.
- Overpowered owner (SP-11 - see 3. Owner operations)
- Vulnerable off-chain server: giving too much power to back-end can lead to undesired consequences if the off-chain server is hacked
In Ethereum, smart contracts bytecode and values of state variables are available for everyone. However, some developers use it to store sensitive data.
Issues with the economic model of the system.
- Voting issues: wrong voting logic that can lead to undesired effects
- Tokenomics issues: undesired users behaviour caused by economic conjuncture of the token
- Game Theory issues: undesired users behaviour caused by their feasible benefits
The following registries were addressed in the classification.