Introduction

A driver is a software component that lets the operating system and a device communicate with each other. The main reason for writing a driver is to gain access to protected data that is available only in kernel mode. If there are security flaws in a driver, unlike user mode applications, it can lead to serious problems that SYSTEM privileges are violated.

There have been many efforts to improve the security of Windows drivers, but there have been many difficulties in applying effective testing techniques such as fuzzing (Fuzzing is a technique that automatically generates inputs and injects them into a program to check for bugs and software defects. It is used in various fields to examine stability and security by detecting defects that are difficult for humans to predict.) compared to userland applications.

Since a driver is loaded into kernel memory, we must access the kernel space to examine its stability. It is very difficult to apply fuzzing to this kernel component. Especially, it is even more difficult to apply coverage-guided fuzzing to the kernel.

At the kernel level, the driver handles application requests in the form of a structure called IRP (I/O Request Packet). More specifically, the DispatchDeviceControl that exists inside the driver handles each routine corresponding to the IOCTL code, which is the handler code contained in the IRP sent from the outside of the driver. At this time, access to the routine is determined by various constraints such as inputBuffer contents and inputBufferLength for each routine.

In addition, there are cases in which the execution of other routines must precede the execution of a specific routine in the driver. The typical case mentioned above is a case where a global variable set in one routine is used in another routine. We express this situation as an ordering dependency between IOCTL routines. In order to apply fuzzing to Driver without problem, information about the driver interface is required: that satisfies the constraints and dependencies of the IOCTL code.

Even in order to apply coverage-guided fuzzing to the kernel level, coverage measurement at the kernel level and consideration of the driver interface must be preceded. These causes have made it difficult to fuzz the kernel and driver. So, team driverThru tried to solve these two problems. As we continued our research, we found several ways to solve them, and developed a simple and fast driver fuzzing framework applying these solutions. We hope this tool is useful for improving the stability of Windows drivers and kernel environments.