*&&&"$.

TU
*OUFSOBUJPOBM
$POGFSFODF
PO
4PGUXBSF
&OHJOFFSJOH
$PNQBOJPO
1SPDFFEJOHT
*$4&
$PNQBOJPO

Finding Concurrency Exploits on Smart Contracts

Yue Li
Peking University
[email protected]

1 contract EtherStore {
Abstract—Smart contracts have been widely used on Ethereum 2 address Owner ;
to enable business services across various application domains. 3 address Creator ;
4 mapping ( address = > uint256 ) balances ;
However, they are prone to different forms of security attacks 5 uint price ;
due to the dynamic and non-deterministic blockchain runtime 6 constructor () {
7 Owner = msg . sender ;
environment. In this work, we highlighted a general miner- 8 Creator = msg . sender ;
side type of exploit, called concurrency exploit, which attacks 9 }
smart contracts via generating malicious transaction sequences. 10 function foo ( address newOwner ) {
11 Owner = newOwner ;
Moreover, we designed a systematic algorithm to automatically 12 }
detect such exploits. In our preliminary evaluation, our approach 13 function bar () {
14 price = msg . value ;
managed to identify real vulnerabilities that cannot be detected 15 balances [ msg . sender ]+= price ;
by other tools in the literature. 16 // tranfer ether to owner
17 Owner . call . value ( price ) () ;
I. P ROBLEM A ND M OTIVATION 18 }
19 function upgrade ( address currentVersion ) {
Ethereum smart contracts are programs running on the 20 require ( msg . sender == Owner ) ;
21 // contrat currentversion code injection
blockchain to operate on Ethereum cryptocurrencies (i.e., 22 if (! currentVersion . delegatecall ( msg . data
) ) revert () ;
ether) and a set of persistent data (i.e., storage) [1]. Figure 1 23 }
shows a simple smart contract EtherStore with four storage 24 function destruct () {
25 require ( msg . sender == Creator )
variables and public functions except the constructor. External 26 // contract termination
27 selfdestruct ( Creator ) ;
accounts can use EtherStore by sending transactions to 28 } }
it. For example, a possible transaction data may look like Fig. 1: A motivating example of smart contract
a9059cbb7adee867ea91533879d083dd4ea81f0eee3a37e.
Specifically, the first four bytes a9059cbb point to the to directly manipulate storage of the current contract, e.g.,
hash of the foo function and the remaining bytes indicate Creator variable. In such cases, transactions of upgrade
the parameter used by foo, i.e., a 20-byte address. In the and destruct will produce uncertain scenarios of contract
execution of foo, the storage Owner will be updated to the destruction as in 2b, since Creator is used as a receiver
value passed from the transaction (line 11) and permanently of the remaining balance after the contract is cleared by the
stored on blockchain. Commonly, transactions submitted to selfdestruct API at line 27. The last case of 2d describes
the Ethereum network are ordered and packaged by a miner two transactions of bar from both Alice and Bob, where
node to optimize its own benefit, e.g., efficiently get the most different transaction orders will generate the same final storage
transaction fee. From this perspective, smart contracts can be values of balances no matter which one is executed first.
seen as a form of concurrent software since their executions While such concurrency enables normal miners to flexibly
are non-deterministic to transaction senders. make profits, it introduces great security threats to Ethereum.
We further explain such concurrency via Figure 2 based on In the aforementioned cases, only the last one is considered
the contract in Figure 1. Particularly, we describe four cases secure since the concurrent execution of transactions can com-
in this context to explain the transaction ordering and storage mute, e.g., different transaction orders will yield the same state
state transitions accordingly. In 2a, Alice first submitted a transition. The other three cases are all viewed as potentially
transaction to call the foo function, which sets the storage malicious, because attackers can employ specific sequence of
Owner to Alice. The following two transactions are from transactions to make undesired benefits, e.g., transfer money
Alice (call bar) and Bob (call foo). If Bob’s transaction to themselves, pollute the contract storage etc. In this work,
is ordered before Alice’s as in 2a, the call to bar will we refer such attacks as concurrency exploits and highlight an
lead to a money transfer to Bob (line 17) because Owner informal definition below. Given two accesses p and q from
has been updated to Bob. Otherwise, the money goes to two transactions tp and tq on storage sp and sq respectively,
Alice. Similarly in 2c, when Alice acquired the Owner, tp and tq can be exploited by a concurrency attack if
the order of calls to foo and upgrade from Bob will cause • p and q include exact one write and one read operation.
the sanity check at line 20 to fail or not. If the check is • sp and sq point to the same storage index.
passed, Bob would be able to further invoke a delegated • p and q are not mutually exclusive.
call (line 22), i.e., use a delegate contract (currentVersion • At least one security-critical operation is dependent on
in this case) to process the transaction input instead of the sp or sq (explained later).
current contract. In Ethereum, the delegate contract is allowed Our work aims to detect concurrency exploits in smart


¥
*&&& 
%0*
*$4&$PNQBOJPO

Authorized licensed use limited to: UNIVERSIDADE DE BRASILIA. Downloaded on June 25,2021 at 14:53:44 UTC from IEEE Xplore. Restrictions apply.
 6WDWH 6WDWH 6WDWH 6WDWH
2ZQHU B$ 2ZQHU B% 2ZQHU B$ 2ZQHU B%
$OLFH %RE $OLFH $OLFH %RE $OLFH
IRRQR IRRQR EDU FRQVWUDFWRU XSJUDGHFY GHVWUXFW

(a) 6WDWH
(b) 6WDWH
6WDWH 6WDWH
EDODQFHV>B$@ PVJYDOXH EDODQFHV>B$@ PVJYDOXH
2ZQHU B$ 2ZQHU B% EDODQFHV>B%@  EDODQFHV>B%@ PVJYDOXH
$OLFH %RE %RE $OLFH %RE
IRRQR IRRQR XSJUDGHFY EDU EDU

(c) (d)
Fig. 2: Possible transaction sequences and state transitions

contract [2]. Oyente identified transaction ordering bugs(TOD)

by checking if two different traces have different Ether flows, TABLE I: Comparison of Concurrency Exploits Detection
which is the sub-class of concurrency exploits [3] [4]. Securify Contract Address Type CESC Oyente Securify
share the same oracle of TOD with oyente [5]. At technical
0x352dbBA201aF66f98a47F2b280bFf45f9050DBf8  2 2 1
level, many techniques are used for analyzing security of smart 0x4ceae42d5fb3bd6956b2463fdd4a2209382d722c  1 0 1
contract: formal verification [6], symbolic execution [7] [3] [5] 0x33b44a1D150F3feAA40503aD20a75634Adc39B18  1 1 0
0xaf71b19e6292c6e1491ff3a54b3e63dbd41ef023  1 0 0
[8] and fuzzing [9]. 0xfa82f0a05b732deaf9ae17a945c65921c28b16dd 
 1 0 0
0x5aef06ec39e98c05201ee1e54b653c372ecb9cf3  2 0 2
II. A PPROACH 0x43efc486d1c7c5cb0193e409a73aa33786f5197c  2 0 2
Smart contract is compiled to bytecode that is executable 0xd43cbd8a74535327a8a196ea36cd44fc799ca289  1 0 0
0x7b47e1473F97040689812204113FF549b2E2C31B None 0 2 4
on the Ethereum virtual machine (EVM) [1]. We proposed
a systematic technique to automatically detect concurrency
exploits from EVM bytecode. Before we describe the details, price is determined while loading and it is not affected by
we first introduce security-critical operations as mentioned in concurrency, Step 3 removes SLOAD marking in line 15,17.
§I. Specifically, we focus on four EVM instructions, as below. Furthermore, if there are multiple writing to a storage index
in a branch, only the marking of last writing is retained.
• CALL that allows a contract to directly transfer ether to a
given address [10]. Step 3: Verifying Concurrency Exploits. Step 3 obtains
• CALLCODE / DELEGATECALL that enables another contract pairs of concurrent operations on storage from Step 2 to check
to process the current transaction [10]. concurrency exploits based on our definition in §I. Consider
• SELFDESTRUCT that terminates a contract, and transfers concurrency exploits in Figure 2a, the CALL instruction is
all remaining ether to the specified account [10]. dependent on Owner. Step 3 checks the pair of operations
Furthermore, as defined above, a security-critical operation on Owner(line 11, line 17 in Figure 1) that are not mutually
is dependent on a storage, if any of the following two exclusive by solving the path condition constraints of them.
conditions is satisfied. III. P RELIMINARY E VALUATION
• The storage as part of the parameters of security-critical
To evaluate our algorithm, we apply it to verify real-world
operations. Such as the concurrency exploits in Figure 2a, smart contracts from etherscan [11]. And we compare our
Owner is the receiver of CALL instruction. technique(marked as CESC) with Oyente [3] and Securify [5].
• The storage as part of security-critical operations execu-
While Oyente and Securify allow checking on a set of bug
tion path condition constraint. Such as the concurrency patterns, we focused on transaction-ordering dependency bug
exploits in Figure 2b, the value of Owner is a condition (TOD) in this setting. The results are shown in Table I. The
for DELEGATECALL ’s execution. first column is contract address in Ethereum [11]. The con-
Our technique using symbolic execution explores branches currency exploits on CALL instructions marked as . The con-
and leverages program paths to identify concurrency exploits currency exploits on DELEGATECALL/CALLCODE instructions
from EVM bytecode (smart contract). The detection flow marked as  . The concurrency exploits on SELFDESTRUCT
mainly contains three steps: instructions marked as . We marked false positives as gray .
Step 1: Marking Storage Operation. Accessing storage By comparing with our approach in detecting concurrency
variable is a major source of concurrency exploits. Our work exploits, our approach highly improve the scope of detection
using symbolic execution traces two EVM instruction to for potentially concurrent attacks and reduce false positives.
operate storage: SLOAD loads word from storage and SSTORE IV. C ONTRIBUTION
saves a word to storage. Step 1 marks operation of storage to
construct access flow graph(AFG). We summarize our main contributions below.
• We highlighted concurrency exploit as a new and general
Step 2: Merging Access Flow. Since an AFG contains se-
form of security attacks on Ethereum smart contracts.
quential relations of storage operation. Step 2 aims to classify
• We proposed a systematic detection technique to identify
in-sensitive operation in AFG. Consider foo function(branch)
concurrency exploits based on symbolic execution.
in Figure 1, it firstly writes(SSTORE) price(line 14) then
• We conducted a preliminary evaluation on real contracts
loads(SLOAD) price to use(line 15,17). Since the value of
deployed on Ethereum.



Authorized licensed use limited to: UNIVERSIDADE DE BRASILIA. Downloaded on June 25,2021 at 14:53:44 UTC from IEEE Xplore. Restrictions apply.
 R EFERENCES
[1] G. Wood, “Ethereum: A secure decentralised generalised transaction
ledger,” Ethereum Project Yellow Paper, vol. 151, 2014.
[2] I. Sergey and A. Hobor, “A concurrent perspective on smart contracts,” in
International Conference on Financial Cryptography and Data Security.
Springer, 2017, pp. 478–493.
[3] L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making smart
contracts smarter,” in Proceedings of the 2016 ACM SIGSAC Conference
on Computer and Communications Security. ACM, 2016, pp. 254–269.
[4] K. Delmolino, M. Arnett, A. Kosba, A. Miller, and E. Shi, “Step
by step towards creating a safe smart contract: Lessons and insights
from a cryptocurrency lab,” in International Conference on Financial
Cryptography and Data Security. Springer, 2016, pp. 79–94.
[5] P. Tsankov, A. Dan, D. D. Cohen, A. Gervais, F. Buenzli, and M. Vechev,
“Securify: Practical security analysis of smart contracts,” arXiv preprint
arXiv:1806.01143, 2018.
[6] K. Bhargavan, A. Delignat-Lavaud, C. Fournet, A. Gollamudi,
G. Gonthier, N. Kobeissi, A. Rastogi, T. Sibut-Pinote, N. Swamy,
and S. Zanella-Beguelin, “Formal verification of smart contracts,” in
Proceedings of the 2016 ACM Workshop on Programming Languages
and Analysis for Security-PLAS’16, 2016, pp. 91–96.
[7] S. Kalra, S. Goel, M. Dhawan, and S. Sharma, “Zeus: Analyzing safety
of smart contracts.” NDSS, 2018.
[8] I. Nikolic, A. Kolluri, I. Sergey, P. Saxena, and A. Hobor, “Finding
the greedy, prodigal, and suicidal contracts at scale,” arXiv preprint
arXiv:1802.06038, 2018.
[9] B. Jiang, Y. Liu, and W. Chan, “Contractfuzzer: Fuzzing smart contracts
for vulnerability detection,” in Proceedings of the 33rd ACM/IEEE
International Conference on Automated Software Engineering. ACM,
2018, pp. 259–269.
[10] Ethereum, “Solidity — solidity 0.4.19 documentation,” 2017. [Online].
Available: https://solidity.readthedocs.io/en/develop/
[11] E. Team, “Etherscan: The ethereum block explorer,” 2017.



Authorized licensed use limited to: UNIVERSIDADE DE BRASILIA. Downloaded on June 25,2021 at 14:53:44 UTC from IEEE Xplore. Restrictions apply.