A Survey on EOSIO Systems Security: Vulnerability, Attack, and Mitigation

BY KEYHUNTER 05.03.2025
A Survey on EOSIO Systems Security: Vulnerability, Attack, and Mitigation

EOSIO, as one of the most representative blockchain 3.0 platforms, involves lots of new features, e.g., delegated proof of stake consensus algorithm and updatable smart contracts, enabling a much higher transaction per second and the prosperous decentralized applications (DApps) ecosystem. According to the statistics, it has reached nearly 18 billion USD, taking the third place of the whole cryptocurrency market, following Bitcoin and Ethereum. Loopholes, however, are hiding in the shadows. EOSBet, a famous gambling DApp, was attacked twice within a month and lost more than 1 million USD. No existing work has surveyed the EOSIO from a security researcher’s perspective. To fill this gap, in this paper, we collected all occurred attack events against EOSIO, and systematically studied their root causes, i.e., vulnerabilities lurked in all relying components for EOSIO, as well as the corresponding attacks and mitigations. We also summarized some best practices for DApp developers, EOSIO official team, and security researchers for future directions.

CCS Concepts: • Security and privacy → Distributed systems security; • General and reference → Surveys and overviews.

Additional Key Words and Phrases: EOSIO, Blockchain, Smart Contract

ACM Reference Format: Ningyu He, Haoyu Wang, Lei Wu, Xiapu Luo, Yao Guo, and Xiangqun Chen. 2022. A Survey on EOSIO Systems Security: Vulnerability, Attack, and Mitigation. 1, 1 (July 2022), 34 pages. https://doi.org/10.1145/nnnnnnn.nnnnnnn

1 INTRODUCTION

When Satoshi Nakamoto released the whitepaper of Bitcoin in 2008 [74], cryptocurrency has become one of the most popular topics in the area of computer science and finance. By the time of writing, Bitcoin is still the leading one, far beyond the second place, of numerous kind of cryptocurrencies, with the market capitalization of more than 134 Billion USD [8]. As the Bitcoin’s follower, Ethereum, who takes the second place, brings in the concept of smart contract, in which the programmer are allowed to interact with the data stored in blockchain by the means of programmable script.

However, these early-staged implementation has a fatal limitation: a poor scalability. The Bitcoin can only theoretically support 27 transactions per second (TPS) at most [9]; while Ethereum can achieve approximately 50 TPS [35]. Moreover, the Ethereum is still in ongoing development, the frequently adding and deleting of features in its programming language lead to developers’ unfamiliarity and unexpected behaviors. Lots of works and technical blogs [26, 83, 96] have indicated kinds of vulnerabilities existed in Ethereum smart contract and its virtual machine. At the meanwhile, several works [51, 52, 101, 104] focused on the vulnerabilities’ detection in a variety of ways. Therefore, lots of competitors emerged, one of the most influential products is EOSIO [45].

EOSIO launched its initial coin offering [50] (ICO) in 2017, and raised more than 4 billion USD which is the largest one ever [90]. Its main purpose is to be Ethereum alternative, thus EOSIO improves upon intrinsic shortcomings of Ethereum, e.g., scalability and speed. According to a EOSIO network monitor [11], it have reached around 4,000 TPS in history, which is tenfolds higher than Ethereum’s and Bitcoin’s. Except for its high TPS, EOSIO choose C++ as its smart contract language, and WebAssembly [7] (Wasm) as its target language executed in EOS Virtual Machine (EOS VM). Though Wasm is relatively younger than C++, it is endorsed by several influential technical companies. Additionally, Wasm aims to execute at native speed by taking advantage of common hardware capabilities. Therefore, the high TPS and efficiency of EOSIO smart contract bring EOSIO a huge success. For example, EOSIO has successfully surpassed Ethereum in decentralized applications (DApp) transactions just three months after its launch in June 2018 [37], and further increased dozens of times after another several months.

However, due to developer’s unfamiliarity of developing EOSIO smart contract, kinds of vulnerabilities has been introduced. For example, EOSBet [27], one of the most famous gambling DApp in EOSIO, have been attacked twice in just one month [40, 76] due to the lack of verification of two different key arguments in transaction respectively. In these two attacks, EOSBet has lost nearly 190 thousand of EOS, which was more than 1 million USD according to the exchange rate then. According to several blockchain security companies’ blogs, forums and official announcements, we have counted 113 attacks against several kinds of vulnerabilities just within one year after EOSIO launched.

Except for vulnerabilities imported in smart contract by developers, EOS VM, the stack-based machine used to execute smart contract, also has some inherent flaws that are used by some attackers [31, 77]. Additionally, EOSIO utilizes an energy-saved and efficient consensus algorithm, delegated proof-of-stake [17] (DPoS), as its consensus algorithm instead of widely-used proof-of-work (PoW). Lots of novel characteristics are introduced by DPoS and EOSIO new transaction model, e.g., block producer, action and transaction. Some of them can result in unexpected behaviors which are not considered by the official.

This paper makes the following contributions:

  1. We present the first systematic exposition of the vulnerabilities in EOSIO ecosystem, ranging from smart contracts to the consensus algorithm. The hierarchical presentation of vulnerabilities clearly illustrates the direct causes of these loopholes which can be referenced by DApp developers and security researchers;
  2. We comprehensively survey all existing attack events against all vulnerabilities, as well as their direct consequence, attack tactics and corresponding countermeasures;
  3. We well study all existing mitigations on identifying vulnerabilities or happened attack events, including program analysis and transaction analysis. Moreover, we propose a set of best practices for developers to avoid financial losses as much as possible.

The whole paper is organized as follows: §2 depicts the whole picture of EOSIO blockchain platform and performs a comparison between Ethereum smart contract and EOSIO’s on bytecode level. Then, §3 and §4 introduce the underlying principles of vulnerabilities and attacks, which are collected from several well-known sources, like [70, 83, 96], respectively. Moreover, §5 summarizes best practices and current existing work whose targets are all against security issues of EOSIO smart contracts. Finally, we propose some best practices in §6 to DApp developers, EOSIO official team and security researchers according to the observation from the previous three sections, and §7 summarizes existing related work from several perspectives.

2 BACKGROUND

In this section, we will briefly introduce the key concepts related to the EOSIO platform to facilitate the understanding of this work. As shown in Fig 1, according to their dependency, we divide the components of EOSIO into five categories: application layer, data layer, consensus layer, network layer and environment. In application layer, EOS Virtual Machine (EOS VM) runs on each nodes in EOSIO, responsible for executing smart contracts that are invoked by other accounts. All these interactions between accounts are achieved by transactions (and actions) and notifications with their carrying permission, which are all packaged and stored at data layer. Moreover, as we mentioned in §1, EOSIO significantly outperforms Bitcoin and Ethereum in terms of Transactions Per Second (TPS) and prospers in DApp ecosystem. This is mainly due to its adopted consensus algorithm and resource system, which will be introduced in consensus layer. As an auxiliary component, environment offers several key technology to serve the above three layers, e.g., a user-friendly front-end interface and a trustworthy back-end serve can support the application layer. Last, blocks, as the basic unit that will be propagated across all nodes, are created and relayed in the network layer, played as infrastructure for all these stuff. For full details, readers can refer to the official documents (e.g., [44]) for a systematic illustration.

2.1 Application Layer

2.1.1 Account. Instead of the unreadable and random-like address adopted by Ethereum and Bitcoin to identify accounts, the account name of EOSIO is composed of at most 12 characters. And EOSIO requires the uniqueness of all accounts’ name to avoid identity impersonation. Moreover, unlike the distinction between External Owned Account (EOA) and smart contract in Ethereum [34], there is only one type of account in EOSIO, which can be regarded as a normal account and a smart contract simultaneously.

2.1.2 Smart Contract. As we mentioned in §2.1.1, an account can be seen as a smart contract sometimes. To be specific, if a piece of compiled smart contract bytecode is stored in one’s account, the account performs pre-defined logic written in the contract once it is invoked. Similar to one’s balance, EOSIO smart contract is updatable. The mutability of smart contract not only allows the developers to patch loopholes, but also introduces users’ concern that the unexpected behaviors may happen if they are not aware of the update. EOSIO smart contracts are written in C++, and compiled to WebAssembly (Wasm) [7], a well-structured assembly-like language.

2.1.3 EOS VM. As with Ethereum, EOSIO adopts a virtual machine to execute the smart contracts, named as EOSIO Virtual Machine (EOS VM), embedded in each nodes of EOSIO. EOS VM is a stack-based machine, i.e., all the operands and operators are pushed into the popped from a stack. Moreover, EOSIO supports another two sections: local and global, to share data within a function or across functions, respectively. Furthermore, EOS VM provides a random-accessible linear array called memory to store the unbounded and non-permanent data, e.g., a string that will be printed out.

2.2 Data Layer

Block is the basic unit that will be appended to EOSIO blockchain, the decentralized ledger. A block consists of two key components: block header and block body. The former one contains some meta data, e.g., block height, timestamp; the latter one is composed of transactions. In EOSIO, a transaction can be further divided into actions, in which it carried the invoker’s permission to authorize behaviors. Moreover, EOSIO introduces a notification mechanism that enables message delivering between accounts.

2.2.1 Transaction & Action. Each transaction in EOSIO is packed as a transaction instance. Moreover, each transaction is composed of two components: transaction header and a list of action instances. To be specific, the former one contains meta data, like transaction ID and its belonged block ID prefix; the latter one is a string of linked action instances. Each action instance corresponds to an atomic behavior in EOSIO, consisting of four components: account name, action name, action data, and authorization list. The first three respectively represent the invoked account name, function name and concrete data to invoke the function; while the last one is the invoker’s authorization to the current action instance (detailed in §2.2.3).

Moreover, actions can be created explicitly to invoke a smart contract, or generated implicitly as the side effect alongside other actions. Thus, actions are divided into two categories: explicit action and implicit (inline) action. Explicit action is represented as an outermost and isolated action instance, like the action #1 and the action #n in Fig. 2; and implicit action shares the same context to which its parent action belongs. For example, the inline action action #n.1 is the side effect when executing action #n, thus these two actions share an action instance.

Note that both explicit and implicit actions are executed in synchronous mechanism, it is necessary, however, for EOSIO to support the asynchronous execution because a single transaction has to be finished within 30 ms [68] to avoid the congestion. Therefore, EOSIO allows an action to invoke a deferred action as the action #n.2 in Fig. 2. The deferred action will be embedded in a future transaction after the delay period set by its initiator.

Similar to the Ethereum’s rollback mechanism, any failure within a transaction will lead to its reversion, but it will not affect other already on-chained transactions. For example, if action #n.1 failed, the whole transaction #1 will be reverted; if action #n.2 in transaction #m fails, the transaction #m will be reverted but the transaction #1 will keep everything intact.

2.2.2 Notification. EOSIO imports the notification mechanism to enable message delivering between accounts. Specifically, a smart contract can initiate a notification by require_recipient( ) within a function. For example, the native token, dubbed EOS, is issued by an official account: eosio.token, in which it maintains a balance table for all holders. Therefore, as depicted in Fig. 3, if the user intends to transfer EOS to the dapp, he has to request the transfer function in eosio.token firstly to update the corresponding rows of balance table. Once the update finished, eosio.token will notify both of the payer and payee that the following logic can be performed continously (step 2 and 3). Received notification is handled by a fixed entry-point function: apply, which must be implemented by each smart contract and will be detailed in §2.2.4.

2.2.3 Permission System. In EOSIO, each account is associated with a permission system. An concrete example, the permission system of alice, is shown in Fig. 4. Specifically, the permission system follows hierarchical structure, and there are always two default permissions: owner and active. Specifically, owner sits at the root of the permission hierarchy and correspond to one’s highest permission; and active permission can do anything except changing the key associated with current account (controlled by the owner). Following the hierarchical structure, accounts are allowed to create new permissions, like the transfer under the active permission. Moreover, each permission is linked to an authority table, in which it specifies the threshold that should be satisfied at least to perform the action which requires the permission, and the others’ permission with their weights. Within each action instance (see §2.2.1), the initiator has to designate the carrying permission and signed the action by the corresponding key of the permission. For example, if a function requires transfer@alice, the action with either transfer@bob or active@charlie could satisfy the requirement, as both of them are authorized by transfer@alice.

Table 1. The meaning of arguments in apply under two circumstances.

Direct InvocationNotification
receiverThe callee
codeCurrent account
actionThe invoked function’s name

2.2.4 Dispatcher – An Example. In EOSIO, there is a dispatcher, named apply, responsible for handling the received action invocations and notifications. Moreover, its name and signature is fixed as shown in Listing 1. apply takes three arguments as input: receiver, code, and action. The receiver is the recipient; the action is the function’s name; and the code indicates in which the code is actually executed. The concrete meanings of these three arguments under two circumstances: direct invocation or notification are shown in Table 1. Therefore, if Listing 1 is the apply instance of dapp in Fig. 3, it only accepts the notification from official account eosio.token (where code is eosio.token) or a direct invocation (where code is itself).

void apply(uint64_t receiver, uint64_t code, uint64_t action) {
    if (code == _self || code == N(eosio.token)) {
        switch(action) {
            // dispatches to corresponding function
        }
    }
}

Listing 1. An example of apply in EOSIO smart contract. Note that this is vulnerable to the fake EOS vulnerability.

2.3 Consensus Layer

2.3.1 DPoS & Block Producer. The correctness of blockchain is essential for user’s financial security, thus how to guarantee the data consistency across such a distributed system is the overriding issue for cryptocurrency. Unlike Bitcoin and Ethereum, who utilizes traditional energy-consumed PoW consensus algorithm, EOSIO adopts delegated proof of stake (DPoS), a more efficient and environment-friendly one. Specifically, all the accounts in EOSIO network are entitled to delegate their rights to someone whom they entirely believe in, and only the top 21 trusted accounts are called block producer (BP). These 21 BPs are responsible for constructing blocks in turn. Once a BP is on duty, it is responsible for verifying the correctness of the signature and executing actions in the transaction. After all the actions are executed without any failure, the transaction will be appended to a new block’s body, which will then be broadcasted and validated by other nodes. While the block is validated by a supermajority of BPs (> (\frac{2}{3})), the block, including the transactions inside, will be irreversible. Note that the order of producing blocks is negotiated in advance among those BPs, thus competitive mining process is unnecessary and deprecated in DPoS.

2.3.2 Resource Model. Similarly to other blockchain platforms, executing transactions and constructing blocks charges fee from initiators to prevent denial of service attack. However, EOSIO does not calculate fee by length of data (e.g., Bitcoin) [53] or executed opcode (e.g., Ethereum) [39], it introduces three key concepts to represent resources: NET, CPU and RAM. Specifically, all these three types of resources are provided by BPs, i.e., transaction validators and block constructors. NET is used to measure the amount of data that can be sent within a transaction, and CPU limits the maximum execution time of a transaction. These two are jointly called bandwidth. RAM limits

1 The N() in L2 is the native string encoding function implemented by EOSIO, which will not be explained in the following.

Table 2. Comparison between EOSIO smart contract and Ethereum’s

Ethereum smart contractEOSIO smart contract
Source LanguageSolidityC++
Target LanguageEVM Bytecode / EWasm (future)WebAssembly
Amount of Instructions154172
Type of Instructions–Float number related instructions; Typecast related instructions; br_table instruction;
Control Flow ComplexitySimpleComplicated
Running EnvironmentEthereum VMEOS VM
Data Structure in VMstack, memory, storagestack, local, global, memory, table

the maximum space that can be occupied to store permanent data(^2). An account can exchange NET and CPU by mortgaging EOS, but has to buy RAM due to its scarcity. Users are free to use the bandwidth resources as long as there are available ones, i.e., not be mortgaged by any other accounts. However, the price of mortgaging bandwidth resources fluctuates, depending on how much EOS are staked in total.

2.4 Network Layer

EOSIO also adopts P2P network to broadcast messages among the nodes distributed across the world. In this work, however, we mainly focus on the vulnerabilities existed in its above layers: application, data and consensus layers. Therefore, the network layer is a black box for us in this work. For more details about EOSIO network layer, e.g., block and transaction propagation and P2P protocol, please refer to the official documentation ([44]).

2.5 Environment

For all these layers mentioned above, it is necessary for them to be supported by some infrastructures. To be specific, for DApp developers on the application layer, they need to provide user-friendly front-end interfaces and back-end servers to perform the corresponding functionalities, e.g., random number generation. For items stored in the data layer, they have to be indexed in a multi-indexed database to conduct an efficient CRUD(^3) operations. Last, the underlying cryptography plays an important role for the consensus layer, like validating transactions and blocks. The reason of we separate the environment from the EOSIO’s architecture is attacks against components of environment can be easily addressed out of the EOSIO’s scope, which consequently leading to a modular and clear abstraction for EOSIO.

2.6 Comparison between EOSIO smart contract and Ethereum’s

Table 2 depicts the comparison between EOSIO smart contract and Ethereum’s. As we can see, though they are written in different programming languages (Solidity and C++), they both store the bytecode in the blockchain. Interestingly, Ethereum also plans to support EWasm ([49]), a variant of WebAssembly, in the future upgrade. Compared with Ethereum smart contract, EOSIO’s is more complicated in both quantity and variety of bytecode instructions. Specifically, Ethereum contains 32 PUSH, 16 DUP and SWAP to handle different length of data. EOSIO, however, pre-defines four types of data, i.e., i32, i64, f32 and f64, to abstract all data structure, including string and struct. Moreover, EOSIO supports float number related instructions and type conversion between above four

(^2)The data is stored in the BPs’ RAM to accelerate the retrieving process.

(^3)Create, Read, Update, and Delete

LocationsVulnerabilityCauses
Application Layerasset overflowUndefined behavior
Insufficient code verificationImproper validation
Relayable notificationFlawed implementation
Predictable random numberExternal dependency
Re-entrancyInadequate authentication
Inadequate permission verification
Freely invoked inline actionInsufficient transaction validation
Unchecked statusImproper business model
Arbitrarily rollback
Exploitation on blacklist
Top-priority deferred transactionImproper execution model
Data LayerDeficient resource systemEOSIO Design
Assignable resource payer
Abnormal parser
Private key compromising
Consensus Layer
Environment

Fig. 5. The vulnerabilities in EOSIO, and their corresponding locations and causes.

data types, which are not supported in Ethereum. And br_table, which enables multi forks simultaneously like switch-case, plays an important role in the control flow of EOSIO smart contract. According to [55], the authors claimed that: generally, EOSIO smart contracts is more complicated than Ethereum’s in terms of control flow.

Except for the distinction located in smart contracts, their running environments, i.e., virtual machines, also exist some differences. In Ethereum, both operands and operators are pushed into and popped from the stack. The memory and storage, which adopt simple key-value structure, are used to store temporary and permanent data, respectively. In EOSIO, the stack plays an identical role. Whether the data is stored in the local or global depends on whether the data can be shared between functions. The memory and table structures are totally different with the Ethereum VM. Specifically, the former one can be randomly accessible, which is implemented by store and load instructions with pointers; the latter one is used to CRUD permanent data, which is achieved by a multi-index database integrated into the EOSIO (see §2.5). Consequently, EOSIO is more complicated than Ethereum in both smart contract and running environment level.

3 VULNERABILITY

To cover as many types of vulnerabilities related to EOSIO smart contract as possible, we did a comprehensive investigation from different sources, like blogs from security companies [83, 96], forums [13, 14] and official announcements related to attack events. After collecting all these information, we manually audit the source code or reverse engineering the WebAssembly bytecode (if the source code is not available) of the corresponding smart contracts. Consequently, in this section, we discussed all the observed vulnerabilities in the wild, as well as the root cause and the status, i.e., it has already eliminated by official or still open and can be avoided by best practice. To ease the reference, we adopt notation $V_i$ to refer to each vulnerabilities (as shown in Fig. 5). In the following, we discuss the vulnerabilities according to its belonged layers.

3.1 Vulnerabilities in Application Layer

3.1.1 asset Overflow ($V_1$). This type of vulnerability is first observed in [28]. Specifically, EOSIO adopts a user-defined struct, named asset, to encapsulate a certain amount of token. With the uniform definition of asset and its overloaded operators, developers can easily present a piece of money (token) and implement arithmetic operations on the token with the same symbol. The source code of official implementation of multiplication on asset is shown in Listing 2

asset & operator*=(int64_t a) {
    eosio_assert(a == 0 || (amount * a) / a == amount, "multiplication overflow or underflow");
    eosio_assert(-max_amount <= amount, "multiplication underflow");
    eosio_assert(amount <= max_amount, "multiplication overflow");
    amount *= a;
    return *this;
}

Listing 2. The source code of implementation of multiplication on asset.

As we can see from L2, it performs a standard implementation of overflow/underflow verification. Then, it returns the result after guaranteeing it ranges from the minimum and maximum limit. However, any source code, including the library functions, will be compiled to Wasm bytecode format (see §2.1.2) to execute on EOS VM. Listing 3 shows the corresponding Wasm bytecode of L2.

(call $eosio_assert
  (i32.const 1) // always true
  (i32.const 224) // "multiplication overflow or underflow")

Listing 3. The compiled (with -O3 optimization) Wasm bytecode corresponding to L2 in Listing 2.

We can see that the first argument of assertion is always true, which invalidates the overflow/underflow check. The reason behind is when both operands are signed integers, the result of overflowed multiplication is undefined [88]. Coincidently, some compilers with high-level optimization (like -O3 in EOSIO) will generate unexpected behaviors encountering undefined result. The overflow of asset could result in the unexpected consumption of any type of tokens. As this vulnerability is imported by the mis-implementation of official library contract, it is patched timely [3].

3.1.2 Insufficient code verification ($V_2$). Fake EOS is the most representative vulnerability in EOSIO, as it is introduced by the mis-implemented apply function (see §2.2.4). Hence, lots of contracts were attacked against this vulnerability [40, 57, 87]. Specifically, its appearance is due to the neglect or improper verification of argument code in apply function, which can be further divided into two circumstances:

  1. No validation on the code field. Suppose an account (e.g., eosio.token1) also issued a token called EOS by duplicating the official contract in eosio.token. The malicious user could request the transfer in eosio.token1 to transfer the fake EOS to a victim, like the process depicted in Fig. 3. If the victim’s apply happens not to check if the value in code is eosio.token, the official one, the victim would be deceived by a worthless and faked EOS token.
  2. Even if developers update the apply as Listing 1, which only accepts the direct invocation or a notification from eosio.token, it is still vulnerable. The malicious user could call the transfer function directly, in which way the balance for both of them will not be updated. The invocation will then be forwarded to the transfer function to perform the following logic.

Therefore, the vulnerability can only be prevented by a thorough verification on the code. Specifically, if a contract intends to accept EOS token, both of action == transfer and code == eosio.token have to be guaranteed simultaneously or it will be affected by such a vulnerability.

3.1.3 Relayable notification ($V_3$). As we mentioned in §2.2.2, EOSIO innovatively introduces the notification mechanism. However, the unfamiliarity of contract developers with the new mechanism may introduce a vulnerability that is named as fake receipt vulnerability, which is observed in [76]. In order to enhance the flexibility of notification mechanism, EOSIO enables the rebroadcast of notifications. But to avoid the way like man-in-the-middle attack [20], EOSIO forbids the modifications of rebroadcasted notification. To this end, if two malicious accounts coordinate and transfer EOS token to each other, once the payee received the notification from eosio.token, he can immediately relay the notification to the victim. As both the code and action are valid, the victim may mistakenly believe that he is the beneficiary of the transfer. As with the Fake EOS vulnerability, this one can also be prevented by a careful arguments’ validation, i.e., examining the to field of the transfer notification to distinguish the actual beneficiary.

3.1.4 Predictable Random Number ($V_4$). Gambling DApps plays an important role in EOSIO’s ecosystem [58]. They heavily depend on pseudo-random number generation (PRNG), which can be used to determine which player wins the final jackpot. However, current types of pure on-chained PRNG are all flawed, and are attacked several times [62, 75, 93]. Specifically, EOSIO’s PRNG relies on some blockchain state as seeds, e.g., current_time, transaction_id, and tapos_block_num. The variables like the first two, however, are either accessible to everyone or deterministic, which leads to the predictable result of PRNG. As for the tapos_block_num, it refers to the height of the reference block (typically the previous block). Taking advantage of the deferred transaction, a future block’s reference block seems unpredictable and is properly used as a seed of PRNG. It turns out, however, that the variable is predictable regardless of how many times the delay transactions invoked (detailed in §4.1.4). To mitigate this vulnerability, on the one hand, developers can follow a more secure PRNG prototype proposed by Daniel Larimer [61]; on the other hand, they can utilize (de)centralized oracles [18, 43, 67] or even its back-end server to generate random number.

3.1.5 Re-entrancy ($V_5$). Re-entrancy is a well-studied vulnerability in Ethereum smart contracts [33, 89], attacks against this vulnerability are firstly observed in [71]. As with Ethereum, this vulnerability is because the order between checking key variable and performing sensitive operations (like function call) is reversed. Taking transferring tokens as an example, as shown in Fig. 3, after both of the participants are notified by the token issuer (step 2 and 3), they can perform following logics within their transfer function (if they have). Intuitively, the order of above operations is: the payer is notified and the notification is handled by the transfer, then the same processes performed in payee’s contract. However, EOSIO processes all the notifications in advance, which brings in a vacuum period for the payer whose money is spent but the response is not conducted in transfer. So once the malicious payee receives notifications, he could immediately inlined invoke the function again and repeat the above process. To mitigate this vulnerability, developers should always guarantee updating status before performing operations.

3.1.6 Inadequate Permission Verification ($V_6$). As we mentioned in §2.2.3, every account has its related permission hierarchical structure, and each action instance would carry an authority list. Therefore, once the function in which it performs sensitive operations, e.g., transferring money and updating permanent data, but not conduct a permission validation, it may be abused by malicious users without authorization. To be specific, there are three authority validating library functions in EOSIO:

  • require_auth(usr): it validates if the action carries the permission that is equivalent to usr’s active permission;

Moreover, its name and signature is fixed as shown in Listing 1. apply takes three arguments as input: receiver, code, and action. The receiver is the recipient; the action is the function’s name; and the code indicates in which the code is actually executed. The concrete meanings of these three arguments under two circumstances: direct invocation or notification are shown in Table 1. Therefore, if Listing 1 is the apply instance of dapp in Fig. 3, it only accepts the notification from official account eosio.token (where code is eosio.token) or a direct invocation (where code is itself).

Useful information for enthusiasts:

Contact me via Telegram: @ExploitDarlenePRO