Smart contracts are “smart” because their programs are self-executable, derived solely from written code. But how smart are they really?
As with other software, the program's strength depends on the quality of its source code. After conducting numerous smart contract audits across a multitude of use cases, we’ve compiled a few common–and sometimes fatal–vulnerabilities that you’ll want to remember in order to prevent some not-so-smart contract bugs.
Examples of vulnerabilities
Miner manipulation vulnerabilities
In these types of vulnerabilities, a malicious miner manipulates variables outside the smart contract's execution to exploit the system in their favor.
Timestamp dependence
Believe it or not, a transaction's timestamp can be influenced by miners to some extent. Because there’s no centralized clock that all the nodes in a network adhere to (when a block is successfully mined on a node, the timestamp is set locally), there’s typically a tolerated drift, or variance, when new blocks are added.
While that variance is not usually a cause for concern, that opening may still allow a miner to manipulate the block timestamp to achieve a more favorable outcome.
Warning on using block.number to keep time
Block number dependence is not so much a vulnerability as it is a loose workaround or alternative to using block.timestamp. Though the block.number function itself can’t be manipulated by design; it’s not always a reliable variable when calculating time that’s far in the future, because the time it takes to mine a block can vary and change.
Let’s say, for example, one of the rules on a smart contract is to transfer assets from User A to User B in 365 days, and it takes, on average, 10 minutes to mine a block. One might try to create a rule with block.number to transfer those assets when the block.number variable reaches 52,560 (365 days x 24 hours/day x 60 minutes/day / 10 minutes of mining/block).
But! If the average time to mine a block changes for any reason (e.g., if nodes leave the network, reducing the difficulty and the time required to mine blocks), the asset transfer may occur too soon or too late.
How do you know whether to use it or not? Depending on the smart contract's use case, block.number may be the right workaround if time sensitivity isn’t a concern or if you’re looking at a relatively short-term contract length. However, if the smart contract needs to execute at a specific date and time–especially if it’s well into the future–then the lack of accuracy is enough of a reason to look for another solution.
Transaction-ordering / Front-running dependence
A race condition vulnerability that occurs when code depends on the order of the transactions submitted to it.
Because the order of the transactions is known before they’re executed on and added to a block, this may provide too much transparency for some decentralized markets. For example, if this type of vulnerability were applied to the stock market, you could see who is buying and selling shares before it happens!
Depending on the protocol of the chain you’re working in, this ordering may result in an unbalanced and unfair market. On Ethereum, for example, a malicious miner could pay more gas to prioritize their transaction over another’s so that theirs is processed first–opening the door for bad actors to cut the line.
If your smart contract relies on transactions to execute in the order they’re received, make sure you build in safeguards so that bad actors can’t manipulate that order.
Integer overflow and underflow
An overflow occurs when arithmetic operations cause an output that’s larger than the maximum size allocated to it; conversely, an underflow occurs when the output is smaller than the minimum size.
A classic example of integer overflow occurs when a car’s odometer cannot record mileage beyond 999999 (6 digits). When that happens, the car’s odometer inaccurately represents this new seven-figure number (1,000,000) as the last six digits (000000), even though the actual mileage is 1000000 (7 digits long).
Because you want data to be represented as accurately as possible, failure to account for overflows and underflows would result in inaccurate data and unintended outputs from the smart contract.
When you’re reviewing thousands of lines of code, it can be easy to overlook these vulnerabilities, but it’s crucial to account for them. One way to be fully confident that your code is safe from overflows and underflows is to use Formal Verification to apply mathematical proofs that calculate whether those computations could ever exist.
Access and privilege control vulnerability
Because of the nature of public blockchains, access and privilege controls may not be necessary; anyone can read or write blocks to the chain. However, as blockchain technology evolves and expands, permissioned and private chains will require greater consideration and more robust access controls.
If a blockchain has no access controls configured, it’s public by default, which may cause issues for stakeholders. If you need to control which nodes can access the network or restrict access to blocks that may contain sensitive information, you should be aware of the access you’re granting.
DDoS (Distributed Denial of Service) attacks
Although blockchains are often touted as a solution to mitigate traditional DDoS attacks, they can still fall victim. If protective measures aren’t built into the chain protocol itself, blockchain nodes are vulnerable to being flooded with traffic from maliciously coded smart contracts. This would cause all of the network’s processing resources to divert to handling the overload, which in turn would render the network unusable.
While no major DDoS attack on a blockchain network has been reported yet, TRON disclosed a vulnerability earlier this year that put the entire network at risk.
Reentrancy attacks
Attacks by way of smart contracts aren’t always external; a malicious contract may call back into the calling contract before the first function is finished.
In other words, a malicious smart contract is coded into the victim smart contract so that when the victim contract executes for the first time, the malicious contract can interrupt the first execution by either calling the victim contract again (with a fallback function) before its completion or by running a whole new function altogether. It’s considered reentrancy because it re-enters another call to the contract before the initial call finishes.
This kind of loophole allows for malicious users/contract writers to overtake the original intention of the victim’s smart contract and game the system in their favor–creating a sort of internal attack. A well-known example of this vulnerability was the DAO hack, which led to a hard fork between the Ethereum and Ethereum Classic chains.
Becoming bug-free and achieving functional correctness with Formal Verification
While we won’t discuss it in detail here, if you need a primer or refresher on Formal Verification, our Introduction to Formal Verification may be helpful.
The concept of Formal Verification isn’t new (it’s been used for mission-critical projects like the NASA Mars Rover and drone technology), but the team here at CertiK uses cutting-edge technology to help protect blockchains and smart contracts. By representing every possible variable in a smart contract with mathematical proofs, the source code can be proven or disproven to ensure it was built exactly as intended.
Various tools can be used to check for errors, but the limitation is that they often miss things (and you can’t decipher whether the lack of finding something means that it’s safe or that the tool missed something). Without comprehensive mathematical proofs, evidence of full functional correctness is not possible.
It’s important to invest in security, particularly with blockchains. Once a smart contract is deployed, changes are difficult, and transactions are permanent, which is both the beauty and the risk of blockchain technology. That said, the CertiK team can provide a comprehensive audit of your smart contracts and give you the peace of mind that they’re as secure as possible before deployment.
Learn more about our audit process and how we can help.
Don’t just look for bugs–prove that they cannot exist.
