No Peer, no Cry: Network Application Fuzzing via Fault Injection

TL;DR

Fuzztruction-Net introduces a fault-injection based paradigm for network application fuzzing that preserves the integrity and state of the communication while mutating the behavior of one peer to reveal bugs in the other. By injecting faults directly into a peer’s state-modifying operations, the approach avoids desynchronization and cryptographic constraints that block traditional fuzzers, enabling testing of both client and server components. Across nine real-world targets and a broader set of applications, the method achieves higher coverage and discovers more bugs than state-of-the-art fuzzers, including CVEs in Nginx, Apache, and the OpenSSH client, demonstrating practical impact for hardened network software. The work also provides an open-source prototype and a detailed evaluation methodology that supports reproducibility and cross-implementation analysis, highlighting opportunities for differential and multi-configuration testing in complex protocols.

Abstract

Network-facing applications are commonly exposed to all kinds of attacks, especially when connected to the internet. As a result, web servers like Nginx or client applications such as curl make every effort to secure and harden their code to rule out memory safety violations. One would expect this to include regular fuzz testing, as fuzzing has proven to be one of the most successful approaches to uncovering bugs in software. Yet, surprisingly little research has focused on fuzzing network applications. When studying the underlying reasons, we find that the interactive nature of communication, its statefulness, and the protection of exchanged messages render typical fuzzers ineffective. Attempts to replay recorded messages or modify them on the fly only work for specific targets and often lead to early termination of communication. In this paper, we discuss these challenges in detail, highlighting how the focus of existing work on protocol state space promises little relief. We propose a fundamentally different approach that relies on fault injection rather than modifying messages. Effectively, we force one of the communication peers into a weird state where its output no longer matches the expectations of the target peer, potentially uncovering bugs. Importantly, this weird peer can still properly encrypt/sign the protocol message, overcoming a fundamental challenge of current fuzzers. In effect, we leave the communication system intact but introduce small corruptions. Since we can turn either the server or the client into the weird peer, our approach is the first that can effectively test client-side network applications. Evaluating 16 targets, we show that Fuzztruction-Net outperforms other fuzzers in terms of coverage and bugs found. Overall, Fuzztruction-Net uncovered 23 new bugs in well-tested software, such as the web servers Nginx and Apache HTTPd and the OpenSSH client.

Figures (6)

• Figure 1: High-level overview of Fuzztruction-Net. Notably, the role of weird and target peer is independent of which peer is acting as server or client.
• Figure 2: The coverage (in llvm-cov branches) various fuzzers achieve over ten 24h runs on different targets. We display the median run and 66% intervals.
• Figure 3: Coverage on mosquitto$^{\textrm{S}}$ when enabling TLS support as typical for real-world use. We compute coverage computed only for the target, not the TLS library implementation. TLS stalls SGFuzz but not Fuzztruction-Net.
• Figure 4: Coverage on live555$^{\textrm{S}}$ with HTTP Digest Access Authentication rfc7616 enabled. We still provide replay-based fuzzers with a recording of a successful authentication (HTTP plain text).
• Figure 5: Coverage results for all fuzzers when enabling TLS support, as is often the case in practice. We compute coverage only for the target but not the TLS implementation.