Fuzzing is an industry-standard software testing technique that uncovers bugs in a target program by executing it with mutated inputs. Over the lifecycle of a fuzzing campaign, the fuzzer accumulates inputs inducing new and interesting target behaviors, drawing from these inputs for further mutation and generation of new inputs. This rapidly results in a large pool of inputs to select from, making it challenging to quickly determine the "most promising" input for mutation. Reinforcement learning (RL) provides a natural solution to this seed scheduling problem---a fuzzer can dynamically adapt its selection strategy by learning from past results. However, existing RL approaches are (a) computationally expensive (reducing fuzzer throughput), and/or (b) require hyperparameter tuning (reducing generality across targets and input types). To this end, we propose T-Scheduler, a seed scheduler built upon multi-armed bandit theory to automatically adapt to the target. Notably, our formulation does not require the user to select or tune hyperparameters and is therefore easily generalizable across different targets. We evaluate T-Scheduler over 35 CPU-yr fuzzing effort, comparing it to 11 state-of-the-art schedulers. Our results show that T-Scheduler improves on these 11 schedulers on both bug-finding and coverage-expansion abilities.

Coverage-guided greybox fuzzers rely on control-flow coverage feedback to explore a target program and uncover bugs. Compared to control-flow coverage, data-flow coverage offers a more fine-grained approximation of program behavior. Data-flow coverage captures behaviors not visible as control flow and should intuitively discover more (or different) bugs. Despite this advantage, fuzzers guided by data-flow coverage have received relatively little attention, appearing mainly in combination with heavyweight program analyses (e.g., taint analysis, symbolic execution). Unfortunately, these more accurate analyses incur a high run-time penalty, impeding fuzzer throughput. Lightweight data-flow alternatives to control-flow fuzzing remain unexplored. We present datAFLow , a greybox fuzzer guided by lightweight data-flow profiling. We also establish a framework for reasoning about data-flow coverage, allowing the computational cost of exploration to be balanced with precision. Using this framework, we extensively evaluate datAFLow across different precisions, comparing it against state-of-the-art fuzzers guided by control flow, taint analysis, and data flow. Our results suggest that the ubiquity of control-flow-guided fuzzers is well-founded. The high run-time costs of data-flow-guided fuzzing (~10 × higher than control-flow-guided fuzzing) significantly reduces fuzzer iteration rates, adversely affecting bug discovery and coverage expansion. Despite this, datAFLow uncovered bugs that state-of-the-art control-flow-guided fuzzers (notably, AFL++) failed to find. This was because data-flow coverage revealed states in the target not visible under control-flow coverage. Thus, we encourage the community to continue exploring lightweight data-flow profiling; specifically, to lower run-time costs and to combine this profiling with control-flow coverage to maximize bug-finding potential.

This Replicating Computational Report (RCR) describes (a) our datAFLow fuzzer and (b) how to replicate the results in “ datAFLow : Toward a Data-Flow-Guided Fuzzer.” Our primary artifact is the datAFLow fuzzer. Unlike traditional coverage-guided greybox fuzzers—which use control-flow coverage to drive program exploration— datAFLow uses data-flow coverage to drive exploration. This is achieved through a set of LLVM-based analyses and transformations. In addition to datAFLow , we also provide a set of tools, scripts, and patches for (a) statically analyzing data flows in a target program, (b) compiling a target program with the datAFLow instrumentation, (c) evaluating datAFLow on the Magma benchmark suite, and (d) evaluating datAFLow on the DDFuzz dataset. datAFLow is available at https://github.com/HexHive/datAFLow.

The popularity of coverage-guided greybox fuzzers has led to a tsunami of security-critical bugs that developers must prioritize and fix. Knowing the capabilities a bug exposes (e.g., type of vulnerability, number of bytes read/written) enables prioritization of bug fixes. Unfortunately, understanding a bug's capabilities is a time consuming process, requiring (a) an understanding of the bug's root cause, (b) an understanding how an attacker may exploit the bug, and (c) the development of a patch mitigating these threats. This is a mostly-manual process that is qualitative and arbitrary, potentially leading to a misunderstanding of the bug's capabilities.

Mutation-based greybox fuzzing---unquestionably the most widely-used fuzzing technique---relies on a set of non-crashing seed inputs (a corpus) to bootstrap the bug-finding process. When evaluating a fuzzer, common approaches for constructing this corpus include: (i) using an empty file; (ii) using a single seed representative of the target's input format; or (iii) collecting a large number of seeds (e.g., by crawling the Internet). Little thought is given to how this seed choice affects the fuzzing process, and there is no consensus on which approach is best (or even if a best approach exists).

JavaScript is a popular attack vector for releasing malicious payloads on unsuspecting Internet users. Authors of this malicious JavaScript often employ numerous obfuscation techniques in order to prevent the automatic detection by antivirus and hinder manual analysis by professional malware analysts. Consequently, this paper presents SAFE-DEOBS, a JavaScript deobfuscation tool that we have built. The aim of SAFE-DEOBS is to automatically deobfuscate JavaScript malware such that an analyst can more rapidly determine the malicious script's intent. This is achieved through a number of static analyses, inspired by techniques from compiler theory. We demonstrate the utility of SAFE-DEOBS through a case study on real-world JavaScript malware, and show that it is a useful addition to a malware analyst's toolset.

Coverage‐based fuzz testing and dynamic symbolic execution are both popular program testing techniques. However, on their own, both techniques suffer from scalability problems when considering the complexity of modern software. Hybrid testing methods attempt to mitigate these problems by leveraging dynamic symbolic execution to assist fuzz testing. Unfortunately, the efficiency of such methods is still limited by specific program structures and the schedule of seed files. In this study, the authors introduce a novel lazy symbolic pointer concretisation method and a symbolic loop bucket optimisation to mitigate path explosion caused by dynamic symbolic execution in hybrid testing. They also propose a distance‐based seed selection method to rearrange the seed queue of the fuzzer engine in order to achieve higher coverage. They implemented a prototype and evaluate its ability to find vulnerabilities in software and cover new execution paths. They show on different benchmarks that it can find more crashes than other off‐the‐shelf vulnerability detection tools. They also show that the proposed method can discover 43% more unique paths than vanilla fuzz testing.

This paper presents the design, implementation and evaluation of an automated method for distributing symmetric cryptographic keys in a Wireless Sensor Network (WSN). Unlike previous methods for key distribution in WSNs, we do not rely on sensitive knowledge to be stored in program memory prior to network deployment. Additionally, the protocol proposed uses dominant security primitives to ensure strong security and interoperability with existing networks (such as the Internet), while operating independent of the network layer protocol. Through both hardware experimentation and simulation, we show that this protocol can provide strong confidentiality, integrity and authenticity protection to the symmetric keys as they are distributed throughout a network, while maintaining the ability to scale to large-size networks and remain energy efficient.