5 Common Smart Contract Vulnerabilities

Smart contracts are only as smart as the code (or coder) behind them. The strength of the program is dictated by the quality of the source code and in this article, we’re going to take you through some of the most common vulnerabilities and bugs which can affect smart contracts.

What is a Smart Contract?

Smart contracts are programs stored on a blockchain that run when predetermined conditions are met. They are typically used to automate the execution of an agreement so that all participants can be sure of the outcome immediately, without an intermediary’s involvement. Smart contracts can also automate a workflow, triggering the next action when predetermined conditions are met.

Common Vulnerabilities

Reentrancy Attacks

We covered Reentrancy Attacks in one of our recent blog posts, so we won’t go into too much detail here. In the simplest terms, a reentrancy attack occurs between two smart contracts, when a function makes an external call to another untrusted contract. Then the untrusted contract makes a recursive call back to the original function in an attempt to drain funds.

A simple example of a reentrancy attack is when a contract carries out internal accounting with a balance variable and exposes a withdrawal function. If the vulnerable contract transfers funds before it sets the balance to zero an attacker can recursively call the withdraw function repeatedly and drain the whole contract of funds.

Arithmetic Error of Integer (Integer Overflow and Underflow)

Another common vulnerability can be integer overflow and underflow. An overflow occurs when the arithmetic operations result in an output that is larger than the maximum size allowed, and as you may have guessed, an underflow does the opposite- causes an output that is smaller than the minimum allowed size.

An example of integer overflow that you may have seen in regular life is on a car’s odometer. These usually go up to 6 digits, showing a maximum of 999999 miles, and then once it hits the 1,00,000 miles point, the odometer shows 000000. This results in an inaccurate output which shows the car as having done zero miles when in fact it has done one million.

This is a very simple real-world example, but it can also be a common flaw in smart contracts that is overlooked. A great way to counter this is to use Formal Verification to apply mathematical proofs that calculate whether computations can exist.

Front-Running Dependence or Transaction-Ordering

The nature of many blockchains, including Ethereum, implies the combination of external calls to other contracts and a large number of users which makes it possible for bad actors to determine Solidity vulnerabilities by racing code execution for their benefit.

Before a transaction is added to the block, it first goes to the mempool where everyone knows what will occur. A malicious miner could then pay higher gas to prioritize their transaction over another’s so that theirs is processed first–opening the door for bad actors to cut the line.

It is almost impossible to fully protect against front-running because it is a feature of blockchain, but two possible ways are to implement batch auctions or to use a pre-commit scheme.

Tx.Origin Authentication

Tx-origin is a global variable used on the Ethereum blockchain. It runs through the entire process and returns the address of the account that sent the transaction. When this variable is used for smart contract authentication it creates a huge risk for phishing cyberattacks. It has become more of a rarity to come across this issue as developers become more experienced, but as a rule, do not use tx.origin use msg. sender instead.

Vulnerabilities of the Block Gas Limit

The Ethereum blockchain uses a block gas limit which ensures that the block does not grow too large. The amount of gas that the transactions contained in these blocks can use is limited, meaning if a transaction consumes too much gas it will never execute.

This can lead to a common vulnerability which most commonly occurs during production. If the data is stored in resizable arrays and then accessed through loops over these arrays, the transaction can run out of gas and get a refund. These types of vulnerabilities can be particularly dangerous as contracts with the issue will often pass Unit Tests and work fine during testing with small numbers of users.

Conclusion

These are just five of the most common pitfalls developers can fall into when working with smart contracts, but there are many, many more. The best way to ensure that your smart contracts are as safe and secure as they can be is to get a smart contract audit.

HYDN provides detailed, manual smart contract audits from a team of experienced cybersecurity and blockchain specialists. If you’re interested in getting an audit, head over to our site today and fill in a Request a Quote form and one of our team will come back to you as soon as possible.

‍