logo

Improper Address Validation in IOCTL with METHOD_NEITHER I/O Control Code

Draft Variant
Structure: Simple
Description

This vulnerability occurs when a Windows driver defines an IOCTL using METHOD_NEITHER but fails to properly check the user-supplied memory addresses before using them.

Extended Description

When a driver uses METHOD_NEITHER for an IOCTL, it receives raw pointers directly from user mode. The driver code itself becomes fully responsible for validating that these addresses are safe and accessible before any read or write operation. Skipping this validation is dangerous because the driver will blindly trust user-controlled pointers. Attackers can exploit this by passing crafted or invalid memory addresses, which can lead to reading sensitive kernel data, corrupting system memory, or crashing the system. Proper validation includes checks for user-mode address ranges, probe operations, and using structured methods like ProbeForRead or ProbeForWrite to prevent privilege escalation and denial-of-service attacks.
Common Consequences 1
Scope: IntegrityAvailabilityConfidentiality

Impact: Modify MemoryRead MemoryExecute Unauthorized Code or CommandsDoS: Crash, Exit, or Restart

An attacker may be able to access memory that belongs to another process or user. If the attacker can control the contents that the IOCTL writes, it may lead to code execution at high privilege levels. At the least, a crash can occur.
Potential Mitigations 3
Phase: Implementation
If METHOD_NEITHER is required for the IOCTL, then ensure that all user-space addresses are properly validated before they are first accessed. The ProbeForRead and ProbeForWrite routines are available for this task. Also properly protect and manage the user-supplied buffers, since the I/O Manager does not do this when METHOD_NEITHER is being used. See References.
Phase: Architecture and Design
If possible, avoid using METHOD_NEITHER in the IOCTL and select methods that effectively control the buffer size, such as METHOD_BUFFERED, METHOD_IN_DIRECT, or METHOD_OUT_DIRECT.
Phase: Architecture and DesignImplementation
If the IOCTL is part of a driver that is only intended to be accessed by trusted users, then use proper access control for the associated device or device namespace. See References.
Observed Examples 5
CVE-2006-2373Driver for file-sharing and messaging protocol allows attackers to execute arbitrary code.
CVE-2009-0686Anti-virus product does not validate addresses, allowing attackers to gain SYSTEM privileges.
CVE-2009-0824DVD software allows attackers to cause a crash.
CVE-2008-5724Personal firewall allows attackers to gain SYSTEM privileges.
CVE-2007-5756chain: device driver for packet-capturing software allows access to an unintended IOCTL with resultant array index error.
References 7
Exploiting Common Flaws in Drivers
Ruben Santamarta
11-07-2007
http://reversemode.com/index.php?option=com_content&task=view&id=38&Itemid=1
ID: REF-696
Remote and Local Exploitation of Network Drivers
Yuriy Bulygin
01-08-2007
https://www.blackhat.com/presentations/bh-usa-07/Bulygin/Presentation/bh-usa-07-bulygin.pdf
ID: REF-697
Windows driver vulnerabilities: the METHOD_NEITHER odyssey
Anibal Sacco
10-2008
http://www.net-security.org/dl/insecure/INSECURE-Mag-18.pdf
ID: REF-698
Buffer Descriptions for I/O Control Codes
Microsoft
https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/buffer-descriptions-for-i-o-control-codes(2023-04-07)
ID: REF-699
Using Neither Buffered Nor Direct I/O
Microsoft
https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/using-neither-buffered-nor-direct-i-o(2023-04-07)
ID: REF-700
Securing Device Objects
Microsoft
https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/controlling-device-access(2023-04-07)
ID: REF-701
Exploiting Windows Device Drivers
Piotr Bania
https://www.piotrbania.com/all/articles/ewdd.pdf(2023-04-07)
ID: REF-702
Applicable Platforms
Languages:
C : OftenC++ : Often
Modes of Introduction
Implementation
Related Weaknesses
ChildOf: Improper Validation of Specified Index, Position, or Offset in Input (CWE-1285)
CanPrecede: Untrusted Pointer Dereference (CWE-822)
Notes
Applicable Platform Because IOCTL functionality is typically performing low-level actions and closely interacts with the operating system, this weakness may only appear in code that is written in low-level languages.
Research Gap While this type of issue has been known since 2006, it is probably still under-studied and under-reported. Most of the focus has been on high-profile software and security products, but other kinds of system software also use drivers. Since exploitation requires the development of custom code, it requires some skill to find this weakness. Because exploitation typically requires local privileges, it might not be a priority for active attackers. However, remote exploitation may be possible for software such as device drivers. Even when remote vectors are not available, it may be useful as the final privilege-escalation step in multi-stage remote attacks against application-layer software, or as the primary attack by a local user on a multi-user system.