IOCTLs with FILE_ANY_ACCESS: safe or sorry?

FILE_ANY_ACCESS authorizes the I/O Manager to send an IRP for any caller that has a handle to the device, creating a possible path for malicious users to compromise the system. What's the alternative? The RequiredAccess bits in an IOCTL definition indicate the type of access that a caller must request when opening the file object that represents the device. The system-defined constant FILE_ANY_ACCESS, commonly used for driver IOCTLs and FSCTLs, authorizes the I/O Manager to send an IRP for any caller that has a handle to the device (that is, a handle to the file object that represents the target device object). FILE_ANY_ACCESS essentially allows unrestricted access to the target device.

Although FILE_ANY_ACCESS makes life easy for callers, it's risky for drivers because it can create a possible path for malicious users to compromise the system. For example, an IOCTL might put the device in a particular state that should only be in effect for legitimate reads and writes to the device. If the IOCTL's RequiredAccess is set to FILE_ANY_ACCESS, any caller could issue the IOCTL.

What should you do?

  • For new IOCTLs, don't specify FILE_ANY_ACCESS unless it's really necessary. Most requests need only FILE_READ_ACCESS or FILE_WRITE_ACCESS (or both—they can be OR'd together).

Kernel-Mode Drivers: Fixing Common Driver Reliability Issues

Using I/O Control Codes

Writing Secure Code, Chapter 23: General Good Practices

 

 

Send comments about this topic to Microsoft