Windows: Elevation of Privilege in ahcache.sys/NtApphelpCacheControl

[GoogleCodeExporter]

Platform: Windows 8.1 Update 32/64 bit (No other OS tested)

On Windows 8.1 update the system call NtApphelpCacheControl (the code is 
actually in ahcache.sys) allows application compatibility data to be cached for 
quick reuse when new processes are created. A normal user can query the cache 
but cannot add new cached entries as the operation is restricted to 
administrators. This is checked in the function AhcVerifyAdminContext.

This function has a vulnerability where it doesn't correctly check the 
impersonation token of the caller to determine if the user is an administrator. 
It reads the caller's impersonation token using PsReferenceImpersonationToken 
and then does a comparison between the user SID in the token to LocalSystem's 
SID. It doesn't check the impersonation level of the token so it's possible to 
get an identify token on your thread from a local system process and bypass 
this check. For this purpose the PoC abuses the BITS service and COM to get the 
impersonation token but there are probably other ways. 

It is just then a case of finding a way to exploit the vulnerability. In the 
PoC a cache entry is made for an UAC auto-elevate executable (say 
ComputerDefaults.exe) and sets up the cache to point to the app compat entry 
for regsvr32 which forces a RedirectExe shim to reload regsvr32.exe. However 
any executable could be used, the trick would be finding a suitable 
pre-existing app compat configuration to abuse. 

It's unclear if Windows 7 is vulnerable as the code path for update has a TCB 
privilege check on it (although it looks like depending on the flags this might 
be bypassable). No effort has been made to verify it on Windows 7. NOTE: This 
is not a bug in UAC, it is just using UAC auto elevation for demonstration 
purposes. 

The PoC has been tested on Windows 8.1 update, both 32 bit and 64 bit versions. 
I'd recommend running on 32 bit just to be sure. To verify perform the 
following steps:

1) Put the AppCompatCache.exe and Testdll.dll on disk
2) Ensure that UAC is enabled, the current user is a split-token admin and the 
UAC setting is the default (no prompt for specific executables). 
3) Execute AppCompatCache from the command prompt with the command line 
"AppCompatCache.exe c:\windows\system32\ComputerDefaults.exe testdll.dll". 
4) If successful then the calculator should appear running as an administrator. 
If it doesn't work first time (and you get the ComputerDefaults program) re-run 
the exploit from 3, there seems to be a caching/timing issue sometimes on first 
run. 

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 30 Sep 2014 at 2:17

Attachments:

• poc.zip

[GoogleCodeExporter]

first post

Original comment by taviso on 6 Jan 2015 at 7:21

[GoogleCodeExporter]

#100, strange, i tried it with simple domain user and it ask for different 
credentials.

Original comment by mpange...@gmail.com on 7 Jan 2015 at 9:24

[GoogleCodeExporter]

I think what a lot of you guys are forgetting is that this isn't Google, nor is 
it Google's OS development team, nor is it the team behind Android, its their 
security research team which sole purpose is to search for and find security 
exploits like these. Everyone saying that Google is just finding 0Days in 
Windows for the publicity or that they should "concentrate on fixing security 
issues in their own products is stupid. Google's Research team find 0Days in 
thousands of different products every day, the only reason people are 
interested in this one is because its "Windows". These events happen everyday.

Whilst you can debate whether the timeframe was appropriate in this case, 
Google did the right thing in not making different rules for different 
companies. Some vendors NEED this deadline to get off their lazy ass's and 
actually fix the bugs, some (maybe Microsoft) don't. Google can't apply 
different policies to different people so they found one that works across the 
board. Just because "its Microsoft" doesn't give them any right to be exempt 
from Google's policy that was clearly outlined in the original bug report. If 
Microsoft needed more time, they should have contacted Google and requested it.

Original comment by jduncanator on 7 Jan 2015 at 10:41

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

@102 It ask credentials, but if you type the same simple user domain in prompt, 
it work with elevated privileges. 

Don't forget to lunch Auto-Elevated executable (Computerdefaults.exe) to work.

Original comment by reclad on 7 Jan 2015 at 11:20

[GoogleCodeExporter]

Didn't work on Windows Server 2012 / 64 bit, with UAC enabled, cmd disabled , 
taskmgr disabled, from under user restricted account, with Powershell 1.0

The executables have been run smoothly (modified with XVI hex editor from calc 
to notepad etc..) , however haven't got elevated privilegues ... anyone has 
some idea?

Original comment by mailo...@gmail.com on 7 Jan 2015 at 1:36

[GoogleCodeExporter]

Despite the precedent and all of the arguments for the positive benefits of 
establishing a deadline (in the absence of a federal requirement), those 
arguments fall completely flat once actual damages are done to innocent third 
parties (businesses and users of the vulnerable product) as a direct result of 
publishing the vulnerability. A 13-yr precedent means nothing in today's 
infosec ecosystem, where it's not a matter of *if* damages will be done, it's 
*when*.  I'm certain Google knows that, but they don't seem to mind the 
collateral damage.  The public is getting fed up with all of the attacks, so 
it's really terrible PR on the part of Google to aid such attacks in any way, 
regardless of the points they may have in favor of using this tactic to 
pressure a software developer.

What really needs to be done:
1) A legal time limit must be established for remediation of certain 
vulnerabilities.  It can and should include an ability to be extended on a case 
by case basis.  Until our society can agree on and implement a specific legal 
limit, third party research teams must exercise patience and restraint.
2) The law should require that vulnerabilities be reported to the responsible 
party and the U.S. government within a short time (i.e. 14 days) of their 
discovery.  Beyond this reporting requirement, it should be legally mandatory 
to secure the details (for at least two months past the public release of the 
patch) about any vulnerability that could be exploited for malicious use, and 
the law should impose penalties and assign civil liability for any organization 
that leaks such details.
3) In the absence of such a law, Google's security research team should stop 
releasing any vulnerability information until a patch has been publicly 
available for at least two months. Trying to force a specific remediation 
effort by imposing penalties on the users of a third-party's products is not 
appropriate.
4) Until a law is passed that addresses items 1 and 2 above, legal firms need 
to drive changes via civil lawsuits against entities that published information 
that was used to compromise a business's or person's computer.
5) Every major news outlet in the U.S. needs to showcase how entities such as 
Google's security research team are making it easier to compromise either your 
computer or the systems of entities that have your personal information.  Think 
about it.  Let's say the host of a major news outlet starts off their next 
story with 'scary' statistics of all the various cyberattacks, all of the 
horrible consequences, and the terrible experiences people have gone through to 
recover from a stolen identity or deal with the exposure of very personal 
private information/photos, then she/he concludes with this statement: "And the 
people at Google just made it even easier for hackers to do such things.  
GOOGLE, of all people."  Then she/he explains Google's practice of releasing 
detailed vulnerability information, and EVEN providing a platform for the 
discussion of exactly how to exploit the vulnerability immediately below the 
announcement.  Who do you think the general public will blame, Google, or 
Microsoft?  I think we could count on one hand the number of days it would take 
Google to change their policy after stories like this are broadcast.  Any other 
security company with similar practices that could be negatively impacted by 
bad publicity would follow suit.

Original comment by jmj...@yahoo.com on 7 Jan 2015 at 2:54

[GoogleCodeExporter]

#107 - jmj,

I mean this in the most respectful way possible but I think the premise of your 
argument is completely flawed.  While I agree that responsible disclosure is 
something that should be legally addressed, not allowing disclosure is equally 
as dangerous.

Try to think of this vulnerability in a different way, maybe in terms of a 
defective airbag in a vehicle with your child in the front seat.  Just because 
the manufacturer doesn't know about it, or knows but doesn't tell you that 
there is a defect in an airbag firing mechanism (for example) does not mean 
that the flaw does not exist.  It exists and just because you do not know it 
exists doesn't change reality.  

Not sure if you are familiar with the idea of recombinant conceptualization, or 
multiple independent discovery but it is highly likely if not certain that 
another less well-intentioned entity has found this vulnerability (and any 
other future vulnerability the Project Zero group discovers) and is already 
using it to maliciously exploit systems.  

Knowing that the airbag is faulty gives us the opportunity to move our kid to 
the backseat, replace the faulty airbag mechanism, or drive a different car - 
for lack of a better metaphor.

Google letting us know that this vulnerability exists after giving the good guy 
90 days to fix it, and the bad guys 90 days to continue to exploit it is more 
than generous if the intention is to help ensure a more secure computing 
environment.

R/s,
Lx

Original comment by alexande...@gmail.com on 7 Jan 2015 at 3:40

[GoogleCodeExporter]

Thank you Google for pressuring Microsoft into fixing this vulnerability, as 
Microsoft never would have, even with a 90 day head start. 

Original comment by KARMA...@gmail.com on 7 Jan 2015 at 4:29

[GoogleCodeExporter]

James,

On Windows 7, you are able to use Cache Flags 4 and 8, which correspond to 
Telemetry and Event without TCB. Same goes for the result flags.

However, your PoC uses Cache Flag 1 (AppCompat) and Result Flags 0xFF. While 
the Result Flags probably don't matter, I believe without Cache Flag 1, you're 
only able to insert the entry with Telemetry and Event flags, so when 
CreateProcess will later query SDB/Cache, it will see that this is not an 
"AppCompat" entry, but rather a Telemetry entry, and probably ignore it.

To everyone else: this bug has nothing to do with UAC.

Original comment by aione...@gmail.com on 7 Jan 2015 at 4:57

[GoogleCodeExporter]

Thanks Alex,

That's pretty much what I thought would be the case. It seemed likely that the 
TCB check would cover adding a cache entry which would likely cause a security 
issue. Of course why the developers removed the check is beyond me. But then 
again why the actual check was so broken (it's worse in 7 as SeTokenIsAdmin 
also doesn't take into account the impersonation level) is also beyond me. At 
the very least it wasn't really worth spending more time verifying on Windows 7 
considering the 2 or 3 days spent RE'ing 8.1 to prove the vulnerability so that 
MS would likely accept it. I'm sure you could have saved me the hassle.

Original comment by fors...@google.com on 8 Jan 2015 at 12:38

[GoogleCodeExporter]

Historically App Compat was 100% the purview of the AppInfo service up until 
Widows Server 2003 (which has a delicious unfixed bug in how it impersonates 
the caller... back in the LPC days many components had similar issues). This 
delayed process creation, because it meant that every single new process had 
not only to block on CSRSS, but also on AppCompat.

In Vista, they moved App Compat to the kernel (and introduced 'deferred' CSRSS 
process notifications, etc...) as part of an effort to reduce contention on 
user-mode services during process creation. But it was a pretty botched 
attempt, because when it came to some operations, you still needed a service to 
manage app compatibility, and because it bloated the kernel with SBD and app 
compat code. Since a service was used, they put that TCB check in there.

In Windows 8, they cleaned things up and put app compat into its own driver 
(part of the kernel MinWinization), and I believe completely got rid of the 
service such that all app compat actions can come from processes. They still 
kept sensitive actions as 'admin-only', but TCB is no longer required. This 
also meant that the processes that manage app-compat can run with reduced 
privileges, which sounds like a good idea.

In fact, you'll find many places in Win7+ where they removed/reduced privilege 
checks in the kerrnel, all under the guise of "reducing privileges held by 
user-mode apps". 

A really good example is DWM, which ran with very high privileges before (and 
had tons of bugs), but now runs as its own virtual service account. Now all its 
user-mode bugs become boring since it can't do much. Oh but of course, nobody 
thought that this now means all the undocumented Win32k.sys DWM internal APIs 
no longer have the privilege checks... ;-)

Original comment by aione...@gmail.com on 8 Jan 2015 at 4:27

[GoogleCodeExporter]

For anyone thinking this is only a UAC bypass (who are ignoring any other 
comments to contrary) I do have a PoC which gets arbitrary localsystem 
execution from any user account regardless of UAC status which works on Windows 
8.1 Update 32bit. The rationale for providing a UAC only PoC to Microsoft was 
as a demonstration of the specific issue without unnecessary effort being 
expended. 

The vendor is typically best placed to make the assessment on whether something 
is a security issue or not, our responsibility is to provide what information 
we can and a PoC which we feel adequately demonstrates the issue. If Microsoft 
had responded stating that this was a UAC bypass vulnerability only then would 
further work have been necessary to prove it wasn't. In this case Microsoft 
confirmed the issue and planned a fix so it wasn't required. 

Original comment by fors...@google.com on 9 Jan 2015 at 12:59