February 2, 2018
Smart contracts can remove some of the security concerns of a trusted, third party but then immediately introduce a completely new set of potential vulnerabilities.
Common development practices used in software may not be entirely applicable in the smart contract construct. There are new classes of attacks to consider when building out potentially complex or modular smart contracts.
Race conditions may occur in other forms of software systems, but smart contracts require special consideration.
A race condition is a circumstance where event A is dependent upon the completion of event B, but may not control the completion of event B, nor fully understand when event B is actually complete.
This can cause all sorts of undesired or unexpected behaviors, and can be exploited by an attacker to cause a smart contract to behave abnormally.
Reentrancy is an interesting example of a race condition based attack. Essentially, an attacker can create another, new, evil smart contract (let’s call it
Contract E) and call the vulnerable contract (
Contract V). This can create a circular loop in the processing which exploits the functionality of the vulnerable contract (
Contract V). bountyone.io has good write-up on this exact topic.
Due to the decentralized nature of most blockchains, using timestamps, or time base calculations can be troublesome. This is a vulnerability more applicable to blockchains than previous computer systems where it may have been more of a functional consideration than a security one. Any contract which is required to get information external to the blockchain software need special consideration.
Buffer overflows are a common vulnerability in any software built using platforms where manual memory management is required. Smart contracts can take this type of vulnerability to a whole new level.
Smart contracts can be developed which allow callers to increase or decrease the value of a variable. Increasing the variable past the max (or min) value of the variable type will cause the value to “circle back” and reset which can be exploited by an attacker.
Here is a list of 20 potential overflow/underflow vulnerabilities in Solidity: https://github.com/ethereum/solidity/issues/796#issuecomment-253578925
Denial of Service
Because many smart contracts are immutable, a logical flow in the contract could be exploited in perpetuity. Consider a contract which, upon an invalid call, attempts to revert to a previous state involving another external contract. If a caller is able to control the logic within that external contract, the original revision may never be able to complete, rendering the contract effectively locked.
This is just a short (and high level) list of potential vulnerabilities within smart contracts. Detailed analysis is REQUIRED for any smart contract which handles any amount of assets. Always use a third party to audit and employ rigorous testing before production deployment.