A security researcher working with Google Project Zero has discovered a novel bug class that impacts Windows and some of its drivers.
Discovered by James Forshaw, the issue resides in the fact that some of the kernel mode drivers that Windows ships with do not perform all the necessary checks when handling specific requests, which could allow an attacker to escalate privileges.
Windows distinguishes between system calls by setting their PreviousMode fields to UserMode or KernelMode, to help determine if the arguments of the call are from a trusted or untrusted source.
This applies to the creation and opening of files as well, where kernel mode code can choose from various API functions, including some leading to I/O Manager internal function IopCreateFile. The thread’s PreviousMode is assigned to a specific variable to determine whether to check for valid parameters and buffers.
The same variable is later used in access checking, and a privilege check is performed on the device object if it is UserMode, Microsoft explains. However, an Options parameter in IopCreateFile that is exposed to API functions only reachable from kernel mode can set a flag to override AccessMode and set it to KernelMode.
In some cases, however, the behavior is overridden and access checks are forced to occur, including for kernel mode drivers that open an object name specified by a user mode application. In Windows XP, Microsoft introduced a new flag to ensure that other API functions operating in the object namespace can force an access check.
What Forshaw discovered was that some kernel mode drivers shipped with Windows did not perform all of the access checks when handling specific (IRP_MJ_CREATE) requests. Kernel mode code could force access checks, seemingly for legitimate purposes, but the operation could apparently be maliciously exploited.
An attacker with sufficient control of the arguments of a file create/open call could use requests originating from user mode to abuse the bug and send an IRP_MJ_CREATE request with a check set to KernelMode, which could result to a local privilege escalation vulnerability.
The researcher specified two kernel mode code patterns required to exploit the vulnerability, namely an ‘initiator’, which makes a file create/open call, and a ‘receiver’, which handles IRP_MJ_CREATE requests. The attacker would need to direct the initiator to open a device object handled by the receiver, which could result in the security check in the receiver being bypassed.
“In his investigations, James had found instances of both initiators and receivers, but none that when chained together would directly lead to privilege escalation,” Microsoft explains.
Microsoft worked together with the security researcher to investigate the new bug class, and eventually discovered that the currently supported versions of Windows contain no combination of initiator and receiver that could be used for local privilege escalation out of the box.
However, Microsoft decided to address the issue in future versions of Windows as a defense-in-depth measure, and is ready to include most of the fixes in Windows 10 19H1. Some of them, however, will be held back for additional compatibility testing and/or because the component they impact is either deprecated and disabled by default.
“There exists some risk of third-party drivers being susceptible to this vulnerability class, and we urge all kernel driver developers to review their code to ensure correct processing of IRP requests and defensive use of the file open APIs,” the software giant says.
Related: Windows Zero-Day Exploited by FruityArmor, SandCat Threat Groups
Related: Google Discloses Actively Exploited Windows Vulnerability
Ionut Arghire is an international correspondent for SecurityWeek.
Tags: 
