Securify: Practical Security Analysis of Smart Contracts Petar Tsankov Andrei Dan Dana Drachsler-Cohen ETH Zurich ETH Zurich ETH Zurich [email protected] [email protected] [email protected] Arthur Gervais∗ Florian Bünzli Martin Vechev Imperial College London ETH Zurich ETH Zurich [email protected] [email protected] [email protected] ABSTRACT July 2017 [10], and few months later 280M were frozen due to a bug Permissionless blockchains allow the execution of arbitrary pro- in the very same wallet [13]. It is apparent that effective security grams (called smart contracts), enabling mutually untrusted entities checkers for smart contracts are urgently needed. to interact without relying on trusted third parties. Despite their Key Challenges. The main challenge in creating an effective secu- potential, repeated security concerns have shaken the trust in han- rity analyzer for smart contracts is the Turing-completeness of the dling billions of USD by smart contracts. programming language, which renders automated verification of To address this problem, we present Securify, a security ana- arbitrary properties undecidable. To address this issue, current auto- lyzer for Ethereum smart contracts that is scalable, fully automated, mated solutions tend to rely on fairly generic testing and symbolic and able to prove contract behaviors as safe/unsafe with respect to execution methods (e.g., Oyente [39] and Mythril [16]). While use- a given property. Securify’s analysis consists of two steps. First, it ful in some settings, these approaches come with several drawbacks: symbolically analyzes the contract’s dependency graph to extract (i) they can miss critical violations (due to under-approximation), precise semantic information from the code. Then, it checks com- (ii) yet, can also produce false positives (due to imprecise modeling pliance and violation patterns that capture sufficient conditions of domain-specific elements [30]), and (iii) they can fail to achieve for proving if a property holds or not. To enable extensibility, all sufficient code coverage on realistic contracts (Oyente achieves patterns are specified in a designated domain-specific language. only 20:2% coverage on the popular Parity wallet [17]). Overall, Securify is publicly released, it has analyzed > 18K contracts these drawbacks place a significant burden on their users, who must submitted by its users, and is regularly used to conduct security inspect all reports for false alarms and worry about unreported vul- audits by experts. We present an extensive evaluation of Securify nerabilities. Indeed, many security properties for smart contracts over real-world Ethereum smart contracts and demonstrate that it are inherently difficult to reason about directly. A viable pathto can effectively prove the correctness of smart contracts and discover addressing these challenges is building an automated verifier that critical violations. targets important domain-specific properties [15]. For example, re- cent work [31] focuses solely on identifying reentrancy issues in KEYWORDS smart contracts [5]. Smart contracts; Security analysis; Stratified Datalog Domain-Specific Insight. A key observation of this work is that 1 INTRODUCTION it is often possible to devise precise patterns expressed on the contract’s data-flow graph in a way where a match of the pattern Blockchain platforms, such as Nakamoto’s Bitcoin [43], enable the implies either a violation or satisfaction of the original security trade of crypto-currencies between mutually mistrusting parties. property. For example, 90:9% of all calls in Ethereum smart contracts To eliminate the need for trust, Nakomoto designed a peer-to-peer can be proved free of the infamous DAO bug [6] by matching a network that enables its peers to agree on the trading transactions. pattern stating that calls are not followed by writes to storage. Buterin [24] identified the applicability of decentralized computa- The reason why it is possible to establish such a correspondence arXiv:1806.01143v2 [cs.CR] 24 Aug 2018 tion beyond trading, and designed the Ethereum blockchain which is that violations of the original property in real-world contracts supports the execution of programs, called smart contracts, written tend to often violate a much simpler property (captured by the in Turing-complete languages. Smart contracts have shown to be pattern). Indeed, in terms of verification, a key benefit in working applicable in many domains including financial industry [8], public with patterns, instead of with their corresponding property, is that sector [11] and cross-industry [9]. patterns are substantially more amenable to automated reasoning. The increased adoption of smart contracts demands strong se- curity guarantees. Unfortunately, it is challenging to create smart Securify: Domain-specific Verifier. Based on the above in- contracts that are free of security bugs. As a consequence, critical sight, we developed Securify, a lightweight and scalable security vulnerabilities in smart contracts are discovered and exploited ev- verifier for Ethereum smart contracts. The key technical idea isto ery few months [2, 3, 6, 7, 10, 26]. In turn, these exploits have led to define two kinds of patterns that mirror a given security property: losses reaching millions worth of USD in the past few years: 150M (i) compliance patterns, which imply the satisfaction of the property, were stolen from the popular DAO contract in June 2016 [6], 30M and (ii) violation patterns, which imply its negation. To check these were stolen from the widely-used Parity multi-signature wallet in patterns, Securify symbolically encodes the dependence graph of the contract in stratified Datalog [50] and leverages off-the-shelf ∗Work done while at ETH Zurich 1 exists Call(_, _, y) unsafe behaviors safe behaviors 00:60 MemTag(0x20,Const) violation compliance 01:07 MemVal(0x40,Caller) !MayDep(y,Gas) 02:5b pattern pattern Eq(x, MLoad(0x40)) all SStore(_, x, _) 03:56 SStore(02, Gas, y) DetBy(x,Caller) 04:10 Call(04, x, y) ... ... ... violation contract semantic facts (§4) compliance and security no violation bytecode violation patterns (§5) report all behaviors warning Figure 1: Securify’s approach is based on automatic infer- Figure 2: Securify uses compliance and violation patterns ence of semantic program facts followed by checking of to guarantee that certain behaviors are safe and, respec- compliance and violation security patterns over these facts. tively, unsafe. The remaining behaviors are reported as warnings (to avoid missing errors). scalable Datalog solvers to efficiently (typically within seconds) analyze the code. To ensure extensibility, all patterns are expressed in a designated domain-specific language (DSL). execution tools have better support for numerical properties (e.g., In Fig. 1, we illustrate the analysis flow of Securify. Starting overflow). Our finding was that Securify was particularly help- with the contract’s bytecode (or source code, which can be compiled ful in auditing larger contracts, which are challenging to inspect to bytecode), Securify derives semantic facts inferred by analyzing with existing solutions for the reasons listed earlier. Overall, we the contract’s dependency graph and uses these facts to check a set believe Securify is a pragmatic and valuable point in the space of of compliance and violation patterns. Based on the outcome of these analyzing smart contracts due to its careful balance of scalability, checks, Securify classifies all contract behaviors into violations (_), guarantees, and precision. warnings (N), and compliant (■), as abstractly illustrated in Fig. 2. To summarize, our main contributions are: Here, the large box depicts all contract behaviors, partitioned into Main Contributions. – A decompiler that symbolically encodes the dependency safe (which satisfy the property) and unsafe ones (which violate graph of Ethereum contracts in Datalog (Section 4). it). Securify reports as violations (_) all behaviors matching the – A set of compliance and violation security patterns that violation pattern, and as warnings (N) all remaining behaviors not capture sufficient conditions to prove and disprove practical matched by the compliance pattern. security properties (Section 5). Reduced Manual Effort. Compared to existing symbolic ana- – An end-to-end implementation, called Securify, which fully lyzers for smart contracts, Securify reduces the required effort to automates the analysis of contracts (Section 6). inspect reports in two ways. First, existing analyzers do not report – An extensive evaluation over existing Ethereum smart con- definite violations (they conflate _ and N), and thus require users tracts showing that Securify can effectively prove the cor- to manually classify all reported vulnerabilities into true positives rectness of contracts and discover violations (Section 7). (found in the red box ) or false positives (found in the green box ). In contrast, Securify automatically classifies behaviors guaranteed 2 MOTIVATING EXAMPLES to be violations (marked with _). Hence, the user only needs to In this section, we motivate the problem we address through two manually classify the warnings (N) as true or false positives. real-world security issues that affected ≈ 200 millions worth of USD As we show in our evaluation, the approach of using both viola- in 2017. We describe the underlying security properties and the tion and compliance patterns reduces the warnings a user needs challenges