├── LICENSE └── README.md /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2018 SmartDec 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Classification of smart contract vulnerabilities 2 | 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. 3 | Here is the list of classes and groups with some standard vulnerabilities categorized by this classification. 4 | 5 | ## Blockchain 6 | Vulnerabilities caused by blockchain nature of the system. 7 | 8 | ### Block content manipulation 9 | Miner assembles block and thus can influence its contents (included transactions, their order, other block parameters). 10 | - Front-running / transaction reordering ([SWC-114](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-114), [DASP-7](https://dasp.co/#item-7), [SP-10](https://blog.sigmaprime.io/solidity-security.html#SP-10)) 11 | - Timestamp manipulation ([SWC-116](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-116), [DASP-8](https://dasp.co/#item-8), [SP-12](https://blog.sigmaprime.io/solidity-security.html#SP-12)) 12 | - Random with blockhash ([SWC-120](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-120), [DASP-6](https://dasp.co/#item-6), [SP-6](https://blog.sigmaprime.io/solidity-security.html#SP-6)) 13 | - Transaction censorship ([link](https://blog.ethereum.org/2015/06/06/the-problem-of-censorship/)) 14 | 15 | ### Contract interaction 16 | 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. 17 | - Unchecked low-level call ([SWC-104](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-104), [DASP-4](https://dasp.co/#item-4), [SP-9](https://blog.sigmaprime.io/solidity-security.html#SP-9)) 18 | - Reentrancy ([SWC-107](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-107), [DASP-1](https://dasp.co/#item-1), [SP-1](https://blog.sigmaprime.io/solidity-security.html#SP-1)) 19 | - DoS with revert ([SWC-113](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-113), [SP-11](https://blog.sigmaprime.io/solidity-security.html#SP-11)) 20 | - DoS with selfdestruct ([DASP-5](https://dasp.co/#item-5)) 21 | 22 | ### Gas limitations 23 | 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. 24 | - Infinite loops ([SWC-129](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-129)) 25 | - 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 26 | 27 | ### Message structure 28 | Ethereum allows accounts to send messages to each other. This data is converted to function calls according to specific rules. 29 | - Signature collisions: two different functions may have the same signature 30 | - Short address attack ([DASP-9](https://dasp.co/#item-9), [SP-8](https://blog.sigmaprime.io/solidity-security.html#SP-8)) 31 | 32 | ### Ether transfer 33 | 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](https://blog.sigmaprime.io/solidity-security.html#SP-3)). 34 | - Ether transfer with selfdestruct: contract cannot handle incoming Ether sent by `selfdestruct` function 35 | - Ether transfer with mining: contract cannot handle incoming Ether sent as a reward for block mining 36 | - Pre-sent Ether: contract cannot handle Ether sent to its address prior to the deploy 37 | 38 | ## Language 39 | Vulnerabilities caused by the insecure use of Solidity language (or any other language used for smart contracts). 40 | 41 | ### Arithmetic 42 | Solidity operates only with integer numbers and does not check the correctness of arithmetic operations. 43 | - Over/underflow ([SWC-101](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-101), [DASP-3](https://dasp.co/#item-3), [SP-2](https://blog.sigmaprime.io/solidity-security.html#SP-2)) 44 | - Precision issues ([SP-15](https://blog.sigmaprime.io/solidity-security.html#SP-15)) 45 | 46 | ### Storage access 47 | In some cases, state variables can point to an incorrect storage slot. 48 | - Uninitialized storage pointer ([SWC-109](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-109), [SP-14](https://blog.sigmaprime.io/solidity-security.html#SP-14)) 49 | - Delegatecall and storage layout ([SWC-112](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-112), [SP-4](https://blog.sigmaprime.io/solidity-security.html#SP-4)) 50 | - Overlap attack ([SWC-124](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-124)) 51 | 52 | ### Internal control flow 53 | Some features of Solidity can lead to overcomplicated control flow graph. 54 | - Multiple inheritance ([SWC-125](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-125)) 55 | - Arbitrary jump with function type variable ([SWC-127](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-127)) 56 | - 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 57 | 58 | ## Model 59 | Vulnerabilities caused by mistakes in the model (architecture) of the system. 60 | 61 | ### Authorization 62 | Vulnerabilities connected with the insufficient or incorrect authorization implementation ([DASP-2](https://dasp.co/#item-2)). 63 | - Generous contracts ([SWC-105](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-105)) 64 | - Suicidal contracts ([SWC-106](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-106)) 65 | - Authorization with tx.origin ([SWC-115](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-115), [SP-16](https://blog.sigmaprime.io/solidity-security.html#SP-16)) 66 | - Constructor name ([SWC-118](https://smartcontractsecurity.github.io/SWC-registry/docs/SWC-118), [SP-13](https://blog.sigmaprime.io/solidity-security.html#SP-13)) 67 | 68 | ### Trust 69 | 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. 70 | - Overpowered owner ([SP-11](https://blog.sigmaprime.io/solidity-security.html#SP-11) - see 3. Owner operations) 71 | - Vulnerable off-chain server: giving too much power to back-end can lead to undesired consequences if the off-chain server is hacked 72 | 73 | ### Privacy 74 | In Ethereum, smart contracts bytecode and values of state variables are available for everyone. However, some developers use it to store sensitive data. 75 | 76 | ### Economy 77 | Issues with the economic model of the system. 78 | - Voting issues: wrong voting logic that can lead to undesired effects 79 | - Tokenomics issues: undesired users behaviour caused by economic conjuncture of the token 80 | - Game Theory issues: undesired users behaviour caused by their feasible benefits 81 | 82 | ## References 83 | 84 | The following registries were addressed in the classification. 85 | 86 | 1. Smart Contract Weakness Classification [Registry](https://smartcontractsecurity.github.io/SWC-registry/). 87 | 2. DASP [TOP-10](https://dasp.co/index.html). 88 | 3. Sigma Prime [Blog](https://blog.sigmaprime.io/solidity-security.html). --------------------------------------------------------------------------------