-
Notifications
You must be signed in to change notification settings - Fork 133
List of Security Vulnerabilities
This page contains a comprehensive list of common smart contract security vulnerabilities, compiled from various sources. We use it as our reference list for security audits. In this page we only include basic information. Please click the links in sub-titles to see more details for each attack.
1. Re-Entrancy
happens when a contract A calls a malicious external contract B as part of its operation, which recursively calls A again. Consequently, a transaction that would normally be allowed to run only once, can be executed multiple times. To prevent this sort of attack, contract A must modify its internal state before calling B, in such a way as to detect and prevent re-entrancy.
Neither EVM nor Solidity don't provide builtin error reporting mechanisms for arithmetic overflow/underflow. Consequently, applications that do not check for this cases might contain security vulnerabilities.
Certain contracts behave erroneously when their EVM account contains ether. On other side, it is possible to send Ether to a contract forcibly, potentially rendering them inoperable.
4. Delegatecall
Solidity allows calling external contracts via DELEGATECALL opcode, which executes the code of an external contract in the persistent context of the present contract. Certain contracts perform DELEGATECALL calls using user-provided call data, which effectively gives full reflexion support to the user.
The default visibility for Solidity functions is public. If developers mistakenly ignore visibility specifiers, functions intended to be private may become externally accessible.
EVM does not have support for uncertainty/random number generation. Issue happens when contracts try to incorrectly simulate uncertainty, in a way that is in fact predictable and exploitable.
Issue happens when a contract delegates some of its functionality to external contracts whose address is either non-accessible to the users or can be changed by an unauthorized user. Therefore, the user that has control over the external contract address can use it to deploy malicious code.
The vulnerability appears in certain situations, when an external application calls the contract with user-provided data, that is not correctly validated.
In Solidity, functions there are multiple functions for calling an external contract or sending ether. Function transfer() reverts if transfer fails. However, functions call() and send() return false. The issue appears when programmers mistakenly expect call() and send() to revert, and do not check for return value.
It is possible to alter the order in which transactions execute in a block. Miners have total control over order in which transactions are processed. Users also may manipulate the order by setting high gas cost for transactions they wish to execute first. This poses a security risk when the outcome of two or more transactions depends on the order in which they were executed.
This is a broad category of attacks where users may leave a contract inoperable, temporarily or permanently.
Many contracts use block timestamps for various applications. Miners can slightly adjust them, which poses a security risk.
Prior to solidity v0.4.22, constructors were declared with the name equal to the name of the contract. If contract was changed during development without changing constructor name, constructor would become a regular function, with dangerous security consequences. Since Solidity v0.4.22 constructors are declared with keyword constructor, therefore issue does no longer exists.
Local variables within functions default to storage or memory depending on their type. Uninitialised local storage variables can point to other unexpected storage variables in the contract, leading to intentional (i.e. the developer intentionally puts them there to attack later) or unintentional vulnerabilities.