title | description | keywords | ms.date | ||||
---|---|---|---|---|---|---|---|
Security Issues for I/O Control Codes |
Security Issues for I/O Control Codes |
|
06/16/2017 |
Secure processing of IRPs that contain I/O control codes depends on defining IOCTL codes properly and on carefully examining parameters that the driver receives with the IRP.
When defining new IOCTL codes, use the following rules:
-
Always specify a FunctionCode value that is equal to or greater than 0x800.
-
Always specify a RequiredAccess value. The I/O manager does not send IOCTLs if the caller has insufficient access rights.
-
Do not define IOCTL codes that allow callers to read or write nonspecific areas of kernel memory.
When processing IOCTL codes within a driver, use the following rules:
-
Whenever a driver's dispatch routines test received IOCTL codes, they must always test the entire 32-bit value.
-
Drivers can use IoValidateDeviceIoControlAccess to dynamically perform stricter access checking than that specified by the RequiredAccess value in the definition of the I/O control code.
-
Never read or write more data than the buffer that is pointed to by Irp->AssociatedIrp.SystemBuffer can contain. Therefore, always check Parameters.DeviceIoControl.InputBufferLength or Parameters.DeviceIoControl.OutputBufferLength in the IO_STACK_LOCATION structure to determine buffer limits.
-
Always zero driver-allocated buffers that will contain data intended for an application that originated an IOCTL request. That way, you will not accidentally copy sensitive data to the application.
-
For METHOD_IN_DIRECT and METHOD_OUT_DIRECT transfers, follow the rules above. Additionally, check for a NULL return value from MmGetSystemAddressForMdlSafe, which indicates that mapping failed or that a zero-length buffer was supplied.
-
For METHOD_NEITHER transfers, follow the rules that are provided in Using Neither Buffered Nor Direct I/O.