An IOCTL (an abbreviation of input/output control) is a system call for device-specific input/output operations and other operations which cannot be expressed by regular system calls. It’s an interface in a system call by through which the user space can communicate with device drivers.
Ioctl interfaces are a primary attack surface for drivers (especially in less audited 3rd party or non-OS code) since they parse input from the user space – hence that input should be validated properly. Vulnerabilities in device drivers can be exploited by local users by passing invalid buffers to ioctl calls.
In a code review of a driver it isn’t difficult to spot those routines… watch out for iotcl, fsctl, open, read, write etc.
Read more on the windows driver attack surface in this presentation from IoActive
Security Testing
1. White box Fuzzing: IoSpy and IoAttack are free tools from Microsoft that perform IOCTL and WMI fuzz tests on Kernel-mode drivers. They can be used to ensure that drivers’ IOCTL and WMI code validate data buffers and buffer lengths correctly. More details.
2. Black box Fuzzing: Ioctlfuzzer and Ioctlbf are more general purpose ioctl fuzzers. Ioctlfuzzer is able to spoof ioctls (based on conditions specified in an input file) to seed the fuzz run. In a similar manner, Ioctlbf requires one valid ioctl before scanning the driver for valid Iotcl codes.
