New issue
Advanced search Search tips
Starred by 2 users
Status: Fixed
Owner:
Closed: Mar 2015
Cc:



Sign in to add a comment
Windows: Task Scheduler Executable File Permissions Bypass
Project Member Reported by forshaw@google.com, Nov 11 2014 Back to list
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.
 
poc.zip
96.7 KB Download
Project Member Comment 1 by forshaw@google.com, Nov 11 2014
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.
Project Member Comment 2 by forshaw@google.com, Nov 12 2014
Labels: MSRC-21000
Project Member Comment 3 by forshaw@google.com, Jan 13 2015
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. 
Project Member Comment 4 by forshaw@google.com, Jan 13 2015
Correspondence Date: 16 Dec 2014

> Microsoft indicate that the additional information is as they expected and ask for an extension to the deadline.
Project Member Comment 5 by forshaw@google.com, Jan 14 2015
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.
Project Member Comment 6 by forshaw@google.com, Jan 16 2015
Labels: -Reported-2014-Nov-11 Reported-2014-Dec-11
Updating reported date to reflect adjusted timescales as requested by Microsoft
Project Member Comment 7 by forshaw@google.com, Mar 10 2015
Labels: CVE-2015-0084 MS15-028
Fixed in bulletin https://technet.microsoft.com/library/security/MS15-028
Project Member Comment 8 by forshaw@google.com, Mar 10 2015
Status: Fixed
Project Member Comment 9 by forshaw@google.com, Mar 17 2015
Labels: -Restrict-View-Commit
Sign in to add a comment