5 Common Vulnerabilities in Smart Contract

Blockchain smart contracts are very difficult to operate properly. Store of value, transparency, and immutability are three key attributes that are essential for smart contracts to work effectively. However, these attributes also make many smart contracts a security risk and are the “prey” targeted by many cybercriminals. Even if targeted attacks are not carried out, there are many cases where financial resources are detained and companies lose money due to errors and security holes in smart contracts.

1.Integer arithmetic error

A common occurrence is integer arithmetic error. Smart contracts often represent numbers as integers due to the lack of floating point support. In addition, this is also a fairly common case in financial software, using integers to represent values ​​requires reducing to small units, for the most accuracy. A simple example would be expressing the value in cents instead of dollars, since we cannot express $0.50. In fact, smart contracts often round to a maximum of 18 decimal places as many tokens are supported.

One problem that developers today know quite well is the fact that integers can overflow. Like the mileage counter on a car, when the system registers the maximum value, the counter will immediately return to the original value. Similarly, performing the subtraction of two unsigned integers 4 and 3 will cause an underflow, so the result is a very large number. Developers are often aware of this potential vulnerability and prevent it by using a secure math library, such as the product of Open Zeppelin.

However, what does not seem to be appreciated by developers is that integer arithmetic in general can lead to inaccurate results when errors are encountered in the calculation process. In particular, the order of operations is very important. A typical case is calculating percentages. For example, to calculate 25%, we usually divide by 100 and multiply by 25. Let’s say we want to calculate 25% of 80 using an integer. Expressing this calculation will be 80/100*25 which will result in zero, due to rounding error. The simple mistake here is to do the division before the multiplication.

Of course, this is just a very simple case but it is often encountered with alarming frequency.

2. Block gas limit vulnerability

The block gas limit is how the Ethereum platform uses to ensure blocks do not grow too large. Simply means the maximum amount of gas in a block that transactions in the block can consume. In other words, if a transaction consumes too much gas, that transaction will never fit in a block and thus the transaction will never be executed.

This can create a common vulnerability: If data is stored in arrays of non-fixed size and then accessed through loops over these arrays, the transaction can run out of gas and get a refund. This happens as the number of elements in the array increases, but is more common in production than in testing. In fact, the test data is often smaller which makes this problem dangerous as contracts with these vulnerabilities often pass unit tests and seem to work well with a small number of users. However, users fail only when a project gains momentum and the amount of data increases. Non-cancellation of bonuses occurs if such loops are used to push payouts.

3. Missing parameter or precondition checks

One of the simplest programming mistakes we often make is not validating the arguments of a function or forgetting to perform the necessary checks for a valid operation. This usually includes not checking the address parameter of the address parameter or for example, not verifying that the user has sufficient token balance to conduct a certain transaction. Another good example is access control, where only a certain type of user is allowed to call a function but this check is never performed.

These errors are often the result of a sloppy design process. You should have a detailed log of all functions, stating the parameters, prerequisites, and operations to be performed. Sticking to design best practices, such as Checks Effects Interactions can also help prevent this type of vulnerability.

4. Frontrunning Vulnerability

Frontrunning is probably the most difficult to prevent of the 5 common vulnerabilities with Smart Contracts. Frontrunning can be defined as placing an order to buy an unconfirmed trade. This is the result of blockchain’s transparent nature. All unconfirmed transactions will show up in the mempool before they are included in a block by miners. Interested parties can simply follow trades they like and place an order to buy them by paying higher transaction fees. This can be automated easily and has become quite common in decentralized finance applications.

It is not easy to solve this problem, often needing refactoring or redesigning smart contracts to fix it.

5. Simple logic error

Some of the problems mentioned above are smart contract-specific errors while others are common to all types of programming. However, by far the most common type of problem is simple logical mistakes of smart contracts. These errors can be due to typographical errors, misinterpretation of specifications, or more serious programming errors. Logical errors tend to be related to the security and functionality of smart contracts.

However, what these errors have in common is that they can only be discovered if the auditor fully understands the code base and has insight into the project’s intended functionality and contract specification. It is these kinds of problems that are the reason why smart contract audits take a long time, are not cheap, and require experienced auditors.

Conclusion

Smart contract programming has undergone many changes over the past few years. Countless serious cases of money loss have made projects aware of the importance of security. We’ve found that developers have become more aware of common vulnerabilities and frequently use tools, such as static code analysis and symbolic execution to automatically scan their code. If you need to audit the entire smart contract for your Blockchain project, contact CyStack to consult the Smart Contract Audit 2.0 service – tested by security experts with 8 years of security testing experience and 3 years working with Blockchain projects at home and abroad.

If you’d like to understand how to improve your approach to cyber security, contact my team.