Windows: Task Scheduler Executable File Permissions Bypass

[GoogleCodeExporter]

Windows: Task Scheduler Executable File Permissions Bypass
Platform: Windows 8.1 Update 32/64 bit (7 doesn't seem to be vulnerable)
Class: Security Bypass

The Windows Task Scheduler can be abused by a low privileged user to execute 
files which they don't have access to because of access control permissions. 
The only requirement is LocalSystem is allowed to access the executable file, 
and that the executable doesn't need to access other resources from the same 
location (this rules out .NET applications which re-open their executable 
process). 

The bug comes from the task scheduler creating the process directly from the 
privileged service without impersonating the target user. Even though the 
service is calling CreateProcessAsUser the API doesn't limit the process 
creation to the user's token, instead the access check is done against the 
LocalSystem token. As long as the executable is reasonably standalone once it's 
mapped into memory as LocalSystem it will be allowed to execute once the token 
is swapped for the low-privileged user. 

Locking down executable files on disk is a common technique in Enterprise 
environments. This seems to circumvent Software Restriction Policy (I've not 
tried AppLocker). Of course if you've got code executing already to setup the 
task it isn't clear if that is more of a security issue. I suppose if the 
user's permitted to setup scheduled tasks it might be an issue. 

This doesn't seem to work on Windows 7 because the task scheduler places an 
instance of taskeng.exe in between the privileged service and the resulting 
executable. As the taskeng instance runs as the user this will fail with access 
denied, and it isn't obviously possible to replace taskeng.exe from a normal 
user. There might be a setting in the task to bypass taskeng.exe but it looks 
more likely to be a change in the way the service is implemented in Windows 8.1

Provided is a PoC which exploits the issue on Windows 8.1 Update. There are two 
files, Poc_TaskScheduler_SecurityBypass.exe which performs the exploit and 
runme.exe which is used to demonstrate the issue. When run the PoC will set a 
restrictive DACL on the runme.exe which would normally block the user from 
executing it.

1) Login as a normal user, copy the 2 files to a suitable location. 
2) Execute Poc_TaskScheduler_SecurityBypass.exe, observe that runme.exe should 
now be executing. 

Expected result: 
The execution of file runme.exe should be blocked with an access denied error
Observed result:
The file runme.exe executes

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 11 Nov 2014 at 10:11

Attachments:

• poc.zip

[GoogleCodeExporter]

Further investigation indicates the real culprit (although the analysis still 
stands). It seems that all the process creation is handled through the Unified 
Background Process Manager (ubpm.dll) on Windows 8.1 at least. This has a 
function, UbpmFileAccessCheck that's called from UbpmCreateProcessSuspended 
which presumably is to check that the token can access the target process file. 
Instead it checks the task file, as we created the task file this will pass and 
continue on to creating the process. Perhaps this is actually by design, it's 
hard to tell.

As an aside the CreateProcessAsUser function is also only passed a commandline 
with no executable path. Therefore quote escaping tricks might apply to any fix 
applied to verify the original path.

Original comment by fors...@google.com on 11 Nov 2014 at 2:15

[GoogleCodeExporter]

Original comment by fors...@google.com on 12 Nov 2014 at 10:52

• Added labels: MSRC-21000

[GoogleCodeExporter]

Correspondence Date: 11 Dec 2014

< Microsoft indicate that they've had difficulty reproducing it from the PoC, 
stating that the detailed write-up was not included in the original report. 
They ask for further details

> The original write-up is sent to Microsoft as it seems that the details might 
not have been provided originally. 

Original comment by fors...@google.com on 13 Jan 2015 at 2:18

[GoogleCodeExporter]

Correspondence Date: 16 Dec 2014

> Microsoft indicate that the additional information is as they expected and 
ask for an extension to the deadline.

Original comment by fors...@google.com on 13 Jan 2015 at 2:21

[GoogleCodeExporter]

Correspondance Date: 14 Jan 2015

< Informed Microsoft that we're willing to extend the deadline 30 days in this 
situation because we had apparently not provided a writeup. This corresponds 
with the time it took for them to get back to us informing us of the mistake. 
Requested that they in future inform us immediately if such information is 
missing as it should be expected that we would provide these details in order 
to maximize the chances of remediation of the issue for user security. 
Requested confirmation of this offer.

Original comment by fors...@google.com on 14 Jan 2015 at 11:15

[GoogleCodeExporter]

Updating reported date to reflect adjusted timescales as requested by Microsoft

Original comment by fors...@google.com on 16 Jan 2015 at 1:15

• Added labels: Reported-2014-Dec-11
• Removed labels: Reported-2014-Nov-11

[GoogleCodeExporter]

Fixed in bulletin https://technet.microsoft.com/library/security/MS15-028

Original comment by fors...@google.com on 10 Mar 2015 at 7:09

• Added labels: CVE-2015-0084, MS15-028

[GoogleCodeExporter]

Original comment by fors...@google.com on 10 Mar 2015 at 7:09

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by fors...@google.com on 17 Mar 2015 at 2:06

• Removed labels: Restrict-View-Commit