PaperlayerView exact revision on arXiv

Source-linked AI summary

TraceLib: System-Call Bitmap Feedback Mechanism for Language-Agnostic Web Fuzzing

I Putu Arya Dharmaadi, Elias Athanasopoulos, Fatih Turkmen

arXiv:2609.34778v1cs.SE

TL;DR

Language-specific instrumentation makes coverage feedback costly to implement across diverse web runtimes. TraceLib turns selected system-call transitions into bitmap feedback and evaluates it across web applications. Its projected variant exceeds black-box on all eight PHP applications and Native on four, supporting syscall feedback as a runtime-independent guidance proxy.

  • Problem

    Coverage feedback for web fuzzing commonly depends on language- and runtime-specific instrumentation, which is costly to implement and maintain across heterogeneous applications.

    Source: §I · p. 2

  • Method

    TraceLib observes selected system-call transitions, enriches them with bounded argument hashes, and converts them into AFL-like bitmap feedback for a web fuzzer.

    Source: §I · p. 2

  • Results

    TraceLib projected exceeds black-box on all eight PHP WUTs and Native on four, while averaging 11.21% coverage versus Native's 11.15%.

    Source: §I · p. 2

  • Takeaways & Limitations

    Across 16 WUTs spanning six languages, the evaluation supports system-call feedback as a useful runtime-independent proxy for coverage guidance.

    Source: Contributions · p. 2, §I · p. 2

    The authors state that several limitations remain to be addressed in future work.

    Source: §VII · p. 12

Abstract

from arXiv · show

Coverage feedback is an important source of guidance for fuzzing. However, obtaining such feedback normally requires application-level instrumentation that is specific to the language and runtime of the application. Given that modern web applications span multiple languages and runtimes, this application-level instrumentation is costly to implement and maintain. Therefore, we present TraceLib, a system-call feedback mechanism for enabling language-agnostic web fuzzing. Our proposed approach observes the transitions of system calls, enriches selected transitions with bounded argument hashes, and converts them into a 65,536-position AFL-like bitmap. By using the generated bitmap, any web fuzzer can decide whether to retain requests that add previously unseen bitmap positions without consulting application code coverage. We integrate TraceLib into WebFuzz and evaluate it under five WebFuzz feedback modes: the two proposed TraceLib variants (one over every traced system call and one projected onto monitored file paths and recognized SQL buffers), the N-gram comparator adapted from Xiao et al. representing the most recent work to our knowledge, WebFuzz's Native grey-box feedback, and black-box fuzzing without feedback. We evaluate TraceLib on sixteen web applications under test (WUTs): eight PHP applications and eight further applications spanning Node.js, Ruby, Java, Go, and Python to demonstrate platform portability. The results show that our proposed TraceLib projected exceeds black-box on all eight PHP WUTs while exceeding Native on four: Joomla, Drupal, PrestaShop, and Bagisto. In addition, measured on an identical replayed request workload, the tracer costs approximately one millisecond of server-side latency per request. These results indicate that compact system-call feedback is a useful runtime-independent proxy for coverage guidance.

I. INTRODUCTION

Language-specific instrumentation limits web fuzzing across heterogeneous stacks, motivating feedback that preserves guided fuzzing without depending on an application's language or runtime. TraceLib supplies syscall-based feedback; its projected variant beats black-box on all eight PHP applications and Native on four.

I. INTRODUCTION

  • Language- and runtime-specific instrumentation restricts many grey-box web fuzzers to narrow platform ranges and makes consistent instrumentation costly in heterogeneous applications.Source: §I · p. 1
  • TraceLib uses selected syscall transitions and bounded argument hashes as feedback, decoupling guidance from application code and runtime instrumentation.The implementation tracks selected web-server processes, maps transitions to AFL-like bitmaps, and delivers them through POSIX shared memory.Source: §I · p. 2
  • TraceLib projected exceeds black-box on all eight PHP WUTs and exceeds Native on four: Joomla, Drupal, PrestaShop, and Bagisto.Across the eight PHP WUTs, it averages 11.21% coverage versus 11.15% for Native; replayed-request server-side latency is approximately one millisecond per request.Source: §I · p. 2
  • The evaluation compares TraceLib with Native, black-box, and adapted N-gram feedback across 16 WUTs spanning PHP, Go, Python, Ruby, Java, and Node.js.Campaigns use 10 validated GET endpoints, one worker, two hours, and three repetitions, with crawling skipped.Source: Contributions · p. 2, §I · p. 2
  • The paper identifies three practical challenges for syscall feedback: associating calls with HTTP requests, connecting low-level activity to application behavior, and delivering feedback with low latency.Source: Contributions · p. 2

A. Fuzzing

Fuzzing generates and executes inputs, then uses evaluation feedback to guide later inputs; syscall tracing offers an alternative to code instrumentation but presents request-boundary and abstraction-mismatch challenges.

A. Fuzzing

  • Fuzzing iterates through input generation, execution, and evaluation, with evaluation feedback steering subsequent inputs toward new behavior.Source: A. Fuzzing · p. 2

1) Feedback-guided Fuzzing:

  • Feedback-guided fuzzing uses runtime information such as code coverage or state changes to steer inputs toward unexplored behavior; common sources include compiler instrumentation and runtime hooks.Source: 1) Feedback-guided Fuzzing · p. 3

2) Code Coverage and Bitmap File:

  • A coverage bitmap uses a fixed-size byte array, commonly 65,536 bytes, whose entries represent hashed edges or blocks observed during execution.A newly set entry signals novel behavior and can cause the fuzzer to retain the input in its corpus.Source: 2) Code Coverage and Bitmap File · p. 3

B. System Calls

  • A single request may involve dozens to hundreds of system calls, including file, socket, and process operations.The illustrated WordPress trace uses openat as a file-opening cue and sendto as a cue for submitted SQL queries.Source: B. System Calls · p. 3, Figure 1 · p. 3

A. Challenge 1: Trace-Request Association

  • Syscall traces are continuous in long-running web servers, with no inherent OS signal separating the calls for one HTTP request from the next.Without reliable request boundaries, a bitmap cannot reliably represent the execution triggered by a single input.Source: A. Challenge 1: Trace-Request… · p. 3
  • Request-to-process mappings vary across worker-pool, event-driven, and hybrid server architectures, complicating any fixed trace-association strategy.Source: A. Challenge 1: Trace-Request… · p. 3

B. Challenge 2: Information Mismatch

C. Challenge 3: Result Delivery

TraceLib aggregates system-call activity into per-request bitmaps and returns them to the fuzzer without modifying the application. Its design resolves target processes, records syscall transitions, and associates feedback with requests.

C. Challenge 3: Result Delivery

IV. PROPOSED APPROACH

  • TraceLib provides language-agnostic per-request feedback without modifying the web application’s source code or runtime interpreter.It guides fuzzers toward requests that produce previously unexplored bitmap positions.Source: §IV · p. 4

A. TraceLib Overview

  • A Port-to-PID Resolver, Tracer, Bitmap Builder, and Request Demultiplexer form TraceLib’s request-to-feedback workflow.The fuzzer supplies the target port and a request-identifier header name; TraceLib returns per-request bitmaps.Source: A. TraceLib Overview · p. 4

B. Target Process Discovery

  • TraceLib discovers server processes by matching listening socket inodes to file descriptors, then tracks their process-level identifiers through eBPF tracepoints.Filtering by TGID covers all threads, and child processes created through clone, fork, or vfork are added to the target map.Source: B. Target Process Discovery · p. 5

C. Tracing and Behavioral Monitoring

  • Each syscall transition receives a 16-bit ID and updates one of 65,536 saturating counters; concatenation avoids immediate collisions that XOR can create for dense syscall numbers.Eight-bit syscall-number components include an eight-bit argument hash when the call has a useful argument.Source: C. Tracing and Behavioral Monitoring · p. 5

1) Argument-Selective System-Call Transitions:

TraceLib adds selected argument hashes to syscall transitions to distinguish web-request behavior. It limits the hashed information to stable, meaningful file paths and SQL statements, filtering and canonicalizing paths to reduce execution-to-execution noise.

1) Argument-Selective System-Call Transitions:

  • Syscall transitions alone are too coarse for web workloads, so TraceLib hashes selected file-path and SQL-statement arguments that are meaningful and stable across repeated requests.The hash is included in the transition ID for calls carrying those arguments.Source: 1) Argument-Selective System-Call… · p. 5
  • For file-opening or file-execution calls, TraceLib hashes the filtered path; for SQL-writing calls, it hashes a compact query encoding; other calls receive a zero argument hash.The one-byte hash uses djb2.Source: 1) Argument-Selective System-Call… · p. 5

2) File Path Filtering and Canonicalization:

  • TraceLib hashes paths only after monitoring-root and exclusion rules, then replaces numeric or sufficiently distinctive dynamic components with # to suppress path noise.The default monitored root is /var/www, and the default excluded component is temp.Source: 2) File Path Filtering and… · pp. 5–6

3) Compact SQL Query Encoding:

TraceLib reduces SQL queries to commands and table names, then offers alternative feedback modes and an N-gram comparator. It associates each bitmap with an HTTP request using an identifier carried in a custom header.

3) Compact SQL Query Encoding:

  • Compact SQL encoding extracts commands and table names rather than full query text, avoiding value-dependent hashes that would make repeated operations appear novel.The alternative of removing only user values is difficult when values appear in varied positions or nested-variable construction changes query text.Source: 3) Compact SQL Query Encoding · p. 6

4) Two TraceLib Modes:

  • TraceLib plain includes all syscalls, while TraceLib projected records only calls with nonzero argument hashes to focus on semantically meaningful resources.The projected mode is intended to approximate application-level behavior through file and SQL activity.Source: 4) Two TraceLib Modes · p. 6

5) N-Gram Comparator:

  • The adapted N-gram comparator uses four- and eight-token windows, hashing tokens that combine syscall numbers with argument hashes.It shares TraceLib’s tracing framework and differs in how observed syscall behavior is represented as feedback.Source: 5) N-Gram Comparator · p. 6

D. Request Demultiplexing

  • TraceLib associates each bitmap with an HTTP request by scanning for a unique identifier in request and response payloads, then saving the finalized bitmap under that identifier.The fuzzer retrieves the bitmap from /dev/shm by request identifier.Source: D. Request Demultiplexing · pp. 6–7

1) Non-concurrent Request Requirement:

TraceLib associates feedback with requests through request identifiers and explicit recording boundaries, while requiring sequential request processing for reliable attribution. It aggregates completed bitmaps in-kernel and uses WebFuzz as its whole-application base.

1) Non-concurrent Request Requirement:

  • TraceLib requires at most one request to be processed at a time because concurrent requests can mix syscall transitions in one bitmap and prevent reliable per-request attribution.This matches the isolated-execution model of common binary fuzzers such as AFL.Source: 1) Non-concurrent Request Requirement · p. 7

2) Alternative Prefork-Child Association:

  • Apache prefork-child association permits concurrent requests but depends on a master-worker server model, making it unsuitable for Node.js’s single-process asynchronous event loop.TraceLib instead chooses in-band request identifiers with non-concurrent processing as its more broadly applicable design.Source: 2) Alternative Prefork-Child Association · p. 7

3) Start-Stop Syscall Recording:

  • TraceLib starts a bitmap when it detects a request ID and finalizes it at the first HTTP/1 status line, after 500 ms of server-wide inactivity, on a new ID, or at process shutdown.A repeated ID leaves the active request unchanged.Source: 3) Start-Stop Syscall Recording · p. 7

E. In-Kernel Aggregation and Bitmap Delivery

  • A double-buffered eBPF map lets the kernel collect one request’s feedback while userspace processes the other completed bitmap, which is copied to /dev/shm.Each half holds a 65,536-byte bitmap.Source: E. In-Kernel Aggregation and Bitmap… · p. 7

V. AGNOSTIC WEB FUZZER FRAMEWORK

  • The framework combines TraceLib feedback with an existing coverage-guided web fuzzer, modifying its instrumentation to use the new feedback.WebFuzz was selected as the whole-application base because it explores multiple endpoints in a shared session, matching the study’s focus on realistic application-wide coverage.Source: §V · p. 7, A. Rationale for a Whole-Application… · p. 7

A. Rationale for a Whole-Application Base

  • Whole-application fuzzers dynamically crawl endpoints, maintain a multi-handler request corpus, and allocate effort using accumulated coverage feedback.This contrasts with per-endpoint fuzzers, which exercise a single URL or script independently.Source: A. Rationale for a Whole-Application… · p. 7

B. WebFuzz Architecture

WebFuzz mutates HTTP requests and retains those that reveal new coverage, but its original AST instrumentation is tied to PHP and rewritable source code. TraceLib replaces that feedback mechanism while leaving the rest of the fuzzer unchanged; the evaluation compares this approach with Native, black-box, and N-gram feedback.

B. WebFuzz Architecture

  • WebFuzz seeds its corpus by crawling endpoints, then mutates request parameters and payloads, retaining requests that expose unseen coverage.Corpus selection also weights requests by their historical contribution to coverage growth.Source: B. WebFuzz Architecture · pp. 7–8
  • Original WebFuzz relies on AST-level instrumentation, limiting it to PHP applications with available, rewritable source code.Source: B. WebFuzz Architecture · p. 8

C. Integrating TraceLib with WebFuzz

  • TraceLib replaces WebFuzz’s AST coverage collection with per-request bitmaps, while the fuzzer’s corpus updates and subsequent iterations remain unchanged.WebFuzz retrieves each bitmap by request identifier and compares it with a global bitmap.Source: C. Integrating TraceLib with WebFuzz · p. 8

VI. EVALUATION

  • The evaluation asks whether TraceLib can guide code coverage, agree with coverage tools, limit overhead, and work across platforms.Source: §VI · p. 8

A. Evaluation Setup

  • Five feedback modes compare Native instrumentation, TraceLib plain and projected, an N-gram comparator, and black-box fuzzing without feedback.Native requires source access and is available only for PHP applications in WebFuzz.Source: A. Evaluation Setup · p. 8

1) WUT Selection:

Across eight PHP applications, TraceLib projected and Native achieve comparable coverage, with each leading on four applications. The study uses platform-specific coverage oracles and controlled WebFuzz campaigns to assess the comparison.

1) WUT Selection:

  • The 16 WUTs span PHP, Go, Python, Ruby, Java, and Node.js, with PHP applications comprising half the set.PHP enables more detailed comparison because WebFuzz includes AST-level instrumentation for that platform.Source: 1) WUT Selection · p. 8

2) Code Coverage Oracle:

  • PHP coverage uses WebFuzz’s edge counter, while non-PHP coverage uses runtime tools that primarily record executed lines and are not directly equivalent.The PHP edge counter records transitions between code blocks.Source: 2) Code Coverage Oracle · p. 8

3) Fuzzer Setup:

  • Each campaign uses one worker and receives the same ten authenticated GET seeds, validated with HTTP 200 responses, for a 7,200-second fuzzing period.Crawling is skipped to remove endpoint discovery as a confound.Source: 3) Fuzzer Setup · p. 8, B. RQ1: Code Coverage · p. 8

4) Experiment Environment:

  • Experiments run on an Intel Core i7-6700 host with 32 GiB RAM and Ubuntu 26.04 LTS; WebFuzz runs in a Python 3.12.13 environment.Source: 4) Experiment Environment · p. 8

1) Overall Coverage:

  • 11.21% versus 11.15% coverage: TraceLib projected and Native are tied across eight PHP WUTs, with each leading on four.TraceLib plain averages 11.10%; the differences are not significant, within approximately 0.07 percentage points.Source: Figure 5 · p. 9, 1) Overall Coverage · p. 9

B. RQ1: Code Coverage

  • Figure 5 reports five feedback modes over two-hour PHP campaigns, with each campaign repeated three times because fuzzing is non-deterministic.Source: Figure 5 · p. 9

2) TraceLib nGram Comparison:

TraceLib’s N-gram comparator transfers poorly to web workloads, where variable system-call streams make requests appear distinct. Separately, TraceLib projected shows strong pairwise agreement with platform-specific coverage tools across the request dataset.

2) TraceLib nGram Comparison:

  • TraceLib call feedback transfers poorly to web workloads, is its weakest of three modes, and is the only feedback source worse than no feedback, reaching 19.60% on WordPress versus black-box’s 19.96%.Source: 2) TraceLib nGram Comparison · p. 9
  • TraceLib nGram encodes the identity and order of four or eight consecutive calls, unlike TraceLib plain’s two-call transitions or projected transitions carrying relevant arguments.Source: 2) TraceLib nGram Comparison · p. 9
  • Figure 6 shows TraceLib plain and projected achieving coverage similar to Native; Figure 7 shows projected keeping the smallest corpus while N-gram resembles black-box.Source: Figure 6 · p. 10, Figure 7 · p. 10
  • Variable runtime calls can make identical WordPress requests produce different N-gram bitmaps, so nearly every request appears distinct and the corpus grows like black-box.The example identifies newfstatat calls as runtime or web-environment activity that varies across identical requests.Source: 2) TraceLib nGram Comparison · p. 10

1) Methodology:

3) Results:

  • Across the dataset, TraceLib projected achieved over 94% true-positive rate and 11% false-positive rate in coverage equivalence to ground-truth coverage, showing strong consistency despite operating at a lower abstraction level than code instrumentation.Source: 3) Results · p. 10

4) Small Negative Class:

Across non-PHP applications, TraceLib’s coverage advantage over black-box is modest and the reference oracles are coarser than PHP’s. Replayed-request measurements show small average tracing overhead, while dataset imbalance and platform-specific coverage-tool crashes constrain parts of the evaluation.

4) Small Negative Class:

  • The request-pair dataset is imbalanced toward positive pairs, and non-PHP applications were limited to fewer requests because their coverage tools crash when repeatedly measuring large request sets.Pairs are negative only when both requests receive the same coverage result.Source: 4) Small Negative Class · p. 10, Table III · p. 11

5) False Positives on non-PHP WUTs:

  • Non-PHP false-positive rates exceed 50% on Gogs and Roller partly because their line-based oracles miss execution-order and repetition differences that syscall transitions can distinguish.Source: 5) False Positives on non-PHP WUTs · p. 11

D. RQ3: Time Overhead

  • 0.81 ms mean overhead per request, or 4.5% of black-box baseline, across 48 TraceLib campaigns; WordPress and PrestaShop reach 24.2 ms and 17.6 ms.A few campaigns measure below the black-box baseline because server runtime state and environment vary between runs.Source: D. RQ3: Time Overhead · p. 11, Figure 8 · p. 12

E. RQ4: Portability

  • TraceLib slightly exceeds black-box on five non-PHP WUTs, ties on two, and falls marginally behind on Wiki.js across Node.js, Ruby, Java, Go, and Python.Source: E. RQ4: Portability · pp. 11–12

VII. LIMITATIONS

TraceLib’s limits arise from request attribution, how much application behavior reaches the system-call boundary, and whether database traffic is encrypted. The related work also illustrates the varying levels of application or runtime modification required by existing fuzzers.

A. Single Active Request

  • Overlapping requests can cause syscall misattribution, preventing reliable multi-client throughput measurements and risking missed concurrency-dependent bugs.TraceLib aggregates observations into one bitmap for the active request; a second request can replace or finalize that record.Source: A. Single Active Request · p. 12

B. Dependence on Application Externalization

  • In-memory user-space computation may not cross a syscall boundary, while Native’s AST instrumentation can observe execution at instrumented code branches.Recording more syscalls with TraceLib plain does not necessarily improve behavioral discrimination.Source: B. Dependence on Application… · p. 12
  • TraceLib projected’s TPR ranges from approximately 58% to 99%; Redmine is lowest because SQLite processes SQL inside the application rather than exposing it in syscall traces.Per-language coverage-over-time graphs were omitted because their counters crashed under per-minute polling; each was queried once at campaign end.Source: B. Dependence on Application… · p. 12, Figure 9 · p. 13

C. Reduced Effectiveness on Encrypted Connections

  • TLS-encrypted database connections hide SQL text at the syscall boundary, preventing TraceLib projected from using SQL statements as feedback.In a controlled fuzzing setup, developers can disable database TLS so SQL statements cross the boundary in plain text.Source: C. Reduced Effectiveness on Encrypted… · p. 13

A. Intrusive Modifications

  • WebFuzz modifies PHP source, Witcher modifies interpreters and external components, while Phuzz and Atropos keep instrumentation within the PHP interpreter.Grey-box fuzzing of interpreted-language web applications also faces instrumentation, state-handling, and input-structure challenges.Source: A. Intrusive Modifications · p. 13, §VIII · p. 13

B. Non-Intrusive Approaches

The related work contrasts system-call feedback with database-only and binary-oriented approaches, and distinguishes full-application fuzzing from API-format-focused tools. The conclusion reports TraceLib projected’s coverage and corpus-growth results while identifying concurrency and application externalization as future-work concerns.

B. Non-Intrusive Approaches

  • SQLiFuzz limits feedback to database activity, whereas TraceLib observes file and network interactions; TraceLib nGram adapts Xiao et al.’s SPC for web fuzzing.SPC was designed for whole-program binary execution; TraceLib must associate calls with individual HTTP requests in a long-running server.Source: B. Non-Intrusive Approaches · pp. 13–14

C. Specialized Formats

  • BackREST, RESTler, and related tools focus primarily on REST APIs and often require OpenAPI specifications, unlike full-application fuzzers targeting dynamically structured web pages [10, 1, 18, 25, 5, 12].Source: C. Specialized Formats · p. 14

IX. CONCLUSION

  • Across eight PHP and eight non-PHP WUTs, TraceLib projected achieves coverage and corpus growth comparable to Native and substantially outperforms black-box on PHP WUTs.Future work includes addressing the non-concurrent request requirement and dependence on application externalization.Source: §IX · p. 14
Loading 2609.34778v1…