Monorail Project: project-zero Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 5 users
Status: WontFix
Owner:
Closed: Feb 2015
Cc:



Sign in to add a comment
Windows: Console Driver Job Object Process Limit Bypass
Project Member Reported by forshaw@google.com, Dec 9 2014 Back to list
Windows: Console Driver Job Object Process Limit Bypass
Platform: Windows 8.1 Update (Windows 7 not vulnerable)
Class: Security Bypass

Summary:
The console driver in Windows 8.1 can be used to break out of a process with an active process job limit. 

Description:

One change in Windows 8.1 from Windows 7 is the introduction of the console driver (condrv.sys) which is responsible for handling the management of consoles. It contains a method, CdpLaunchServerProcess which creates an instance of conhost.exe. This method calls ZwCreateUserProcess which means that the system call runs with kernel permissions, it also passes a flag (0x400) to the system call which indicates that the new process should not be assigned to the parent job. This allows for the conhost process to bypass the job restrictions. 

As a normal user application has many ways out of this job (process injection, WMI etc.) this wouldn't seem to be really that big of a deal. However some applications such as Chrome and Adobe Reader use job object limits as part of defense in depth for their sandbox implementations. They also set an active process limit and disable breakaway to prevent a sandboxed process breaking out of the job restrictions. Therefore any technique which can circumvent that is interesting. For the most restrictive processes (such as Chrome renderers) this can still be used as the console driver's device has no security enforced and even though the process wouldn't normally be able to access the conhost.exe file it's bypassed by the system call dispatch. As the new process inherits the DACL from the parent token you can set that so even a heavily restricted process can get access once it's been created.

Obviously I realize this is a niche security consideration and might not be considered for a bulletin. Also there are likely legitimate reasons for this behavior. 

I've attached a simple PoC which enables a job object with a limit of one process to the current process and then calls AllocConsole. If that succeed it injects a call to WinExec to exit the job restrictions with an arbitrary process. Obviously this just demonstrates the behaviour, it isn't a serious issue in this case. The pre-built binary is for 64 bit windows, however it will work on 32 bit as well if recompiled. 

Expected Result:
The call to AllocConsole should fail, probably with a quota error

Observed Result:
The call to AllocConsole succeed

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
14.2 KB Download
Project Member Comment 1 by forshaw@google.com, Dec 10 2014
Labels: MSRC-21174
Project Member Comment 2 by forshaw@google.com, Feb 10 2015
Cc: wfh@google.com
Comment 3 Deleted
Project Member Comment 4 by forshaw@google.com, Feb 11 2015
Correspondence Date: 10 Feb 2015

> Microsoft indicate that due to compatibility concerns and the limited impact of the issue to heavily sandboxed applications this doesn't meet the bar for a security bulletin. Changes might be considered for a future version of Windows.
Project Member Comment 5 by forshaw@google.com, Feb 12 2015
Cc: jschuh@google.com
Project Member Comment 6 by forshaw@google.com, Feb 26 2015
Labels: -Restrict-View-Commit
Status: WontFix
Microsoft have confirmed that they will not be fixing this issue. Marking as WontFix and de-restricting. 
nice
Comment 8 Deleted
Sign in to add a comment