Google Project hacker James Forshaw has discovered a new class of vulnerabilities found in some of the kernel mode drivers in Windows that could allow attackers to escalate privileges. The flaws are due to the lack of necessary checks when handling certain requests.
Windows uses the PreviousMode fields to set UserMode or KernelMode and, therefore, determine whether the call's arguments come from a trusted or untrusted source.
The mechanism is also used for creating and opening files, where kernel mode code can choose from various API functions, including some that lead to the I/O Manager's internal function IopCreateFile.
In this case, PreviousMode is assigned to a specific variable to determine whether to check for valid parameters and buffers.
The operating system also uses the variable to check privileges on the device object if it is in UserMode. The Options parameter in IopCreateFile exposes API functions that could only be used by the kernel function to set a flag to override AccessMode and set it to KernelMode.
“IoCreateFile can only be called from kernel function code and there is no syscall transition period, so all calls will use whatever previous function is set on the thread. If IoCreateFile is called from a thread with a previous state set to UserMode, it means that it will become SecAC and MemAC.” reading the white hat hacker’s analysis.
“The implementation of MemAC is particularly problematic, as it means that kernel mode cannot pass kernel pointers to IoCreateFilewhich makes the API very difficult to use. However, the caller of IoCreateFile cannot simply change the thread's previous state to KernelMode, as that would disable SecAC.”
Under certain conditions, this means that access checks are forced to occur, allowing kernel mode 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 access checks when handling certain requests (IRP_MJ_CREATE). The kernel mode could force access checks, opening the door to malicious activity.
“The type of operation being performed and the specific parameters of the operation are passed to the IO stack location structure that immediately follows the IRP structure,” the expert continues. “In the case of opening a file, the main operation type is IRP_MJ_CREATE and uses the Create union field of the IO_STACK_LOCATION structure.”
An attacker controlling the arguments of a file create/open call could use requests originating from user mode to exploit the issue and send an IRP_MJ_CREATE request with a control set to KernelMode, thereby escalating privileges.
In order to define the class of error that leads to local privilege escalation, there is a need for the following separate elements.
- An initial kernel function (which calls IoCreateFile or IoCreateFileEx) that sets the INPC and IFAC flags but does not set OFAC. This could be in a driver or in the kernel itself.
- A vulnerable receiver that uses RequestorMode when handling IRP_MJ_CREATE for a security decision, but does not also check the Flags for SFAC.
“An attacker would need to be able to direct the initiator to open a device object handled by the receiver. The security check on the receiver is bypassed, because Irp->RequestorMode will be KernelMode, but the SL_FORCE_ACCESS_CHECK flag is not checked. “Read the analysis published by Microsoft.”
“In his research, James found moments of both the protocols and the receivers, but none that when connected would directly lead to privilege escalation. We chose to work with him to further investigate and see what we could find together.”.
Microsoft will fix the bug in future versions of the Windows operating system and in the meantime plans to apply most of the fixes to Windows 10 19H1.
“To summarize James and MSRC’s combined research, there did not appear to be a combination of initiator and receiver present in current supported versions of Windows that could be used to escalate local privileges “out of the box.
"However, we have chosen to address them in future versions of Windows as a defense-in-depth measure. Most of these patches are in the pipeline for release in Windows 10 19H1, with a few held back for further compatibility testing and/or because the feature exists and is disabled by default," Microsoft.
"There is some risk that third-party drivers may be vulnerable to this vulnerability, and we urge all kernel driver developers to review their code to ensure proper handling of IRP requests and defensive use of open file APIs ."
