Pierluigi Paganini March 20, 2019

James Forshaw, a white hat hacker at Google Project Zero, has discovered a new class of bugs that affect Windows and some of its drivers.

Google Project Zero hacker James Forshaw discovered a new class of flaws that reside in some of the kernel mode drivers in Windows that could allow attackers to escalate privileges. The flaws are caused by the lack of necessary checks when handling specific requests.

Windows uses PreviousMode fields to set up the UserMode or KernelMode, and consequently determine if the arguments of the call are from a trusted or untrusted source.

The mechanism is also used for the creation and opening of files, where kernel mode code can choose from various API functions, including some leading to I/O Manager internal function IopCreateFile.

In this case, PreviousMode is assigned to a specific variable to determine whether to check for valid parameters and buffers. 

The OS uses the variable also for privilege checking on the device object if it is UserMode. The Options parameter in IopCreateFile is exposed to API functions that could be invoked only from kernel mode to set a flag to override AccessMode and set it to KernelMode.

“IoCreateFile can only be called from kernel mode code and there’s no syscall transition involved, therefore any calls will use whatever previous mode is set on the thread. If IoCreateFile is called from a thread with previous mode set to UserMode this means that SecAC and MemAC will be performed.” reads the analysis of the white hat hacker.

“Enforcing MemAC is especially problematic as it means that the kernel code can’t pass kernel mode pointers to IoCreateFilewhich would make the API very difficult to use. However the caller of IoCreateFile can’t just change the thread’s previous mode to KernelMode as then SecAC would be disabled.”

Under specific circumstances, the behavior is the access checks are forced to occur, making it possible for kernel mode drivers to open an object name specified by a user mode application.

Forshaw explained that some drivers shipped with Windows that run in kernel mode did not perform all of the access checks when handling specific (IRP_MJ_CREATE) requests. Kernel mode code could force access checks, opening the door to malicious activity.

“The operation type being performed and the operation’s specific parameters are passed in the IO Stack Location structure which is located immediately after the IRP structure.” continues the expert. “In the case of opening a file the major operation type is IRP_MJ_CREATE and uses the Create union field of the IO_STACK_LOCATIONstructure.” 

An attacker controlling the arguments of a file create/open call could use requests originating from user mode to abuse the issue and send an IRP_MJ_CREATE request with a check set to KernelMode, in this way he could escalate privilege.

In order to define the class of bug that lead to local privilege escalation, there is a need for the following separate components.

1. A kernel mode Initiator (code which calls IoCreateFile or IoCreateFileEx) which sets the INPC and IFAC flags but doesn’t set OFAC. This could be in a driver or the kernel itself.
2. A vulnerable Receiver which uses RequestorMode during the handling of IRP_MJ_CREATE for a security decision but doesn’t also check the Flags for SFAC.

“An attacker would need to be able to direct the initiator to open a device object that is handled by the receiver. The security check in the receiver is bypassed because the Irp->RequestorMode will be KernelMode, but the SL_FORCE_ACCESS_CHECK flag is not examined.” read the analysis published by Microsoft.

“In his investigations, James had found instances of both initiators and receivers, but none that when chained together would directly lead to privilege escalation. We opted to partner with him on further research and see what we could find together.”

Microsoft will solve the bug in the future versions of Windows OS, meantime, it plans to implement most of the fixes in Windows 10 19H1.

“To summarize James’ and MSRC’s combined investigations, there appeared to be no combination of initiator and receiver present in currently supported versions of Windows that could be used for local privilege escalation out of the box.

Nevertheless, we chose to address these in future versions of Windows as a defence-in-depth measure. Most of these fixes are on track for release in Windows 10 19H1, with a few held back for further compatibility testing and/or because the component they exist in is deprecated and disabled by default.” concludes Microsoft.

“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,”

Pierluigi Paganini

(SecurityAffairs – Windows, privilege escalation )

[adrotate banner=”5″]

[adrotate banner=”13″]