PaperlayerView exact revision on arXiv

Source-linked AI summary

sFuzz: An Efficient Adaptive Fuzzer for Solidity Smart Contracts

Tai D. Nguyen, Long H. Pham, Jun Sun, Yun Lin, Quang Tran Minh

arXiv:2004.08563v1cs.SE

TL;DR

Smart contracts can contain vulnerabilities that are difficult to fix after deployment, creating a need for thorough pre-deployment testing. sFuzz addresses this need with AFL-style feedback-guided fuzzing plus lightweight multi-objective adaptation for hard-to-cover branches, and its evaluation reports faster, broader, and more effective testing than existing fuzzers.

  • Problem

    Smart contracts may contain vulnerabilities and cannot be modified easily after deployment, making thorough pre-deployment testing important.

  • Method

    sFuzz combines AFL-based feedback-guided fuzzing with a lightweight adaptive seed-selection strategy using Solidity-oriented objectives for hard-to-cover branches.

  • Results

    sFuzz was evaluated on more than 4 thousand smart contracts and was reported as faster, more effective, and more reliable than existing fuzzers.

  • Takeaways & Limitations

    sFuzz’s fuzzing strategies complement one another, and its adaptive strategy improves code coverage during prolonged fuzzing.

  • Takeaways & Limitations

    Performance may vary with the initial population, and reported true-positive percentages are approximated from samples of 50 contracts per vulnerability type.

Abstract

from arXiv · show

Smart contracts are Turing-complete programs that execute on the infrastructure of the blockchain, which often manage valuable digital assets. Solidity is one of the most popular programming languages for writing smart contracts on the Ethereum platform. Like traditional programs, smart contracts may contain vulnerabilities. Unlike traditional programs, smart contracts cannot be easily patched once they are deployed. It is thus important that smart contracts are tested thoroughly before deployment. In this work, we present an adaptive fuzzer for smart contracts on the Ethereum platform called sFuzz. Compared to existing Solidity fuzzers, sFuzz combines the strategy in the AFL fuzzer and an efficient lightweight multi-objective adaptive strategy targeting those hard-to-cover branches. sFuzz has been applied to more than 4 thousand smart contracts and the experimental results show that (1) sFuzz is efficient, e.g., two orders of magnitude faster than state-of-the-art tools; (2) sFuzz is effective in achieving high code coverage and discovering vulnerabilities; and (3) the different fuzzing strategies in sFuzz complement each other.

1 INTRODUCTION

Smart contracts can contain vulnerabilities that are difficult to remedy after deployment, motivating automatic pre-deployment testing. sFuzz combines AFL-style feedback-guided fuzzing with a lightweight adaptive strategy and reports strong comparative evaluation results.

  • Motivation: Smart contracts may remain vulnerable after deployment because they cannot be modified easily on the blockchain.The DAO attack illustrates the consequences: remediation required an expensive and controversial hard fork.
  • Problem: Automatic testing must address how to run test cases, what to test, and how to identify vulnerabilities.
  • Approach: sFuzz is a fully automatic, feedback-guided testing engine for Ethereum smart contracts inspired by AFL.
  • Approach: sFuzz combines AFL-based fuzzing with a lightweight adaptive seed-selection strategy targeting branches guarded by strict conditions.Its adaptive strategy uses a Solidity-oriented objective function and multi-objective optimization.
  • Evaluation: Applied to more than 4 thousand smart contracts, sFuzz was more than two orders of magnitudes faster than ContractFuzzer, covered more branches, and revealed more vulnerabilities.The experiments also found that sFuzz and Oyente are complementary and that prolonged adaptive fuzzing improves coverage.

2 ILLUSTRATIVE EXAMPLES

sFuzz illustrates its adaptive fuzzing workflow through Ethereum smart-contract examples. It measures distance to missed branches, selects promising seeds for each objective, and evolves tests until difficult branches and vulnerabilities are exposed.

  • Workflow: sFuzz requires only EVM bytecode and automatically configures a blockchain network, deploys the contract, and generates transaction-based test cases.Transactions execute in an EVM enriched with vulnerability-detection oracles, while execution feedback guides subsequent generation.
  • Single objective example: The quiz-game example contains a Gasless Send vulnerability caused by an unchecked false return when a costly fallback function exceeds the forwarded 2300 gas.The resulting failure lets contract owners retain the reward.
  • Single objective example: sFuzz selects the closest test case as a seed, mutates and repeats generation, and after 140 generations covers the branch and reveals the vulnerability.
  • Single objective example: For a just-missed branch, sFuzz computes a distance from the test case’s observed value to the branch condition and prioritizes smaller distances.In the example, the distance is |msд.value −100| + 1, reaching 1 when msд.value equals 100.
  • Multiple objective example: With multiple missed branches, sFuzz computes a separate distance for each branch and selects one minimum-distance seed per branch.The Figure 2 example uses two arithmetic comparison branches, producing separate seeds for their subsequent coverage.

3 FUZZING SMART CONTRACTS

sFuzz frames smart-contract testing as efficient branch-coverage maximization under limited resources, using feedback-guided adaptive fuzzing to evolve transaction-based test cases. Its strategy combines AFL-inspired evolution with lightweight multi-objective seed selection focused on just-missed branches.

  • 3.1 Problem Definition: A test case pairs an initial blockchain configuration with a sequence of transactions, while branch coverage records whether test cases visit control-flow edges.The configuration includes blockchain state such as block number, timestamp, contract addresses, and balances.
  • 3.1 Problem Definition: sFuzz seeks to maximize covered branches efficiently rather than generate arbitrarily large test suites, because time and process resources are limited.The paper identifies feedback-guided adaptive fuzzing as its solution to this refined optimization problem.
  • 3.2 Feedback-Guided Adaptive Fuzzing: sFuzz initializes a population of transaction-based test cases, adds tests covering new branches to the suite, filters seeds, and creates further tests through crossover and mutation until timeout.The workflow follows an AFL-like iterative evolution process.
  • 3.2 Feedback-Guided Adaptive Fuzzing: sFuzz generates initial tests by calling each public function once after construction, ensuring 100% function coverage before subsequent fuzzing.Function parameters receive random values based on their types, including bounded random lengths for arrays and strings.
  • 3.2 Feedback-Guided Adaptive Fuzzing: For each just-missed branch, sFuzz selects the seed with minimum distance, making its adaptive strategy lightweight and branch-focused.Unlike more expensive approaches that consider all uncovered branches, just-missed branches have already reached the preceding node, so their approximate graph distance is constant.
  • 3.2 Feedback-Guided Adaptive Fuzzing: Existing SBST strategies use more complicated distances and Pareto-optimal seeds, whereas sFuzz avoids complete CFG construction and expensive distance maintenance for Solidity bytecode.The paper attributes this simplification to dynamic EVM jump targets and the efficiency requirements of AFL-based fuzzing.

4 IMPLEMENTATION

sFuzz implements its fuzzing and vulnerability-detection pipeline in three main components around an Ethereum test network and EVM. The implementation constructs CFG information during fuzzing, generates and monitors tests, and applies an extensible oracle library with an explicit Freezing Ether caveat.

  • 4 IMPLEMENTATION: sFuzz is implemented in C++ and comprises runner, libfuzzer, and liboracles components.The tool accepts contract bytecode and ABI as inputs.
  • 4 IMPLEMENTATION: The runner creates a test network, deploys contracts, and executes transactions, including provisioning externally owned accounts for address-type parameters.The account pool has size no greater than the number of address-type parameters.
  • 4 IMPLEMENTATION: libfuzzer solves test generation by implementing the adaptive fuzzing algorithm and constructing the contract CFG on the fly during execution.On-the-fly construction avoids statically resolving dynamic EVM jump targets from bytecode.
  • 4 IMPLEMENTATION: libfuzzer excludes view, pure, and constant functions from generated tests because they do not change contract state or additionally expose the targeted vulnerabilities.These functions are recognized through the ABI.
  • 4 IMPLEMENTATION: liboracles monitors EVM execution events and checks test-case logs against an extensible library of eight vulnerability oracles.The monitored events expose read-only execution data such as stack, memory, program counter, and opcode values.
  • 4 IMPLEMENTATION: sFuzz reports true positives by its vulnerability definitions except for Freezing Ether, where warnings can be false positives if relevant send or transfer tests are not generated.Whether Freezing Ether is absent can only be established by covering all feasible opcodes, which is often infeasible.

5 EXPERIMENTS AND EVALUATION

sFuzz was evaluated on 4,112 Solidity smart contracts against ContractFuzzer and Oyente for efficiency, coverage, vulnerability discovery, and adaptive-strategy usefulness. It generated over 208 test cases per second on average, generally exceeded ContractFuzzer in branch coverage and vulnerability discovery, while its adaptive strategy contributed substantially for most contracts.

  • Experimental setup: The evaluation used 4,112 Solidity smart contracts and compared sFuzz with ContractFuzzer and Oyente using three repeated experiments.Each contract was fuzzed for two minutes in the efficiency experiment, a setting that favored the comparison tools because adaptive fuzzing takes time to become effective.
  • 5.1 Efficiency: sFuzz generated and executed more than 208 test cases per second on average, compared with 0.1 for ContractFuzzer and 16 for Oyente.Efficiency varied across contracts: the top 10% exceeded 989 test cases per second, while the bottom 20% produced fewer than 14.
  • 5.2 Effectiveness: sFuzz covered more branches than ContractFuzzer for 4,077 of 4,112 contracts, whereas ContractFuzzer covered more for 35 contracts.ContractFuzzer’s apparent advantage was partly attributed to counting view-function branches and branches reached by invalid test cases that violate compiler-generated mandatory constraints.
  • 5.2 Effectiveness: sFuzz found vulnerabilities in 1,113 contracts, 24 times more than ContractFuzzer, and found more vulnerable contracts than ContractFuzzer in every category.Manual sampling found false positives in some categories, while all sampled Gasless Send, Exception Disorder, and Reentrancy findings were true positives.
  • 5.3 Adaptiveness: For about 80% of contracts, the adaptive strategy contributed an average of 31% of generated test cases, rising from 18% after 12 seconds to 33% after two minutes on average.The authors conclude that the adaptive strategy is useful for increasing generated-test-suite coverage, and that its effect may become more apparent with longer fuzzing.

6 RELATED WORK AND CONCLUSION

sFuzz is situated among fuzzing, symbolic-execution, formal-verification, and broader smart-contract analysis techniques. The paper concludes that its adaptive EVM fuzzing engine is faster, more reliable, and more effective than existing fuzzers.

  • RELATED WORK: Existing fuzzers and symbolic-execution engines address smart-contract testing through different strategies and have complementary capabilities.ContractFuzzer uses predefined values and vulnerability oracles, while symbolic-execution tools analyze program paths or targeted vulnerabilities.
  • RELATED WORK: Formal-verification approaches verify smart-contract correctness or fairness by translating contracts into verification-oriented representations or using theorem provers.Examples include LLVM-based verification, F*, and Isabelle/HOL.
  • RELATED WORK: Broader smart-contract analysis includes studies of safe-contract development, vulnerability taxonomies, immutable control flows, and gas-cost programming patterns.These works examine both security risks and operational properties of smart contracts.
  • CONCLUSION: sFuzz is presented as an adaptive fuzzing engine for EVM smart contracts, positioned alongside existing fuzzers and complementary symbolic-execution engines.The paper frames sFuzz within multiple strands of smart-contract analysis rather than as a replacement for every technique.
  • CONCLUSION: Experimental results show that sFuzz is significantly more reliable, faster, and more effective than existing fuzzers.The conclusion reports an overall advantage over existing fuzzers without specifying a single aggregate metric here.
Loading 2004.08563v1…