search

v4ng3l1s / google-security-research

Automatically exported from code.google.com/p/google-security-research
0 stars 0 forks source link

Windows: Console Driver Job Object Process Limit Bypass #213

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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.

Original issue reported on code.google.com by fors...@google.com on 9 Dec 2014 at 2:57

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 10 Dec 2014 at 9:03

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 10 Feb 2015 at 11:54

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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.

Original comment by fors...@google.com on 11 Feb 2015 at 8:53

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 12 Feb 2015 at 10:18

GoogleCodeExporter commented 9 years ago 
Microsoft have confirmed that they will not be fixing this issue. Marking as 
WontFix and de-restricting.

Original comment by fors...@google.com on 26 Feb 2015 at 6:41