5 Need-to-Know Smart Contract Vulnerabilities
Web3 has seen a number of data breaches in the past, resulting in substantial financial loss with the most significant example being that of the The DAO Hack where US$ 150 million was lost in 2016.
Now, even if losses have declined in value since this attack, not addressing the topic of smart contract vulnerabilities would be a clear mistake.
Particularly, if it is our intention to inform budding Web3 developers of such attack scenarios if only to prevent such instances from reoccurring with their smart contracts.
5 Smart Contract Vulnerabilities — An Overview
Even if smart contracts are generally considered to be secure from attacks, there are times when hackers can ‘game’ the system to their advantage. In most cases, they use limitations of the language itself to perform unauthorized actions that result in financial gain.
For this series, we have focused solely on Ethereum smart contracts as written in Solidity, and vulnerabilities that are most likely to affect this blockchain.
So, here are 5 smart contract vulnerabilities that you should be aware of:
1: Reentrancy
This vulnerability allows hackers to reenter said smart contract and withdraw the entire balance from that contract to another. Before being able to do this, they have to make a one-time deposit in order to access the ‘withdraw’ method in the smart contract.
In order to prevent this vulnerability, you can use a reentrancy modifier, a mutex lock in your Solidity code or even use an intermediary escrow address.
You can read more about the reentrancy vulnerability at this link.
2: Integer Overflow/Underflow
The integer overflow/underflow vulnerability occurs when the resulting value of said action performed by a hacker is greater than the largest integer or lesser than the smallest integer possible in Solidity.
Usually, in causing such a value to be computed, hackers can either gain access to a large amount of tokens or perform some other unauthorized action that is dependent on the resulting value. As for the fixes, using the SafeMath smart contract or a Solidity compiler version greater than 0.8.0 should sidestep such a vulnerability.
You can read more about the Integer Overflow/ Underflow vulnerability at this link.
3: Access Control
If smart contract developers do not restrict certain actions to the owner of said contract, hackers can easily take advantage of the situation and drain funds from such a smart contract.
In order to do this, developers should be able to associate an Ethereum account as an owner and others as just users since this does not happen by default when writing and deploying a smart contract. Using a simple ‘require’ statement, a function modifier or even importing the Ownable and Access Control smart contracts should help with determining who is who.
You can read more about the Access Control vulnerability at this link.
4: Integer Division
Since Solidity does not offer the float or double data type, developers have to work with the uint or int data type only. As a result, the division operation returns a floor value that also results in an unacceptable loss in accuracy.
Since this translates to a financial loss, developers must be aware of such an error and adopt certain practices to sidestep this error as deftly as possible. Among the several fixes available, there are three ways accuracy can be improved: use a multiplier or floor division for signed integers. A complex but complete fix for this loss in accuracy involves using the ABDKMath64x64 library to represent floats.
You can read more about the integer division vulnerability at this link.
5: Frontrunning
With this type of vulnerability, certain transactions are moved up ahead and are added to a block before other transactions. Even if the latter were added to the ‘mempool’ much earlier, attackers can examine a time-sensitive transaction for valuable information and send one of their own instead.
As unfair as this is, there are instances where miners have been known to do this for their own financial benefit since most blockchain process transactions with higher gas fees first. In order to resolve this issue, you can use a transaction counter, set limits on gas fees or even use the submarine-send implementation to conceal your transactions.
You can read more about the front-running vulnerability at this link.
5 Key Takeaways
There’s a lot that one can gain from going through each of the vulnerabilities and fixes as a whole. In fact, you can learn much from these attack scenarios and which can translate into a decent list of best practices when it comes to smart contract development.
So, here are 5 simple takeaways:
- Staying aware of the latest vulnerabilities is key for successful smart contract development
- Smart contract bug classifications can help developers understand the types of vulnerabilities that exist for Ethereum smart contracts
- Understanding the nuances of Solidity and how the Ethereum blockchain works is imperative to sidestepping these vulnerabilities too
- Auditing or testing smart contracts rigorously for these vulnerabilities are vital to preventing such financial losses
- Fixes are usually available for each of these vulnerabilities, either incorporated into Solidity as features or that can imported from third-party smart contracts
That said, we’re building a developer-centric metaverse for you to learn, earn and get hired. Sign up to join the Lumos Metaverse Whitelist for exclusive access:
