PaperlayerView exact revision on arXiv

Source-linked AI summary

Sereum: Protecting Existing Smart Contracts Against Re-Entrancy Attacks

Michael Rodler, Wenting Li, Ghassan O. Karame, Lucas Davi

arXiv:1812.05934v1cs.CR

TL;DR

Deployed smart contracts are difficult to protect because their code is immutable and offline analyses can miss runtime re-entrancy patterns. Sereum adds runtime monitoring and validation to the EVM without modifying contracts or requiring semantic knowledge, detecting attacks with a 0.06% false-positive rate in the reported evaluation.

  • Problem

    Immutable deployed code and incomplete offline analysis leave a protection gap for legacy smart contracts vulnerable to re-entrancy attacks.

  • Method

    Sereum hardens the EVM with dynamic taint tracking and write locks that monitor execution and prevent dangerous storage updates during re-entrant invocations.

  • Results

    0.063% of 77,987,922 re-executed transactions were flagged, and Sereum successfully detected all tested attack transactions for three new re-entrancy patterns.

  • Takeaways & Limitations

    Runtime monitoring can protect existing deployed contracts against re-entrancy attacks while covering advanced cross-function, delegated, and create-based patterns.

Abstract

from arXiv · show

Recently, a number of existing blockchain systems have witnessed major bugs and vulnerabilities within smart contracts. Although the literature features a number of proposals for securing smart contracts, these proposals mostly focus on proving the correctness or absence of a certain type of vulnerability within a contract, but cannot protect deployed (legacy) contracts from being exploited. In this paper, we address this problem in the context of re-entrancy exploits and propose a novel smart contract security technology, dubbed Sereum (Secure Ethereum), which protects existing, deployed contracts against re-entrancy attacks in a backwards compatible way based on run-time monitoring and validation. Sereum does neither require any modification nor any semantic knowledge of existing contracts. By means of implementation and evaluation using the Ethereum blockchain, we show that Sereum covers the actual execution flow of a smart contract to accurately detect and prevent attacks with a false positive rate as small as 0.06% and with negligible run-time overhead. As a by-product, we develop three advanced re-entrancy attacks to demonstrate the limitations of existing offline vulnerability analysis tools.

I. INTRODUCTION

Sereum addresses the difficulty of protecting deployed smart contracts when code is immutable, owners are anonymous, and offline analyses may miss runtime attack patterns. It uses runtime monitoring to detect and prevent re-entrancy attacks without modifying contracts or requiring semantic knowledge.

  • Research Gap: Immutable code, anonymous owners, and incomplete offline analysis make fixing vulnerabilities in deployed smart contracts particularly difficult.These challenges limit the practical value of approaches that only prove vulnerabilities absent before deployment.
  • Research Question and Contribution: Sereum protects existing deployed contracts against re-entrancy attacks without modifying contract code or requiring semantic knowledge.The approach is designed to remain backwards compatible.
  • Additional Findings: The paper develops cross-function, delegated, and create-based re-entrancy attacks that existing vulnerability-detection tools may miss but Sereum detects.These attacks illustrate limitations of offline vulnerability analysis.
  • Design: Sereum monitors actual smart-contract execution and uses taint tracking to introduce write locks across potentially dangerous storage variables.The hardened EVM tracks data flows from storage variables to control-flow decisions and prevents invalid writes in re-entered invocations.
  • Evaluation: Sereum detects all malicious transactions related to the DAO attack and incurs 9.6% runtime overhead in the reported evaluation.The evaluation also reports a 0.06% false-positive rate.

A. Smart Contracts and the Ethereum Virtual Machine

Ethereum smart contracts execute deterministic code on the EVM and can transfer currency through transactions and contract calls. Re-entrancy becomes malicious when callbacks cause execution to use internal state that remains inconsistent after an external call.

  • Smart Contracts and the EVM: Ethereum contracts are self-contained programs executed by blockchain nodes, with persistent state maintained in the EVM storage region.The EVM also provides volatile stack and memory regions for execution.
  • Smart Contracts and the EVM: Transactions invoke public contract functions, while CALL transfers control to another contract and DELEGATECALL shares the caller’s execution context.These calls form nested execution chains on the EVM call stack.
  • Re-entrancy: Re-entrancy occurs when an external contract calls back into the calling contract within the same transaction.Legitimate re-entrancy can occur in supported Ethereum programming patterns.
  • Re-entrancy: A malicious re-entrancy uses a control-flow decision based on victim state that is updated only after an external call returns.The re-entered invocation therefore operates on an inconsistent state value.
  • Re-entrancy: In the vulnerable Victim example, credit[msg.sender] is checked before an external call and reduced afterward, allowing a second invocation before the update.The corresponding figure tracks the call sequence and the amount and credit state.

C. Common Defenses and Analysis Tools

Common defenses mainly analyze contracts before deployment using symbolic execution, model checking, or static analysis, but these approaches do not directly protect immutable deployed contracts. The paper therefore motivates runtime defenses for re-entrancy, including attacks that existing tools miss.

  • Existing Defenses: Symbolic execution, model checking, and static analysis are widely used to identify or verify smart-contract vulnerabilities.Examples include Oyente, Mythril, Manticore, Zeus, SmartCheck, and Securify.
  • Runtime Monitoring: ECFChecker dynamically checks whether executions violate the Effectively Callback Free property, but the paper reports an exploitable cross-function contract it failed to detect.The authors describe ECFChecker as the only other runtime monitoring tool known to them at the time.
  • Runtime Monitoring: Sereum proposes a backwards-compatible defense that protects deployed contracts without source code or contract modification.Its runtime focus addresses limitations of offline analysis.
  • Limits of Existing Defenses: Offline defenses help avoid re-entrancy in new contracts but do not directly protect existing contracts whose code is immutable and whose owners may be anonymous.These conditions make patching deployed contracts difficult.
  • Limits of Existing Defenses: Existing approaches may fail to detect all re-entrancy vulnerabilities or produce many false positives.The paper identifies three exploitable patterns: cross-function, delegated, and create-based re-entrancy.

A. Cross-Function Re-Entrancy

Cross-function re-entrancy attacks re-enter a victim through a different function that shares internal state with the initially called function. This can bypass protections guarding the original function and evade some static analyses.

  • A. Cross-Function Re-Entrancy: Cross-function re-entrancy re-enters the same contract through a different function rather than the function originally invoked.The attack exploits interfaces that read or write shared internal state variables.
  • A. Cross-Function Re-Entrancy: In the ERC20-like example, withdrawAll clears etherBalance before an external call but updates tokenBalance afterward.The attacker cannot re-enter withdrawAll, but can re-enter transfer while tokenBalance remains inconsistent.
  • Analysis Limitations: Oyente does not flag the example, whereas Securify and Mythril flag state updates after external calls conservatively without checking whether state becomes inconsistent.The conservative policy produces significant false-positive issues.
  • Analysis Limitations: Static detection is difficult because checking every external call for safety across every function can cause state explosion.ZEUS is cited as omitting cross-function analysis for this reason.
  • A. Cross-Function Re-Entrancy: The attacker can use transfer re-entry to move tokens to another attacker-controlled address despite having no remaining token balance.The figure assumes those tokens can then be exchanged for Ether.

B. Delegated Re-Entrancy

Delegated re-entrancy arises when a contract and library split the external call and state update across contracts, although each appears safe in isolation. The attack exploits DELEGATECALL/CALLCODE-based library execution, motivating runtime detection because offline tools analyze contracts separately or cannot anticipate updated libraries.

  • Delegated re-entrancy: DELEGATECALL or CALLCODE lets a contract invoke another contract’s code in the caller’s execution context.The paper identifies these instructions as the mechanism underlying dynamic library contracts, which share the execution context with their callers.
  • Delegated re-entrancy: The example library exposes send(address,uint256), which transfers Ether through to.call.value(amount)().The victim stores the library address and invokes the library through address(lib).delegatecall with the encoded send signature.
  • Delegated re-entrancy: Victim and Library contracts are safe when analyzed separately but vulnerable when combined in the delegated call chain.Figure 4 presents the upper Solidity source and lower attack call chain; the library is used for sending Ether in this simplified case.
  • Delegated re-entrancy: Delegated re-entrancy emerges when the external call and state update occur in different contracts.In the described pattern, a library performs the improper state update after the contract has already made the external call.
  • Detection: Existing static analysis tools miss delegated re-entrancy because offline analysis does not know which library executes and may not account for future library updates.The paper presents runtime monitoring as one of the few workable means to detect these dynamically composed attacks; ECFChecker analyzes the actual contract-library combination.

C. Create-Based Re-Entrancy

Create-based re-entrancy exploits external calls issued by a newly created contract’s constructor, allowing attackers to re-enter a victim before its state update. Sereum’s dynamic monitoring is designed to detect such execution-flow patterns without requiring contract changes or semantic knowledge.

  • C. Create-Based Re-Entrancy: A constructor can issue external calls after contract creation, enabling re-entry into a victim that updates its state afterward.The victim must create a contract, the constructor must call an attacker-controlled address, and the victim must later update inconsistent internal state.
  • C. Create-Based Re-Entrancy: State-of-the-art tools miss create-based re-entrancy because they do not treat CREATE as an external call or inspect constructor-triggered calls.Detection also requires analyzing the victim and created contract together, even though contract code may change after analysis.
  • IV. DESIGN OF Sereum: Sereum monitors EVM bytecode execution and uses a taint engine plus attack detector to identify suspicious re-entrancy states and abort transactions.The enhanced EVM architecture supports runtime monitoring of actual contract executions.
  • IV. DESIGN OF Sereum: Sereum detects inconsistent state by tracking storage values that influence conditional branches and identifying updates after external calls and re-entry.The relevant inconsistency requires an external call, branch dependence on a storage variable, and an update after the call returns.
  • IV. DESIGN OF Sereum: A dynamic call tree records contract invocations and control-flow-influencing storage sets, enabling selective locking during nested and cross-function re-entry.Sereum avoids locking variables unnecessarily and analyzes cross-function and delegated re-entrancy occurring at runtime.

V. IMPLEMENTATION

Sereum was implemented by extending the geth EVM with runtime taint tracking and re-entrancy attack detection while preserving transparency to executed contracts.

  • V. IMPLEMENTATION: Sereum extends geth’s existing EVM implementation with a taint engine and a re-entrancy attack detector.The implementation is based on the goethereum project.
  • V. IMPLEMENTATION: The modified bytecode interpreter remains transparent to smart contracts and maintains shadow memory separately from actual data values.Shadow memory supports taint storage for Ethereum’s mutable memory regions.

A. Taint Tracking EVM

Sereum’s taint-tracking EVM follows storage-derived data through executed instructions and records when it reaches conditional control-flow decisions.

  • A. Taint Tracking EVM: Dynamic taint tracking assigns labels at defined sources, propagates them with values, and reports when they reach predefined sinks.Sereum uses dynamic rather than static taint analysis for runtime monitoring.
  • A. Taint Tracking EVM: Sereum stores taints in shadow memory for stack and storage data while keeping them separate from actual values.Stack slots and storage words are associated with one or more taints.
  • A. Taint Tracking EVM: The taint engine propagates input taints to instruction outputs as computations execute on the EVM stack machine.This rule applies to computational instructions such as arithmetic and logic operations.
  • A. Taint Tracking EVM: DependsOnStorage taints originate at SLOAD instructions and use conditional JUMPI instructions as sinks for detecting storage-dependent control flow.Each taint records the storage address supplied to SLOAD.
  • A. Taint Tracking EVM: Sereum forwards the recorded storage addresses influencing control-flow decisions to the attack detector after contract execution.These addresses identify storage values relevant to re-entrancy detection.

B. Attack Detection

Sereum detects re-entrancy by combining taint-derived storage dependencies with a dynamic call tree that determines which writes must be locked during nested execution.

  • B. Attack Detection: Sereum records storage addresses influencing control-flow decisions and uses them to compute write-locked variables across a transaction’s call tree.Each call-tree node stores the control-flow-influencing variables identified during that contract execution.
  • B. Attack Detection: Sereum locks only variables used for control-flow decisions during an external call, allowing unrelated state updates to proceed.Selective locking is intended to avoid unnecessary restrictions and false positives.
  • B. Attack Detection: Sereum’s evaluation re-executes Ethereum mainnet transactions and compares findings with tools including Oyente and Securify.Source-code-dependent tools are excluded because source code is rarely available for existing contracts.

A. Run-time Detection of Re-Entrancy Attacks

Sereum replays Ethereum transactions with instruction-level monitoring and taint tracking to detect and invalidate re-entrancy violations. Its evaluation identified actual attacks while exposing coverage and false-positive differences among existing tools.

  • Runtime evaluation: Sereum enables taint tracking during replay and invalidates transactions when an attack pattern is detected.It also returns the instruction trace up to the detection point through the API.
  • Runtime evaluation: 77,987,922 transactions across 4.5 million blocks were replayed, with 49,080 (0.063%) flagged as re-entrancy violations.After grouping identical or alike contracts, the flagged transactions involved 16 contract instances.
  • Runtime evaluation: Manual investigation confirmed two contracts were actually exploited by re-entrancy attacks, including the DAO contract and a lesser-known case.The DAO case accounted for 2,294 attack transactions.
  • Tool comparison: Oyente flagged 8 evaluated contracts, whereas Securify could not evaluate bytecode-only contracts and used a conservative policy that produced many false positives.Securify flagged 5.8% of 24,594 tested contracts in the authors’ cited experiment.
  • Tool comparison: Sereum successfully detected all crafted attack transactions against three vulnerable contracts, while existing tools missed delegated or create-based patterns.Securify, Mythril, and related conservative policies detected some cross-function cases but incurred high false-positive rates or incomplete coverage.
  • Tool comparison: Sereum evaluates actual re-entrancy attacks rather than merely possible vulnerabilities, allowing exact true- versus false-positive assessment on a reduced contract set.The evaluated set contained 16 contracts, compared with 185 for Oyente and 1,426 for Securify.

B. False Positive Analysis

Sereum’s false positives arise from bytecode-level ambiguity and legitimate re-entrancy-like patterns. The analysis identifies field packing, storage deletion, constructor callbacks, tight coupling, and manual locks as important cases.

  • Overall analysis: The identified code patterns are challenging for Sereum and other bytecode-level analysis tools, explaining rare false alarms encountered during evaluation.The paper presents these cases as useful targets for future research on re-entrancy analysis.
  • Field sensitivity: Bytecode-level field aliasing can over-taint unrelated struct fields because Solidity fields may share one EVM storage address.This limitation affects analysis tools operating at the EVM bytecode level and can produce false positives.
  • Storage deallocation: Storage deallocation resembles storing zero at bytecode level, making deletion difficult to distinguish from an ordinary state update.Correct handling requires source code or an explicit EVM deallocation instruction.
  • Constructor callbacks: Constructor callbacks can trigger false positives when a newly created contract re-enters its parent to read state that the parent updates later.Sereum locks the variable even though no malicious external contract is involved and the pattern is not exploitable via re-entrancy in the example.
  • Constructor callbacks: Avoiding constructor callbacks can reduce Sereum false positives and gas costs because external calls are expensive.The paper recommends passing necessary information through the sub-contract constructor instead.
  • Tight contract coupling: Tightly coupled contracts may be re-entered repeatedly across functions, while Sereum lacks knowledge of their underlying trust relationships.This interdependency can make automatically introduced locks appear to match attack patterns.
  • Manual locking: Manual re-entrancy locks are difficult to distinguish from critical state updates at bytecode level and may leave other functions unguarded.Sereum instead introduces locks for potentially dangerous variables across functions using taint tracking.

C. Performance and Memory Overhead

The paper estimates Sereum’s runtime overhead by benchmarking Ethereum block execution against plain geth. The measured overhead is small relative to block time.

  • Runtime overhead: Sereum adds approximately 0.005 seconds to an estimated 0.05-second EVM execution time per block.The estimate is based on benchmark results using sampled blockchain blocks and repeated execution.
  • Runtime overhead: The average interval until the next block is 14.5 seconds, making the measured runtime overhead not noticeable in that comparison.The reported average covers blocks mined between January 1 and August 7, 2018.

VII. RELATED WORK

Related work explores safer contract languages and state-oriented programming models, but deploying new models would require rewriting legacy software. Sereum instead provides runtime protection for existing contracts against basic and advanced re-entrancy attacks without semantic knowledge.

  • Safer programming languages: Related work includes experimental languages designed to improve code clarity and auditing by limiting misleading or complex programming features.Vyper emphasizes human readability, while Babbage uses visual mechanical components to clarify component interactivity.
  • State-oriented models: Bamboo and Obsidian model contracts through explicit states and state transitions to make contract behavior more predictable.Both approaches treat state transitions as central programming constructs.
  • Legacy compatibility: Wide-scale deployment of novel programming models would require rewriting all legacy software, creating significant development effort.This limits the direct applicability of language-based approaches to already deployed contracts.
  • Runtime protection: Sereum complements offline analysis by using runtime monitoring to detect and prevent basic and advanced re-entrancy attacks without semantic knowledge of the contract.Its dynamic taint tracking monitors data flows during execution to identify inconsistent state.
Loading 1812.05934v1…