EOS platform has created much hype in the blockchain community by offering a high transaction rate and providing an operating system like architecture for managing distributed resources. Companies and developers are quickly adopting and moving on to build their next dApps on EOS. Since the smart contracts supported by EOS are converted to web assembly, C++ was the language of choice for developing them.

The ecosystem around EOS is still in its early stages, and the tools, technologies, and practices around developing EOS smart contracts have yet to mature. Smart contracts generally involve the transfer of funds, thus it becomes very important to audit them extensively before they become live. The unique design of EOS and its choice of language (C++) makes the audit process of the smart contracts fundamentally different from other popular platforms like Ethereum. Through this article, we intend to list various language and platform based parameters that must be checked during the smart contract audit process for EOS.

EOS Smart Contracts Security Audit — A Comprehensive Guide

1. Dangling pointers and references, proper memory management

These parameters about EOS contracts are the consequence of using C++ to write smart contracts. While programming with C++, we need to manage allocation and deallocation of memory for the instances that are created dynamically during runtime. Dangling pointers (and references) refer to the memory locations that were previously held by some objects which are now deallocated. This part of the memory may be reallocated to some other object, which can cause the original pointer (or reference) to now point at this reallocated data.

This can cause unpredictability in our application. Usage of dangling pointers inside code can at very least cause undesirable behavior, in some cases corruption of data, and can even be exploited maliciously. Dangling pointers can be targeted by adding malicious code to the memory locations pointed to by them, so that during their further use in application logic, malicious data is introduced in the system and may cause undesirable behavior.

Thanks for reading. Also, do check out our next blog posts on EOS Smart Contracts

2. Checking for Buffer Overflow

Buffer overflow is a flaw where while writing data to a buffer, the program exceeds the limit of the buffer and overwrites the memory locations adjacent to the buffer boundaries. This can happen when we have an assumption on the size of inputs to the buffer for a certain operation. If the input happens to be larger than our assumed value, it may start to overwrite on the memory locations adjacent to the memory locations of the buffer.

Exploiting buffer overflow is a known security vulnerability. The basic idea is to provide inputs with malicious data that are large enough to cause a buffer overflow and overwrite other variables of the application logic. This way, by influencing data in the input, the attacker can try to influence the program into producing desirable outputs. Further, if poorly designed smart contract code is made publicly available, it will give attackers an ample opportunity to analyze the structure and perform buffer overflows on the vulnerable parts of the contract.

3. Custom Dispatcher and mapping of actions to roles and permissions

In EOS, the publicly available executable functions of the smart contract are called actions. Each action can be called upon by the accounts interacting with the smart contract. These actions may have some permission level associated with them, which can be easily handled while using the default permissions (owner or active). Mapping of actions to the permissions is handled by the dispatcher, which is the first entry point inside the contract. It is specified using EOSIO_DISPATCH macro.

However, many times we may need to add custom permissions in our application. In that case, we need to write a custom dispatcher, that maps the actions to the custom permissions. A poorly mapped action to a permission level may leave the smart contract code open to malicious actors, that can have unauthorized access to the actions. Proper permissions and authorization management inside operation is a general practice that must be followed in developing smart contracts on any platform.

4. Dependence of transferring funds on predictable outcomes, handling random numbers

This is especially true for betting games type contracts that depend on some condition like the value of some random number to decide the winner and transfer funds to the winner account. In a well-known incident, attackers made an identical contract and were able to generate the winning numbers beforehand. This led them to place correct bets each time and transferred funds to themselves.

It should be noted that it is not possible to obtain non-deterministic values in a deterministic environment. Blockchain frameworks like EOS have to be deterministic in nature as a transaction on one EOS node must be identical on every other node in order to ensure consensus. However, there are ways to generate random numbers as explained here.

5. Handling persistent data on RAM, usage of multi-index table

EOS provides the RAM as the resource for fast access and persisting application data. The access to the RAM is provided by the EOS library in the form of multi-index tables. These tables are capable of storing any kind of data specified through a struct object passed while instantiating them. These tables are generally used to store important contract-specific data like balances or whitelisted accounts.

So in the absence of proper checking during arithmetic operations over this data can cause the values to overflow, an hence result in data loss. This can especially be dangerous if the records being corrupted points to the balances of accounts. As a good practice, always use the asset structure provided by the eosio library. It overloads all the basic arithmetic operators and its usage is preferred over extracting balances and then performing operations.

6. Transfer error prompts

The EOS smart contracts provide the functionality to respond to notifications from other contracts. Thus when there is no proper checking on the context of notifications, a fake notification can be designed to trigger the action on the victim contract. In a famous betting game hack, fake notifications were used to trigger transfer funds action of the contract, and the attackers were able to transfer funds to themselves by providing fake notifications to the victim contract. To avoid this, we should check all the parameters from the notifications and respond only to those notifications that are of interest to the current contract.

7.  Using loops in the smart contract actions

While using loops of C++ like for or while, one must be very deligent that the allowed NET and CPU time doesn’t limit. For eg. in an action “distributeFunds”, using 100s of inline actions of “transfer” would lead to breaking of it and transaction will fail. Hence, actions like these should be avoided as much as possible. Please note, updating table values in for loop is less vulnerable than calling inline actions multiple times.

8. Inter communication of contracts

While using loops of C++ like for or while, one must be very deligent that the allowed NET and CPU time doesn’t limit. For eg. in an action “distributeFunds”, using 100s of inline actions of “transfer” would lead to breaking of it and transaction will fail. Hence, actions like these should be avoided as much as possible. Please note, updating table values in for loop is less vulnerable than calling inline actions multiple times.

Conclusion

In this article, we covered some general hotspot areas inside the EOS smart contracts that must be inspected while auditing them. This list is by no means exhaustive, and we will continue to discover and index more vulnerable areas about EOS smart contracts as it matures. Further speaking, it is highly advisable to get your contracts audited by trusted 3rd party companies offering auditing services. At QuillAudits, we have a proven track record of developing and auditing smart contracts on major blockchain platforms.

Thanks for reading. Hopefully, this guide has been useful to you and will help you to understand the common hotspots and pitfalls in EOS smart contracts Audit.

Part 3 — Understanding fundamental concepts for writing dApps on EOS.

Part 4- Analysing EOS standard token contract.

Part 5- Develop a basic crowd sale application with EOS.

Part 6- EOS for high-performance dApps — Games on EOS!

Launch your blockchain project with Quillhash: https://quillhash.typeform.com/to/KQ5Hhm

Thanks for reading. Also, do check out our earlier blog posts.