Windows: DosDevices Impersonation Process Creation Elevation of Privilege

[GoogleCodeExporter]

Windows: DosDevices Impersonation Process Creation Elevation of Privilege
Platform: Windows 8.1 Update, Windows 7
Class: Elevation of Privilege

Summary:
The fix for CVE-2015-1644 doesn't take into account process creation scenarios. 
If a process is created by a system service while impersonating another user 
their per-user drive mappings will still be used which could lead to EoP. 

Description:

As far as I can tell the fix for CVE-2015-1644 was to add a new object 
attribute flag (0x800) which disables the impersonation device mapping in the 
name lookup process. This has been applied to the DLL loader code inside ntdll, 
but doesn't seem to be used anywhere else. One area of attack still available 
is process creation, if an explicit token isn't specified then the new process 
inherits its token from the parent, regardless of whether another user was 
being impersonated at the time. 

Looking at the kernel after CVE-2015-1644 there are no changes to 
NtCreateUserProcess and family to open the executable files with the new object 
attribute. This means that if a system service was to impersonate a logged on 
user but call CreateProcess or ShellExecute for an executable it would use the 
impersonating user’s device map rather than the service's. This could lead to 
EoP as the new process would run as the service user, while the executable can 
be specified by the normal user. Calling CreateProcessAsUser is less likely to 
be vulnerable as in the majority of cases the token being passed is the same as 
the impersonating user. Of course the attacker doesn't need to control the path 
to the executable or the command line, they just need to replace the drive 
mappings so the process creation could be completely inadvertent or a byproduct 
of an API call. 

I wouldn't have probably considered reporting this as I've yet to discover an 
actual vulnerable service, however the fixes applied in CVE-2014-1807/MS14-027 
indicates that there are some services, maybe 3rd party which call ShellExecute 
under a user’s impersonation token. If this is the case then those services 
are again vulnerable using this attack instead of the previous registry file 
extension one. About the only thing I've found which can exploit this is 
creation of UI Access processes as they are created under the current user’s 
context, but of course that would be a UAC bypass. 

I’d guess that the new object attribute should be applied when impersonating 
another user and either no explicit token is specified or the token’s user is 
not the same as the impersonating user. 

Proof of Concept:

As I've mentioned I've not found a vulnerable service yet, although one might 
exist on a default installation of Windows. Therefore instead I've provided a 
simple RPC PoC which tests out the theory that impersonating while calling 
CreateProcess or ShellExecute in a privileged service is vulnerable to the 
attack described. The server will try and execute c:\windows\notepad.exe under 
impersonation, assuming that the low-privileged user couldn't influence the 
executable itself. The password for the 7z file is ‘password’. 

1) Extract the PoC to a location on a local hard disk which is writable by a 
normal user
2) As a high-privileged user (one with SeImpersonatePrivilege) execute 
RpcServer.exe
3) As a low-privileged user run RpcClient.exe
4) The server should execute the arbitrary notepad.exe rather than the real 
notepad.exe

You can also try passing -s to the client which will instead test ShellExecute. 
It should work, but it’s not been rigorously tested. 

Expected Result:
The original notepad executable should run as the service user

Observed Result:
Arbitrary process runs at the same privilege as the service user

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.

Original issue reported on code.google.com by fors...@google.com on 28 Apr 2015 at 5:06

Attachments:

• poc_cpi.7z

[GoogleCodeExporter]

Original comment by fors...@google.com on 28 Apr 2015 at 8:54

• Added labels: Id-30096

[GoogleCodeExporter]

Correspondence Date: 26 July 2015

> Microsoft indicates that this won't be fixed in a security bulletin although 
they will consider looking into it in future versions of Windows.

Original comment by fors...@google.com on 27 Jul 2015 at 3:09

[GoogleCodeExporter]

As this will not be fixed in a bulletin opening the issue and marking as 
WontFix. 

Original comment by fors...@google.com on 27 Jul 2015 at 3:10

• Changed state: WontFix
• Removed labels: Restrict-View-Commit