DOSS Bare-Metal Firmware Fuzzing

By Karsten Isakovic, Ramon Barakat, Sascha Hackel, and Martin Schneider, Fraunhofer FOKUS

The Component Tester [1] developed in DOSS is capable of testing not only software that runs on traditional operating systems, but also software designed for IoT and embedded devices. Such software typically operates as self-contained firmware, commonly referred to as “bare metal”, due to the constraints on available code and data size of these devices. Limited observability and debugging capabilities can pose significant challenges during the testing phase. With the increasing prevalence of these devices and their integration into various IoT environments, the threat landscape posed by security vulnerabilities is also growing, resulting in a rising demand for methods to identify vulnerabilities.

Bare-metal fuzz firmware testing is an effective and widely used software testing technique designed to uncover vulnerabilities in embedded devices. One common approach involves running the firmware in an emulator, which allows the fuzzer to feed data into the input channels and monitor the device’s responses without the need for the actual physical hardware, its associated sensors or real input devices. By systematically mutating the input data, the fuzzer can achieve comprehensive coverage of the software’s execution paths to reach unusual and rarely covered system states, thereby uncovering potential vulnerabilities.

Bare-metal firmware fuzzing, however, comes with its own set of challenges. One significant limitation is the lack of sanitizers, which are commonly used in other fuzzing approaches. Sanitizers like AddressSanitizer (ASan) are specifically designed to reliably detect and report memory access errors, such as buffer overflows or use-after-free bugs.

In the context of bare-metal fuzzing, these sanitizers cannot be directly employed because they typically rely on runtime environments or operating system features that are absent in bare-metal systems. As a result, identifying memory access errors becomes significantly more difficult.

DOSS firmware fuzzing approach

Overview

Firmware fuzzing is an integral part of the Component Tester [1], designed to assess the security and reliability of IoT devices from third-party vendors. The solution developed by the DOSS project introduces a significant advancement in the field of bare-metal firmware fuzzing by implementing a Sanitizer Extension for firmware fuzzers, inspired by AddressSanitizer (ASan). This Sanitizer Extension bridges the gap between the lack of traditional fuzzing tools and the need for precise memory error detection in bare-metal environments.

The DOSS bare-metal firmware fuzzer incorporates metadata obtained from static software analysis of the firmware into its fuzzing process to enhance its ability to detect a wider range of memory corruptions and increases the likelihood of uncovering critical vulnerabilities that may otherwise go unnoticed.

Figure 1: DOSS Firmware Fuzzer Block Diagram

Figure 1 provides an overview of the DOSS Firmware fuzzer, the results of the static analysis of the firmware are forwarded into the sanitizer extension of the fuzzer. The fuzzer controls and inspects the executions of the firmware in the emulator, it feeds input data into the firmware and observes the reactions. The extracted static analysis information regarding the layout and usage of global variables, the address ranges of functions, and their parameters and associated variables serves as the foundation for identifying memory access errors that are typically not addressed by standard bare-metal fuzzers. The sanitizer extension of the DOSS bare-metal firmware fuzzer can detect unauthorized access to global and stack variables, the techniques developed could be extended to monitor heap memory access.

Access control for global variables

Memory access to global variables is restricted to the code blocks and access method identified during the analysis. To further improve the detection of off-by-one access errors associated with global variables, the firmware can be binary rewritten to insert redzones between these variables.

Figure 2: Memory rewriting with added red zones

The left side of Figure 2 depicts adjacent global variable memory accesses originating from specific code locations within the firmware binary. Conversely, the right side illustrates the rewritten firmware binary, where the references point to new memory locations with red-zones inserted between the variables. In case the static analysis missed a reference, accessing the original memory location during the execution of the firmware is forwarded to the updated location.

Access control for stack variables

By monitoring changes in the emulated program counter and stack pointer register each time a new code block is entered, the DOSS bare-metal firmware fuzzer can reconstruct the code flow using the function metadata acquired during the analysis. This capability enables the protection of function frames and local variables on the stack against unauthorized access. By examining a called function’s parameters, access permissions can be granted for local variables directly passed by reference.

Fuzzing requirements

The firmware fuzzer supports 32bit ARM based devices using memory mapped IO. The memory access sanitization features require firmware with included symbol tables. The fuzzing solution is not reliant on the source code of the firmware, but the memory layout and MMIO mapping of the target device must be known.

Evaluation

The runtime requirements with enabled memory access control are slightly elevated compared to configurations without since the virtualization needs to be configured to operate without code block chaining optimization. However, the increase is not substantial, as instruction-wide stepping is unnecessary, and the individual code blocks remain optimized.

The generated error reports utilize the data obtained during static analysis to deliver detailed information about the affected variables, functions and threads. This precise information is helpful in uncovering the underlying causes and thus facilitates the development of security patches.

Conclusion

In summary, the DOSS bare-metal firmware fuzzer offers improved vulnerability detection by incorporating static analysis into its fuzzing process. This novel approach allows to uncover memory corruptions that might be missed by standard firmware fuzzing. As the use of embedded devices increases, having advanced and reliable testing tools becomes essential for enhancing security of embedded devices.