PEACHTECH

PEACH FUZZER FOR DRIVER FUZZING WHITEPAPER

Peach.tech

2

PEACHTECH1-844-55-PEACH | sales@peach.tech

www.peach.tech

Peach Fuzzer is a general-purpose fuzzer capable of testing a wide variety of targets. The Peach Fuzzer Platform excels at fuzzing complex configurations, custom data formats, and custom interfaces. Fuzzing drivers presents several challenges that differ from typical fuzzing scenarios:

• Uniqueness of each device and associated driver

• How the driver interacts with the rest of the operating system

• Multiple driver interfaces—to the device, kernel, and user

• Where the fuzzer runs

Additionally, driver interfaces often use custom data formats and communication protocols. This document outlines an approach to fuzz device drivers by exploring a sample configuration of Peach Fuzzer, and presents ways to monitor testing, to detect faults, and to collect fault data.

Hardware devices that require kernel drivers include network adapters, storage adapters, sound cards, and graphics cards.

About Kernel DriversKernel drivers typically provide an interface between the kernel and hardware components in a computer system. Each device attached to the system requires a driver to interface the device with the system and to expose services of the device to the operating system. Drivers interface with other components in the kernel and often provide an interface that is accessible from user processes in addition to communicating with hardware devices.

With a kernel driver, each interface type can be interesting to test. Each interface will require a different method to provide the fuzzed data. One of the unique challenges of driver fuzzing is that each driver is different. At a high level some similarities exist among drivers; however, the implementations tend to have unique elements. This means you can expect each driver to need some custom work to fuzz that driver correctly.

About the Driver Fuzzing ConfigurationWhen fuzzing drivers, most faults cause the operating system to crash. Because of this, the fuzzer must run external to the operating system under test. If possible, the driver and the test operating system should run on a virtual machine. However, since the drivers interface with actual hardware devices, this is not always possible. If using a virtual machine isn’t possible, two machines are required. One machine is the target machine that houses the correct hardware, operating system and driver; the other machine houses Peach Fuzzer. The agent feature in Peach Fuzzer® is a special software program to run on the target system that communicates with an instance of the fuzzer running on the second machine.

Multiple types of agents are supported and used. Individual selections depend on the type of target. Agent processes can receive fuzzed data from Peach and using one of the driver interfaces, send the data to the driver. When the target operating system crashes, the fuzzer continues running on the second machine, and can take corrective actions to log the fault and to restart the target system.

Before moving on to describe how to monitor the test environment and to obtain test results, a word about testing each interface is appropriate. As previously stated, with a kernel driver, each interface type can be interesting to test, and requires a different method to provide the fuzzed data. The following sections describe each interface type.

User-Process InterfacesInterfaces exposed to user processes are the easiest to test, using a standard set of methods to send data from the user to the kernel, such as IOCTL interfaces. The methods for sending data over such interfaces vary based on the interface. Some types of interfaces such as IOCTL require creating a

Driver

Component Program

HardwareDevice

Kernel User

Sample Driver with Hardware, Kernel, and User Interfaces

Driver Fuzzing Configuration Using Peach Agent

Driver

Component Program

HardwareDevice

Kernel User

Peach

Fuzzing Engine

3

PEACHTECH1-844-55-PEACH | sales@peach.tech

www.peach.tech

custom program to perform the actual system call. The fuzzer provides data used by the program. Other interfaces operate similarly to file interfaces and can be accessed directly using the Peach Fuzzer agent process.

Kernel-Component InterfacesWhen communicating with the other components inside the kernel, the data must be delivered to the kernel, then forwarded to the interface defined by the driver. This requires a kernel module written for the specific operating system that can communicate with the Peach Fuzzer agent process. Examples of such modules exist in the Peach Fuzzer Software Development Kit (SDK).

Note that writing kernel modules requires specific knowledge of the operating system internals, such as available services, resources, and tools of the operating system; how to transfer data; interrupt mechanisms; and accessing system-device tables.

Hardware to Driver InterfaceThe hardware to driver interface also requires custom work. The method used to communicate with this interface typically depends on the architecture of the driver in question. In some operating systems such as Windows, it is possible to test this interface from the kernel instead of from the hardware. This is typically easier than interfacing physically to the hardware device. If testing from the kernel is not available, a hardware adapter is required that can communicate using the interface used by the hardware device such as USB, PCI, SPI, or I2C. The hardware adapter allows the fuzzer to send data to the driver. If the adapter is not supported by Peach, support must be added using Peach’s plugin API.

MonitoringOnce Peach can communicate with the driver interface selected for fuzzing, setup shifts to selecting methods for performing fault detection, data collection, and automation. These actions use the agent and monitoring features of Peach. Peach Fuzzer ships with a number of monitor modules for performing common functions such as attaching debuggers, taking network captures, and running programs. Additional monitor modules can be added to Peach using the plugin API to add support for proprietary tools used by your organization.

Monitoring consists of the following aspects:

• Identify a fault that occurred in the target driver

• Cause Peach to log information about the test case in which the issue was detected

• Reset the target machine to a known good state so testing can continue

One of the easiest ways to configure fault detection in Peach is to perform a network ping of the target device to verify it is still running. More advanced fault detection configurations can use kernel debugging, which also enables collection of more information about the crash. Additionally, custom or unsupported tool support can be added to Peach using the plugin API.

The second component of monitoring, data collection, is gathering data that will prove useful in analyzing faults found through fuzzing. Any data deemed interesting can be collected: network traffic, files from the device, and log output. Custom tools are supported through the Peach plugin API.

The third component of monitoring, automation, allows Peach to start and correctly configure the target for testing. In the event of a fault, the automation should restart the device in a clean state and allow testing to continue. Automation steps can include controlling power to the device through a networked power strip, running commands both locally on the device and remotely from another device, interfacing with physical components such as static LEDs or buttons, and integrating custom tools through the Peach plugin API.