HFL: Hybrid Fuzzing on the Linux Kernel

Abstract

Hybrid fuzzing, combining symbolic execution and fuzzing, is a promising approach for vulnerability discovery because each approach can complement the other. However, we observe that applying hybrid fuzzing to kernel testing is challenging because the following unique characteristics of the kernel make a naive adoption of hybrid fuzzing inefficient: 1) having indirect control transfers determined by system call arguments, 2) controlling and matching internal system state via system calls, and 3) inferring nested argument type for invoking system calls. Failure to handling such challenges will render both fuzzing and symbolic execution inefficient, and thereby, will result in an inefficient hybrid fuzzing. Although these challenges are essential to both fuzzing and symbolic execution, to the best of our knowledge, existing kernel testing approaches either naively use each technique separately without handling such challenges or imprecisely handle a part of challenges only by static analysis. To this end, this paper proposes HFL, which not only combines fuzzing with symbolic execution for hybrid fuzzing but also addresses kernel-specific fuzzing challenges via three distinct features: 1) converting indirect control transfers to direct transfers, 2) inferring system call sequence to build a consistent system state, and 3) identifying nested arguments types of system calls. As a result, HFL found 24 previously unknown vulnerabilities in recent Linux kernels. Additionally, HFL achieves 15% and 26% higher code coverage than Moonshine and Syzkaller, respectively, and over kAFL/S2E/TriforceAFL, achieving even four times better coverage, using the same amount of resources (CPU, time, etc.). Regarding vulnerability discovery performance, HFL found 13 known vulnerabilities more than three times faster than Syzkaller. 1 The discussion throughout this paper particularly focuses on the Linux kernel, but most of descriptions and knowledge can be generally applied to other kernels as well. If not mentioned specifically, the kernel implicates the Linux kernel in this paper.

Exploratory Review of Hybrid Fuzzing for Automated Vulnerability Detection

“…Therefore, a significant problem is determining how to produce sufficient testinputs. As mentioned in Section IV, there are two approaches in the test-input generation for fuzzers: a mutation-based approach which produces test-inputs according to the random mutation of the test-input files, or the use of predefined L Intriguer [140] L [141] AutoDES [142] L SHFuzz [143] L HFL [144] L FIoT [145] L BugMiner [146] L…”

“…al. [118] FAS [126] SymFuzz [130] Taintscope [44] HFL [144] Badger [122] HyDiff [123] Pak et. al [39] Eclipser [137] Saad et.…”

“…fuzzer's efficiency owing to the OS reboot. The introduction of the first kernel hybrid fuzzer by HFL [144] proved a significant contribution to kernel bug detection. It was constructed on top of the existing fuzzing tool known as named Syzkaller [181] and the SE engine, S2E.…”

PSOFuzzer: A Target-Oriented Software Vulnerability Detection Technology Based on Particle Swarm Optimization

“…In contrast to non-oriented fuzzing, coverage-oriented fuzzing [9][10][11][12][13] can use lightweight instrumentation to obtain the runtime information of the program to effectively guide the fuzzing process to pursue high coverage in control flow graph (CFG). For example, by selecting the sample with a new edge as the seed sample for the next round of mutations, the execution of the sample will have a greater possibility of obtaining high coverage [9][10][11]; coverage-oriented fuzzing can also use heavyweight instrumentation to perform dynamic symbol execution [14][15][16][17][18][19][20][21]. This approach transforms external data into symbols to participate in the execution, collects the symbol expressions at each program node, and generates samples that try to execute the full path by solving the expressions.…”

“…Coverage-oriented fuzzing [9][10][11][12][13][14][15][16][17][18][19][20][21][23][24][25][26][27][28] increases the probability of triggering vulnerabilities by executing code blocks or paths as much as possible. However, it causes a large quantity of computational resources to be allocated to code that does not have vulnerabilities.…”