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

Summary:
When an application impersonates another user all file accesses are performed using the current DOS device map under that token. This allows a user to force a system service to load DLLs or start processes at higher privileges leading to EoP.

Description:

Each login session has a DosDevices mapping under \Sessions\0\DosDevices\X-Y where X-Y is the login session ID. This object directory is writeable by the user. When a \??\ path is looked up the kernel first checks the per-login session mapping for a symlink to the drive mapping, if not found it will fallback to looking up in \GLOBAL??. This mapping is also done when impersonating another user, which is typical of system services when performing actions on behalf of another user.

The vulnerability occurs because a user can place symlinks for the system drives in the per-login session device map and the kernel will follow them during impersonation. If for example a system service when impersonating calls LoadLibrary for a system DLL it's possible for the file open to be redirected to an arbitrary location. So for example if the service tries to load c:\windows\system32\some.dll a user can create a dos device mapping for c: to somewhere else and get a DLL loaded into a system service.

I've fully tested this on Windows 8.1 update 32 bit, but basic testing on Windows 7 x64 indicates the vulnerability is also on that platform. It isn't a bug in the implementation of the services, but a kernel issue. 

Proof of Concept:

I’ve provided a PoC which causes the uses the spooler service to load an arbitrary DLL. As the spooler service runs as local system this is a complete EoP. I've only chosen the spooler service because it was a convenient one to do so and I knew it does a lot of work while impersonating the user. The PoC is only designed for 32 bit Windows 8.1 update. It might work on x64 version, but it doesn't by default on Windows 7 possibility due to differences in the printer driver I'm relying on for execution. 

1) Extract the PoC to a location on a local harddisk which is writable by a normal user
2) Execute the Poc_DosDeviceSymlink_EoP.exe file
3) The calculator should be running as a child process of spoolsv.exe with system privileges.

Expected Result:
It shouldn’t be possible to elevate privileges

Observed Result:
Calculator running at system privileges

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.
 

Poc_DosDeviceSymlink_EoP.zip 82.8 KB Download