Windows: CSRSS BaseSrvCheckVDM Session 0 Process Creation EoP - CVE-2016-0151 Windows: CSRSS BaseSrvCheckVDM Session 0 Process Creation EoP Platform: Windows 8.1, not tested on Windows 10 or 7 Class: Elevation of Privilege Summary: The CSRSS BaseSrv RPC call BaseSrvCheckVDM allows you to create a new process with the anonymous token, which results on a new process in session 0 which can be abused to elevate privileges. Description: CSRSS/basesrv.dll has a RPC method, BaseSrvCheckVDM, which checks whether the Virtual DOS Machine is installed and enabled. On Windows 8 and above the VDM is off by default (on 32 bit Windows) so if disabled CSRSS tries to be helpful and spawns a process on the desktop which asks the user to install the VDM. The token used for the new process comes from the impersonation token of the caller. So by impersonating the anonymous token before the call to CsrClientCallServer we can get CSRSS to use that as the primary token. As the anonymous token has a Session ID of 0 this means it creates a new process in session 0 (because nothing else changes the session ID). Now this in itself wouldn’t typically be exploitable, there are many places with similar behaviour (for example Win32_Process::Create in WMI) but most places impersonate the primary token it’s going to set over the call to CreateProcessAsUser. If it did this then for most scenarios the call to NtCreateUserProcess would fail with STATUS_ACCESS_DENIED as the anonymous token can’t access much in the way of files, unless of course the default configuration is changed to add the Everyone group to the token. However in this case the code in BaseSrvLaunchProcess instead calls a method, BasepImpersonateClientProcess which opens the calling process’s primary token, creates an impersonation token and impersonates that. This means that the call is created with the security context of the current user which _can_ access arbitrary files. So BaseSrvLaunchProcess does roughly: CsrImpersonateClient(0); OpenThreadToken(..., &hToken); DuplicateTokenEx(hToken, …, TokenPrimary, &hPrimaryToken); <- The anonymous token RevertToSelf(); OpenProcessToken(hCallerProcess, &hToken); DuplicateToken(hToken, SecurityImpersonation, &hImpToken); SetThreadToken(hThread, hImpTOken); <- This impersonates the user NtCreateUserProcess(...); <- Succeeds, creates process as Anonymous Logon in Session 0. Of course this new process in session 0 can’t do a lot due to it being run as the Anonymous Logon user, and in fact will die pretty quickly during initialization. However we can at least get a handle to it before it dies. At least if you have multiple CPUs it should be possible to win the race to open it and suspend the process before death (in fact for later exploitation you might not need it alive at all, just a handle is sufficient). Now you could patch out the LDR calls and allow the process to initialize, but it would be more useful to have a process as the current user with the session ID 0. One way we can do this is exploiting CreateProcessWithLogonW. If we use the LOGON_NETCREDENTIALS_ONLY flag then seclogon will create a new process based on the current callers token (which is the current user) but the service takes a Process ID value which indicates the parent process. It’s the parent process’s session ID which is used to determine what session the new token should really be in. So if we call seclogon, passing the PID of the anonymous token process but call it from the current user we’ll get an arbitrary process created with the current user token but in session 0. There’s some fun to do with default DACLs and the like to make this all work but that’s an implementation detail. The final question is is this useful? Session 0 has a special place in the security model on Windows, even more so since Vista with Session 0 isolation. For example because we’re in session 0 we can drop arbitrarily named Sections and Symbolic Links in \BaseNamedObjects which normally requires SeCreateGlobalPrivilege this might allow a low privilege user to interact with system services which no longer expect this kind of attack vector. Also there’s probably other places which check for Session ID 0 to make some sort of trust decision. Note even though the VDM isn’t present on x64 builds of Windows these CSRSS RPC calls still seem to exist and so should be vulnerable. From a fixing perspective I guess CSRSS should consistently use the same token for the primary and the impersonation. In the more general case I wonder if the anonymous token should have its Session ID set to the caller’s session ID when it impersonates to to prevent this scenario in the first place, but I bet there’s some difficult edge cases on that. Proof of Concept: I’ve provided a PoC as a C++ source code file. You need to compile it with VC++. This must be run on Windows 8.1 32 bit version as I abuse the existing code in CreateProcess to call CSRSS when trying to create a 16bit DOS executable. This is rather than going to the effort of reverse engineering the call. However if you did that it should work in a similar way on 64 bit windows. Also you MUST run it on a multi-processor system, you might not be able to win the race on a single core system, but I’ve not verified that. If it seems to get stuck and no new process is created it might have lost the race, try it again. Also try rebooting, I’ve observed the control panel sometimes not being created for some reason which a reboot tends to fix. 1) Compile the C++ source code file. 2) Execute the poc executable as a normal user. This will not work from low IL. 3) If successful a copy of notepad should be created (suspended though as it’ll crash trying to access the Window Station if it starts). You can create a process which will survive to add stuff to things like BaseNamedObjects but I’ve not provided such an executable. Expected Result: The call to BaseSrvCheckVDM should fail to create the control panel process. Observed Result: A new copy of notepad is created suspended. You can observe that it runs as the current user’s token but in Session ID 0. This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. MSRC requested the grace period for this issue. They plan to fix in the April security updates. Fixed in Found by: forshaw # Iranian Exploit DataBase = http://IeDb.Ir [2016-04-29]