PaperlayerView exact revision on arXiv

Source-linked AI summary

A Survey on Ethereum Systems Security: Vulnerabilities, Attacks and Defenses

Huashan Chen, Marcus Pendleton, Laurent Njilla, Shouhuai Xu

arXiv:1908.04507v1cs.CR

TL;DR

Ethereum’s richer DApp paradigm expands the security threat surface, while existing surveys lack a systematic and comprehensive account of its vulnerabilities, attacks, and defenses. This survey systematizes those three perspectives, correlates them across Ethereum’s layers, and derives insights into root causes, consequences, defenses, and future research directions.

  • Problem

    Existing surveys do not provide a systematic and comprehensive understanding of Ethereum vulnerabilities, attacks, and defenses, including vulnerability root causes.

  • Method

    The survey analyzes Ethereum security across application, data, consensus, and network layers through vulnerabilities, attacks, defenses, and their correlations.

  • Results

    The survey systematizes vulnerability root causes, attack consequences, defenses, and industry best practices, providing insights into the state of the art and future research directions.

  • Takeaways & Limitations

    Securing Ethereum requires understanding its expanded threat surface and the security properties of a complex system that are difficult to formalize.

Abstract

from arXiv · show

The blockchain technology is believed by many to be a game changer in many application domains, especially financial applications. While the first generation of blockchain technology (i.e., Blockchain 1.0) is almost exclusively used for cryptocurrency purposes, the second generation (i.e., Blockchain 2.0), as represented by Ethereum, is an open and decentralized platform enabling a new paradigm of computing --- Decentralized Applications (DApps) running on top of blockchains. The rich applications and semantics of DApps inevitably introduce many security vulnerabilities, which have no counterparts in pure cryptocurrency systems like Bitcoin. Since Ethereum is a new, yet complex, system, it is imperative to have a systematic and comprehensive understanding on its security from a holistic perspective, which is unavailable. To the best of our knowledge, the present survey, which can also be used as a tutorial, fills this void. In particular, we systematize three aspects of Ethereum systems security: vulnerabilities, attacks, and defenses. We draw insights into, among other things, vulnerability root causes, attack consequences, and defense capabilities, which shed light on future research directions.

I. INTRODUCTION

Ethereum extends blockchain systems from cryptocurrency toward semantically richer DApps, but this broader functionality enlarges the security threat surface. This survey addresses the gap with a systematic treatment of vulnerabilities, attacks, and defenses across the Ethereum ecosystem.

  • Motivation: Ethereum introduced smart contracts and DApps, extending blockchain applications beyond Bitcoin’s payment-focused UTXO model.Ethereum uses an account-centered model and supports interacting smart contracts as DApp building blocks.
  • Motivation: High-profile incidents, including the DAO, Parity wallet, and MyEtherWallet attacks, demonstrate substantial financial and infrastructure risks.Reported losses include approximately US$60M, US$31M, and US$17M, respectively.
  • Contributions: The survey systematizes 44 vulnerability types, 26 attacks, and 47 defenses across Ethereum’s platform and operating environment.It also relates vulnerabilities to their root causes, attacks to their consequences, and defenses to their capabilities and effort.
  • Findings: The analysis finds that smart contracts introduce novel vulnerabilities, while blockchain design and implementation vulnerabilities are harder to address than traditional application vulnerabilities.Environment vulnerabilities are largely attributed to human, usability, and networking factors.
  • Findings: Application-layer attacks caused the largest financial losses, while existing proactive defenses cover many vulnerability exploits more broadly than reactive defenses.The survey also reports that front-end protection and front-end/back-end interactions receive comparatively limited attention.
  • Related work: The survey differs from prior work by focusing on the overall Ethereum ecosystem and jointly analyzing vulnerabilities, attacks, defenses, and their relationships.Related surveys variously emphasize narrower vulnerability sets, attack surfaces, tools, Bitcoin-like transactions, or consensus protocols.

C. Paper outline

The paper outlines Ethereum’s layered architecture and explains how accounts, smart contracts, transactions, storage structures, and consensus interact. It presents the system from application and data components through transaction processing and chain selection.

  • Architecture: Ethereum’s four-layer architecture comprises application, data, consensus, and network layers, operating within a broader environment.The environment supplies user interfaces, databases, cryptographic mechanisms, and Internet infrastructure.
  • Accounts and contracts: Ethereum supports externally owned accounts and contract accounts, with contract accounts associated with executable bytecode defining application business logic.Account state includes fields such as nonce, balance, and storage-related data.
  • Accounts and contracts: Smart contracts execute in stack-based EVMs whose quasi-Turing-complete execution is bounded by the transaction’s available gas.DApps commonly combine a user-facing front-end with smart-contract back-end components.
  • Transaction lifecycle: A transaction records sender, recipient, value, and input, then moves through signing, client validation, network broadcast, mining, execution, and blockchain-state update.Miners select transactions from their pools, execute them, formulate blocks, and update the blockchain state.
  • Data layer: Ethereum stores account states, transactions, and execution receipts in trie-based structures referenced from block headers.Trie paths encode keys and leaf nodes contain corresponding values.
  • Consensus layer: Because multiple miners can create valid blocks simultaneously, Ethereum uses a GHOST variant to select the branch with the highest cumulative block difficulty.Stale blocks are excluded from the main chain but can receive uncle rewards.

3) The consensus layer:

Ethereum’s consensus and surrounding infrastructure determine how blocks are selected, rewarded, stored, and communicated. The survey frames these mechanisms as components whose design and implementation can create security vulnerabilities.

  • 3) The consensus layer:: The protocol rewards both regular blocks and referenced stale uncle blocks, with rewards depending on uncle distance and references.A nephew miner receives 1/32 of the static block reward per reference, while the uncle miner receives 1 − d/8 of that reward for 1 ≤ d ≤ 6.
  • 3) The consensus layer:: Ethereum nodes store the blockchain and communicate through P2P networking supported by node discovery, routing tables, RLPx, and the Ethereum Wire Protocol.The network exchanges blockchain information such as transactions and blocks between clients.
  • 3) The consensus layer:: The survey organizes Ethereum security by architectural layers and analyzes vulnerabilities, attacks, and defenses together with their relationships.Vulnerabilities are classified by location, cause, and status, including eliminated, avoidable by best practice, and open categories.

A. Vulnerabilities at the application layer

Application-layer vulnerabilities arise from smart-contract behavior, language and toolchain weaknesses, and interactions between contracts. The survey catalogs these vulnerabilities, their exploitation mechanisms, and the extent to which existing practices or defenses address them.

  • Application-layer vulnerabilities: Reentrancy lets an external callee call back before execution completes, bypassing validity checks until Ether is drained or gas is exhausted.The vulnerability involves cyclic calls between contracts.
  • Application-layer vulnerabilities: Delegatecall injection allows malicious callee bytecode to execute in the caller’s context and modify its state variables.The vulnerability follows from EVM support for code reuse through DELEGATECALL.
  • Application-layer vulnerabilities: Application-layer weaknesses also include frozen Ether, insecure contract upgrading, unexpected reverts, arithmetic errors, manipulated balances, and unchecked call returns.These arise from contract design, external-call behavior, insufficient numeric validation, and Solidity exception-handling discrepancies.
  • Application-layer vulnerabilities: Authentication through tx.origin can be bypassed through phishing because authorization checks the transaction’s original EOA rather than an intermediate malicious caller.Using msg.sender instead of tx.origin is presented as a prevention practice.
  • Application-layer vulnerabilities: Several vulnerabilities remain constrained by language or execution-model limitations: type casts have no feasible avoidance method, while under-priced opcodes may not be completely prevented by gas repricing.The survey also notes that correctly specifying visibility remains necessary despite Solidity’s mandatory visibility syntax from version 0.5.0.
  • Application-layer vulnerabilities: Generating randomness from block-controlled seeds lets malicious miners manipulate outcomes, while proposed Oracle RNG and RANDAO remedies introduce single-point-of-failure or throughput trade-offs.The vulnerability is attributed to manipulable entropy sources.

B. Vulnerabilities at the data layer

Data-layer vulnerabilities can exploit how transactions and accounts are represented across Ethereum’s chains and state trie. The survey describes replay and denial-of-service risks and records the EIP-155 and EIP-161 mitigations.

  • Data-layer vulnerabilities: Indistinguishable chains enabled cross-chain transaction replay because pre-EIP-155 signatures lacked chain-specific information.Ethereum transactions before the hard fork contained six fields without chain-specific data.
  • Data-layer vulnerabilities: Empty accounts increase state-trie bookkeeping and synchronization and transaction-processing costs, enabling denial-of-service attacks through their mass creation.EIP-161 eliminated this vulnerability by removing empty accounts and preventing their storage in the state trie.

C. Vulnerabilities at the consensus layer

Consensus, networking, and environment vulnerabilities expose Ethereum to attacks ranging from outsourced mining and majority-hashrate control to transaction censorship, synchronization stalls, exposed interfaces, and compromised DApp credentials. Several weaknesses arise from protocol design choices, while environmental weaknesses often involve human, web, or networking factors.

  • Consensus layer: Ethash permits miners to outsource smaller puzzle-search tasks because its preimage search is only partially sequential.Several proposed countermeasures have not been adopted by the Ethereum community.
  • Consensus layer: A miner controlling 51% of hashrate can take over the blockchain, reverse transactions, and double-spend at will.The survey characterizes this vulnerability as inevitable for PoW-based consensus protocols.
  • Consensus layer: Fixed consensus termination commits a block after a fixed depth, although communication delay may require waiting for more confirmations to increase protection against double-spending.The protocol provides probabilistic agreement with deterministic termination.
  • Consensus layer: Uncle rewards can lower Ethereum’s security relative to Bitcoin by reducing the risk of selfish mining and double-spending strategies.The survey states that eliminating this vulnerability was unresolved at the time of writing.
  • Network layer: Ethereum’s network layer includes isolation, eclipse, synchronization, and remote-interface weaknesses, including unlimited node creation, uncapped incoming connections, sole block synchronization, and exposed JSON-RPC access.Sole synchronization can stall a client and facilitate double-spending or denial-of-service attacks, while remote port 8545 access enables attackers to call client APIs.
  • Ethereum environment: Environment vulnerabilities include weak passwords, XSS, unvalidated redirects, broken access control, and unreliable BGP messages that can compromise DApp webpages, keys, or user routing.Offline signing prevents the XSS scenario described by keeping private keys out of the browser.

F. Further analysis of vulnerability causes

The survey attributes Ethereum vulnerabilities to four broad sources: smart-contract programming, Solidity and its toolchain, Ethereum design and implementation, and human, usability, and networking factors. The analysis links these causes to 44 vulnerabilities and finds that design- and implementation-level weaknesses are particularly difficult to address.

  • Smart contract programming: Smart-contract programming causes include external dependence, improper validation, inadequate authentication or authorization, and uncontrolled gas consumption.These four sub-causes contributed 14 vulnerability types.
  • Smart contract programming: Among 26 application-layer vulnerability types, 20 can be prevented through best practices, highlighting the importance of secure coding practice.The survey presents this as evidence that the new programming paradigm requires adequate programmer training.
  • Solidity language and tool chain: Solidity and toolchain weaknesses include inconsistent exception handling, undefined storage-pointer behavior, constructor syntax, weak typing, and insufficient compiler support.These five causes contributed five vulnerability types.
  • Ethereum design and implementation: Ethereum design and implementation causes span the EVM, blockchain, PoW consensus, incentive mechanism, and P2P protocol across four architectural layers.Examples include missing input checks, improper execution models, flexible block creation, partially sequential PoW, greedy incentives, and flawed synchronization.
  • Ethereum design and implementation: Design- and implementation-related causes contributed 18 vulnerabilities, nine of which remained largely open at the time of writing.The survey concludes that these vulnerabilities are harder to cope with than other vulnerability classes.
  • Human, usability, and networking factors: Human, usability, and networking causes include improper configuration, insufficient authentication, faulty web development, and exposed Internet services.Together, these causes led to seven vulnerabilities.

4) Human, usability and networking factors:

Ethereum security vulnerabilities span the environment, blockchain, client implementation, and application layers, with many remaining open and requiring defenses across the architecture. The surveyed attacks illustrate how these vulnerabilities produce diverse consequences, including major financial losses.

  • 4) Human, usability and networking factors:: Environment vulnerabilities are largely caused by human, usability, and networking factors, but form a smaller fraction than vulnerabilities inherent to the blockchain and smart contracts.
  • 4) Human, usability and networking factors:: 13 vulnerabilities remain largely open across Ethereum’s blockchain design, client implementation, environment, and application-layer flexibility.The paper identifies distinct mitigation directions, including alternate network protocols, stronger environmental defenses, and alternate contract design patterns or type systems.
  • 5) Cross-cutting analysis:: Many vulnerabilities remain to be tackled across every architectural layer, from application and data through consensus, network, and environment.
  • IV. ATTACKS: The 26 surveyed attacks are grouped by the locations of the vulnerabilities they exploit and described through their history, cause, tactic, and direct impact.The same attack name can represent different vulnerability combinations and consequences, as illustrated by the two Parity multisignature wallet attacks.
  • A. Attacks at the application layer: The DAO attack exploited reentrancy during refunds, while the Parity attacks drained approximately US$31M or froze approximately US$280M through distinct vulnerability combinations.The BECToken attack exploited integer overflow and caused token theft plus a temporary shutdown of exchange trading; GovernMental and HYIP attacks exploited denial-of-service-related vulnerabilities.

B. Attacks at the data layer

Data-layer attacks exploit transaction and state-management weaknesses, including indistinguishable chains and under-priced operations. Their effects range from cross-chain financial losses to slower block production and denial-of-service conditions.

  • B. Attacks at the data layer: Cross-chain replay became possible because ETH and ETC shared transaction history without defenses against replay, causing exchanges participating in both chains to lose substantial money.
  • B. Attacks at the data layer: Under-priced DDoS attacks exploited application- and data-layer vulnerabilities involving improperly priced EVM opcodes.
  • B. Attacks at the data layer: Before EIP 150, repeated EXTCODESIZE invocations could make block creation 2-3x slower by charging only 20 gas for contract-bytecode reads.
  • B. Attacks at the data layer: A second under-priced-opcode attack combined improper SUICIDE pricing with the empty-account-in-state-trie vulnerability.

C. Attacks at the consensus layer

Consensus- and network-layer attacks exploit mining power, consensus timing, peer connectivity, and exposed interfaces, while environment and web-layer compromises can directly steal assets and private keys.

  • C. Attacks at the consensus layer: A 51% attack against ETC exploited reduced hashrate requirements to double-spend against exchanges, causing an estimated loss of US$1.1M.
  • C. Attacks at the consensus layer: Selfish mining exploits uncle-block rewards by withholding and selectively publishing blocks to obtain an unfair share of rewards.
  • C. Attacks at the consensus layer: Balance attacks exploit probabilistic PoW consensus under communication delays and unreliable BGP messages by partitioning miners into groups of similar power.
  • C. Attacks at the consensus layer: Account hijacking exploits RPC API exposure by leaving a decrypted private key in client memory for 300 seconds by default.
  • C. Attacks at the consensus layer: Eclipse attacks isolate victim nodes through connection monopolization or routing-table poisoning, exploiting weaknesses in node creation, incoming connections, or peer selection.
  • C. Attacks at the consensus layer: Web-facing attacks included EtherDelta code injection, CoinDash access-control compromise, Enigma password compromise, and MyEtherWallet BGP/DNS hijacking.Reported losses included thousands of dollars for EtherDelta, US$7M for CoinDash, and approximately US$17M for MyEtherWallet.

1) Unauthorized code execution:

The survey organizes Ethereum attack consequences into distinct categories and connects each consequence to exploiting attacks and vulnerabilities. It finds especially large losses from Parity denial of service, application-layer attacks, and compromised web interfaces.

  • 3) Unfair income:: Double-spending scenarios include 51% attacks, eclipse attacks, and balance attacks; the largest reported single double-spending loss was about US$1.1M.
  • 1) Unauthorized code execution:: Private-key leakage arises through MyEtherWallet, account hijacking, and EtherDelta attacks, with the largest reported loss reaching US$20M.
  • 7) Summary and insights:: The largest single financial loss was $280M from a Parity-wallet DoS attack that disabled a library used by many contracts.Because code reuse amplified the impact, the paper highlights auditing popular contracts and their libraries.
  • 7) Summary and insights:: DApps using centralized web interfaces are not fully decentralized, because vulnerabilities in those interfaces can cause large financial losses.
  • 7) Summary and insights:: Application-layer attacks caused Ethereum’s largest financial losses, partly because DApps operate directly on digital assets.

V. DEFENSES

The survey organizes 47 Ethereum defenses into proactive and reactive classes, with proactive mechanisms further divided by their technical focus. These defenses help developers avoid or mitigate common smart-contract vulnerabilities.

  • Defense taxonomy: 47 defenses are categorized as proactive or reactive rather than by Ethereum architecture layer.Proactive defenses are organized around contract programming languages, development, analysis, contract and Ethereum enhancement, and consensus protocols.
  • Proactive defenses: Programming-language defenses use high-level languages to remove risky functionality and intermediate-level languages to support formal contract analysis.Vyper adds bounds and overflow checking, while Simplicity provides formal semantics through Coq and Scilla separates computation from inter-contract communication.
  • Proactive defenses: These programming-language approaches can help developers avoid or mitigate common vulnerabilities in the new smart-contract programming paradigm.The survey connects these defenses to the practical difficulty of writing secure smart contracts.
  • Contract development: Best practices include checking conditions, updating state, then interacting, while favoring pull over push for external calls.The principles target interaction ordering and control over how recipients withdraw or receive funds.
  • Contract development: Software-engineering mechanisms such as rate limits and balance limits defend against attacks that may exploit unknown vulnerabilities.These mechanisms constrain repeated actions, Ether transfers, or funds held by a contract.
  • Contract analysis: Contract-analysis defenses use symbolic execution, abstract interpretation, formal verification, fuzzing, and model-based vulnerability detection.The approaches analyze execution paths, program semantics, specifications, generated inputs, or structural patterns.

3) Smart contract analysis:

Smart-contract analysis defenses detect vulnerabilities through complementary program-analysis techniques, including symbolic execution, abstract interpretation, formal verification, fuzzing, and model-based detection. The survey also describes defenses targeting consensus and mining-related vulnerabilities.

  • Smart contract analysis: Symbolic execution traverses feasible control-flow paths, but may omit paths and explore unreachable paths, causing false negatives and false positives.Oyente detects four vulnerability types, while Mythril combines symbolic and concrete execution to detect eight types.
  • Smart contract analysis: Abstract interpretation over-approximates program semantics to achieve soundness in vulnerability analysis.Securify uses compliance and violation patterns, while MadMax and Vandal analyze bytecode-derived representations for specific vulnerability classes.
  • Smart contract analysis: Formal verification proves contract correctness with respect to a specification and assures completeness by avoiding false positives.Theorem-proving approaches formalize EVM semantics and reason about invariants, safety, and semantic properties at bytecode level.
  • Smart contract analysis: Fuzzing detects vulnerabilities by generating ABI-derived inputs and inspecting instrumented EVM execution behavior.ContractFuzzer detects five vulnerability types, including reentrancy and unchecked call return values.
  • Smart contract analysis: Model-based detection uses sequence learning or XML parse-tree patterns to identify vulnerability types in contracts.The survey describes Tann et al.'s sequence-learning approach and SmartCheck's XPath-pattern checks over Solidity parse trees.
  • Other proactive defenses: Cryptographic mechanisms, non-outsourceable puzzles, and mining protocols address privacy, outsourcing, and mining-centralization vulnerabilities.Hawk hides transaction data; other proposals target outsourceable puzzles and the 51% hashrate vulnerability.

B. Reactive defenses

Reactive defenses monitor runtime behavior and mitigate damage from potential exploits, complementing proactive defenses. The survey finds that proactive defenses cover many vulnerabilities, whereas reactive defenses cover fewer but can address vulnerabilities that survive earlier defenses.

  • Reactive defenses: Runtime verification monitors execution traces or incoming transactions for suspicious activities that may violate security properties.DappGuard combines transaction monitoring with Oyente to assess whether incoming transactions can cause violations.
  • Reactive defenses: When violations are detected, mitigation can disable vulnerable functionality, require a compensating stake, or replace vulnerable contracts.These mechanisms aim to limit damage during contract execution rather than prevent every vulnerability beforehand.
  • Defense capabilities: Defense-capability analysis compares which proactive and reactive defenses address attacks exploiting particular vulnerabilities.The survey evaluates six defense kinds: five proactive categories and runtime verification.
  • Defense capabilities: Contract best practices can prevent or mitigate attacks exploiting 22 application-layer vulnerability types, while smart-contract analyzers address 18.Security enhancement addresses eight vulnerability types, including four application-layer types.
  • Defense capabilities: Existing proactive defenses cover many vulnerability types, whereas reactive defenses cover only a few.Reactive defenses remain useful for attacks exploiting vulnerabilities that survive proactive defenses.
  • Defense investment: Defense investment is uneven: 17 defenses address the reentrancy vulnerability, while 19 vulnerabilities have zero or one defense mechanism.The latter vulnerabilities are mostly caused by Ethereum design and implementation or reside in the Ethereum environment.
  • Defense investment: Defense effort appears driven by financial losses, creating a reactive prioritization that may leave lower-profile vulnerabilities underprotected.The survey characterizes this as defenders chasing vulnerabilities after attackers expose them.
  • Defense coverage: Existing studies largely protect DApp back-ends while ignoring front-ends and front-end/back-end interactions, although related attacks caused over US$24M in losses.Adequate DApp defense therefore needs to consider interfaces, contracts, and their interactions.

VI. DISCUSSION: GOING BEYOND ETHEREUM

Beyond Ethereum, the survey identifies unresolved needs for rigorously specified security properties, sufficient analysis methodologies, and metrics for measuring security and risk. It concludes by framing its layered, three-perspective synthesis as a basis for future research.

  • A. Rigorous definition of properties: Blockchain-based systems lack a deep understanding of rigorously specified desirable security properties, which are difficult to formalize for complex systems such as Ethereum.Only informal properties are described as a preliminary step toward the broader goal.
  • B. Rigorous analysis methodologies: After properties are defined, principled and rigorous methodologies are needed to analyze whether blockchain systems satisfy them.Cryptography and formal methods have succeeded for some building-block properties but have limitations, while holistic analysis remains necessary.
  • C. Security and risk metrics: Blockchain-based systems also lack a deep understanding of metrics necessary and sufficient for quantifying security and risk.The survey calls metric definition urgent because such systems may become digital infrastructures for future society.
  • VI. Discussion and conclusion: The survey covers Ethereum's application, data, consensus, and network layers while correlating vulnerabilities, attacks, and defenses.It also systematizes industry best practices into guiding principles and identifies future research directions.
Loading 1908.04507v1…