|
|
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.
Project Member
Comment 1
by
forshaw@google.com,
Nov 11 2014
,
Nov 12 2014
,
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.
,
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.
,
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.
,
Jan 16 2015
Updating reported date to reflect adjusted timescales as requested by Microsoft
,
Mar 10 2015
Fixed in bulletin https://technet.microsoft.com/library/security/MS15-028
,
Mar 10 2015
,
Mar 17 2015
|
||||||
| ► Sign in to add a comment | ||||||