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.