GoogleCodeExporter
commented
9 years ago Additional information provided to Microsoft; Jun 9th:
This vulnerability allows a process running within user-mode to corrupt
kernel-mode structures and allow an attacker to take full control of the
operating system. Specifically, this vulnerability allows an attacker to run
code in Ring-0 on Windows x64 without obtaining a driver-signing certificate,
or submitting code to the Windows Hardware Certification service.
This issue is primarily to highlight that there are a number of places where
the Windows kernel unsafely passes "NULL" as the "ObType" parameter to the
"nt!ObReferenceObjectByHandle" function call - expecting that the result of the
call to be a kernel-pointer to a specific type - rather than securely calling
nt!ObReferenceObjectByHandle with a fixed "ObType" parameter corresponding to
the expected object's type.
There are only a small number of such issue, they are easy to fix, and they
have zero application-compatibility risk.
Exploitation of this category of vulnerability is as follows:
Firstly, the attacker creates a handle to any object that is not an LPC type.
Secondly, the attacker calls NtUserSetInformationThread / UserThreadCsrApiPort
from within CSRSS passing this handle as the parameter
NtUserSetInformationThread( hCurrentThread, UserThreadCsrApiPort, &handle,
sizeof(handle) );
win32k!NtUserSetInformation begins by first verifying that the caller of the
syscall is CSRSS. In this case, we are, so the call continues.
CSRSS runs with high user-mode permissions, but it is not a kernel-mode driver,
and does not run with the full set of permissions that Ring-0 code has. For
example, an Administrator on Windows 7 x64 cannot load code within Ring-0 that
is not in a signed driver, but can inject code into CSRSS. For this reason, in
order to maintain the "signed driver" requirement, the kernel should not trust
parameters sent by CSRSS.
This is precisely the reason why during the syscall,
win32k!NtUserSetInformation validates the length and pointer fields inside the
user-mode parameters using ProbeForRead. Win32k!NtUserSetInformation captures
the parameters to the syscall and sends them to win32k!xxxSetInformationThread.
win32k!xxxSetInformationThread can perform a variety of different functions
depending on the "class" parameter to the syscall. In this case, we specified
"UserThreadCsrApiPort", and so win32!xxxSetInformationThread calls
win32k!SetCsrApiPortHandle.
win32k!SetCsrApiPortHandle now tries to resolve the parameter to a kernel
object via the ObReferenceObjectByHandle function call. Crucially, the kernel
lazily passes "NULL" as the "ObType" parameter, rather than
"*LpcPortObjectType", which means that the kernel merely checks that the
provided handle is valid, not that it is valid and pointing to an ALPC port.
This results in a kernel-mode type-confusion vulnerability in the case where
usermode provides a valid handle to the syscall, but where the handle is not
not a PLPCP_PORT_OBJECT. In this case, the kernel resolves the handle to the
not-ALPC object, and this pointer is then implicitly cast to an ALPC kernel
object leading to type-confusion in the kernel.
The pointer to this "confused object" is stored in the global variable
win32k!CsrApiPort. When the kernel next tries to write data via this ALPC port
(for example, via win32k!xxxActivateDebugger), kernel-mode memory corruption
occurs.
The vulnerability exists on all supported versions of Windows, including
Windows7, Windows 8.1 and Windows 10.
Thankfully this bug is extremely easy to fix with zero app-compat or
performance considerations: since CsrApiPort can only ever safely be a handle
to a LPC port, the the memory-corruption issue can be immediately resolved by
making the ObReferenceObjectByHandle explicitly request an "LpcPortObjectType"
via the ObType parameter. This will cause the function to abort any request to
set the CsrApiPort to a non-LPC object and eliminating the potential for
kernel-mode type confusion.
Original comment by mattt...@google.com on 2 Sep 2015 at 5:56
Original issue reported on code.google.com by
mattt...@google.comon 9 Jun 2015 at 1:43