Two kernel-mode type-confusion / memory-corruption vulnerabilities in win32k!xxxRemoteReconnect

[GoogleCodeExporter]

The Windows Kernel is subject to two related kernel-mode type-confusion 
vulnerabilities inside win32k!xxxRemoteReconnect. In both cases, a user-mode 
parameter passed to the syscall is incorrectly resolved to its underlying 
kernel representation via ObReferenceObjectByHandle passing NULL as the 
"ObType" field (rather than *IoFileTypeObject and *IoDeviceTypeObject 
respectively).

Because the type is not checked, if a handle of a type other than a HANDLE to a 
file and a device are passed, the kernel incorrectly uses the underlying 
representation of the object as a PFILE_OBJECT and a PDEVICE_OBJECT, causing 
memory corruption in the kernel.

Triggering the vulnerability from within CSRSS is as follows:

void ExploitMain()
{
  size_t parameter[0x128 / sizeof(size_t)];
  DWORD ignore;
  DWORD ret;
  size_t i;
  HANDLE someHandle = CreateThread(NULL, 0, &ThreadMain, 0, 0, &ignore);
  for(i = 0; i < ARRAYSIZE(parameter); i++)
    parameter[i] = (size_t)someHandle;

  ret = NtUserCallOneParam(0x3c, (ULONG_PTR)(&parameter));
}

CSRSS is a highly privileged process, but is not protected from Administrators 
on Windows 7. This means this bug is automatically a Windows kernel-mode 
signing defeat on Windows 7 x64.

Digging deeper, it turns out CSRSS constructs an ALPC port (\Windows\SbApiPort) 
- ACLed to SYSTEM users. By sending a crafted packet to CSRSS via this port, an 
attacker running as SYSTEM can coerse CSRSS into calling the CSRSS-restricted 
syscall on its behalf. For this reason, this is also a stand-alone Windows 
kernel-mode signing defeat on Windows 8.1 and Windows 10: A non 
protected-process running as SYSTEM can attach to this pipe, request that CSRSS 
pass malicious parameters to the kernel, and thereby trigger memory corruption 
and attacker control within the kernel.

Additionally, LSM - itself running as SYSTEM - connects to CSRSS via this pipe, 
and relays the parameter of DCOM/RPC object "IShadowPipe" (with CLSID 
{CFC351CD-3795-458E-B590-34046794AB2F}

Digging even deeper, \Windows\SbApiPort is connected to by LSM.exe - itself 
running as SYSTEM - on behalf of terminal services. The parameters LSM relays 
are relayed via an RPC-able DCOM object implementation (COM object with CLSID 
{CFC351CD-3795-458E-B590-34046794AB2F}; interface "IShadowPipe"; exported via 
LSMPROXY.dll).

It is unclear whether the "IShadowPipe" object is ever exposed over either a 
RDP virtual channel, or one of the many exposed RPC end-points ACL-ed to 
"EVERYONE" from within LSM.exe.

Original issue reported on code.google.com by mattt...@google.com on 12 Jun 2015 at 2:00

[GoogleCodeExporter]

Communication history for this bug:

Jun11 [Day 0]:  Me -> MSRC    Initial report
Jun12 [Day 1]:  MSRC -> Me    MSRC issues tracking number 30430 to track this 
issue
Aug27 [Day 76]: Me -> MSRC    Request for additional feedback on whether 
Microsoft intends to patch the issue prior to the 90 day deadline.
Sep03 [Day 84]: MSRC -> Me    (10:20:45 PST) Microsoft responds "We have 
completed our investigations and have determined that the reported bug can be 
triggered only through CSRSS which is a privileged process, and requires admin 
to kernel elevation which is not considered as a security boundary"
Sep03 [Day 84]: MSRC -> Me    (17:24:30 PST) Microsoft sends a second email 
asking for acknowledgement of their previous email.
Sep04 [Day 85]: Me -> MSRC    Request for Microsoft to provide date on which 
their internal investigation stopped.
Sep08 [Day 89]: MSRC -> Me    Microsoft states "We tried reproducing this issue 
at our end in June and investigated this report during July and August 
time-frame"

Original comment by mattt...@google.com on 10 Sep 2015 at 2:47

[GoogleCodeExporter]

Note that this issue is a kernel driver signing bypass from Administrator 
privileges, i.e. it would typically be used as the final stage in an exploit 
chain that would already have given Administrator access, rather than as a 
standalone exploit.

Matt still has a lingering suspicion that this can be triggered from a 
non-Admin user (as described in the initial report), but after a fairly 
substantial investigation we haven't established this definitively.

Original comment by haw...@google.com on 11 Sep 2015 at 12:10

• Changed state: WontFix
• Added labels: Severity-Low
• Removed labels: Restrict-View-Commit, Severity-Important