Background

Since the beginning of computer software development, software quality has become an inevitable issue in the field of software testing. In order to more efficiently identify software defects (commonly known as bugs), Fuzzer (fuzz testing tool) appeared, but objectives of the usage of a fuzzer in different areas are different:

• QA-oriented fuzz testing, i.e. detect bugs and fixing them

• Security-oriented fuzz testing, i.e. detect bugs and to figure if its exploitable

In terms of technical architecture/implementation, there are currently two main types of Fuzzer for the Linux/Android kernel:

• Fuzzer for system calls, such as Trinity

• Code coverage-guided fuzzer, such as syzkaller

Trinity was the most popular fuzzing tool for Linux kernel in the early 2010s. It tests system calls based on rules using a combination of system calls and random parameters with certain ranges. Its in-depth exploration of code paths was not ideal, and trinity was the only option back then. It's hard to achieve a wider coverage of each subsystem in the kernel even the hard-coded customization have been used. In February 2015, KASAN merged into the Linux kernel, which is a project from Google. This is the cornerstone for the code coverage-guided fuzzer syzkaller. Many security researchers and QA engineers had begun to experiment with syzkaller in early 2016.

The problem

Syzkaller as a general fuzzer solution can work well with Linux kernel mainline development after several years of improvment. But in-depth exploration of specific subsystems is far from meeting the high stability requirements of industry customers. Finance, ICS (Industrial Control System), Automotive, Cloud computing and other industries may have to deal with some issues under such circumstances:

• The 3rd-party kernel code or module are introduced, which are often a high-risk areas for security vulnerabilities and can be used for security analysis through reverse engineering, even if it is not open source

• The field-specific applications rely on the code path in a particular kernel subsystem and the generic QA approach cannot reach its code coverage in the “acceptable” time

• Incomplete regression testing in application, i.e. the vendor of the application usually do not complete the basic test of kernel stability

Our solution: VaultFuzzer

HardenedVault developed a state-based target directed fuzzer “VaultFuzzer” for Linux kernel based on those requirements above. VaultFuzzer is compatible with the existing syzkaller framework, with the greatest advantage of being able to correlate the customer's application with specific kernel subsystems, and such fuzz testing can provide greater stability to the production system. The key features are:

• The target function address is obtained through static analysis of LLVM IR, assembly code, and the kernel image, while attachments to weighted PCs can be obtained based on CFG of the LLVM IR process, all of which are used by VaultFuzzer.

• Coverage filter, concentrating targets to subsystem, file, and code block to prevents calculations from being wasted on exploration outside of the targets.

• Weighted PCs, to construct the unbalanced weighting system based on CFG and different weights are assigned to different code blocks to guide the direction of the testing.

• Kernel state mode, CLANG/LLVM instrumentation was introduced, in which the state of bug-triggering can be recorded as a test case to map the real state of code path more efficiently in a more complex context, while compatibility with the corpus is essentially a space-for-time approach, avoiding the unacceptable performance overhead, such as formal verification methods.

• Support CLANG/LLVM 10/11/12

(Roughly) Test results: VaultFuzzer and Syzkaller

• Fuzzing in CPU time: 100 hrs
• Time in physical world: 6 hrs 40 mins
• Hardware: 32-core + 64GB RAM
• syzkaller (Aug 2021): Default policy
• VaultFuzzer (Mar 2021): Coverage-filter enabled only

From the results, TCP and SCTP in VaultFuzzer is looking good because they're closer to syzbot/CI. Please noted that syzbot/CI constantly update (add the new corpus if hits new code coverage and vice versa) the corpus, but the total cumulative time is more than 2 years while we only run for less than 7 hrs. Vaultfuzzer would perform better if it had a state-based test of finer-grained subsystems, such as SCTP.

Conclusion

Fuzzing has long been critical to software testing and security, with the software tester usually only focus on identifying bugs as quickly as possible to improve system stability, while the security engineers are divided into:

• Offensive side, to identify the exploitable bug and weaponizing 0day exploit in time
• Defensive side, to identify all bugs (whether they are exploitable ones or not) and fix them as quickly as possible to improve the stability and security of the system

NIST issued [Guidelines on Minimum Standards for Developer Verification of Software](https://www.nist.gov/system/files/documents/2021/07/13/Developer Verification of Software.pdf) in response to executive order EO 14028 in July 2021. Fortunately, “Run a fuzzer” and “Regressional test” are on the list. This will make up for the industry's long-standing lack of attention to fuzzer related to the production system. In terms of technology trends, Microsoft's security team also believes that state-based fuzzer is a trend in the future

VaultFuzzer is also used for VED (Vault Exploit Defense) to ensure the stability of the kernel protection module. HardenedVault is the only solution provider of Linux kernel state-based fuzzer in Asia at the moment.