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]

Original comment by fors...@google.com on 1 Oct 2014 at 7:09

• Added labels: MSRC-20544

[GoogleCodeExporter]

Original comment by fors...@google.com on 2 Dec 2014 at 11:10

• Added labels: Product-Windows-Kernel
• Removed labels: Product-Windows

[GoogleCodeExporter]

Deadline exceeded - automatically derestricting

Original comment by fors...@google.com on 29 Dec 2014 at 8:44

• Added labels: PublicOn-2014-Dec-29, Deadline-Exceeded
• Removed labels: Restrict-View-Commit

[GoogleCodeExporter]

nice

Original comment by wangwei...@gmail.com on 30 Dec 2014 at 1:59

[GoogleCodeExporter]

Automatically disclosing this vulnerability when a deadline is reached with 
absolutely zero context strikes me as incredibly irresponsible and I'd have 
expected a greater degree of care and maturity from a company like Google. My 
reading of the disclosure is that it's your average local privilege escalation 
vulnerability. That's bad and unfortunate, but it's also a fairly typical class 
of vulnerability, and not in the same class as those that keep people like me 
up at night patching servers. The sad reality is that these sort of 
vulnerabilities are a dime a dozen on Windows, and the situation on Linux is 
pretty comparable. But disclosing it with zero context strikes me as the wrong 
approach.

What communication has occurred with Microsoft to date? Has the vulnerability 
been acknowledged? Presumably yes given there's an MSRC ID? Has there been a 
delay on Microsoft's end because of certain engineering complexities? Christmas 
has just passed and today is New Year's Eve, so realistically, many employees 
from both Google & Microsoft are likely on leave. That's unfortunate, security 
issues don't care about the time of year, but it's also the human reality. 
Ninety days may seem like a long time, but developing and regression testing a 
patch to an important operating system driver isn't typically quick or easy. 
Mistakes from rushing cost lots of time and money; anyone who's paid attention 
to recent screw-ups in MS Security Bulletins should be aware of this.

Disclosing this may have been the right thing to do. Doing so based on an 
automated deadline with zero context from Google strikes me as much less so. It 
seems to me that the relationship between Google & MSFT's respective security 
teams is fairly poor. Seeing things like this certainly goes a way to 
explaining why.

Original comment by s...@nexiom.com.au on 30 Dec 2014 at 2:49

[GoogleCodeExporter]

Nice!

Original comment by st33lf...@gmail.com on 31 Dec 2014 at 11:09

[GoogleCodeExporter]

Couldn't get this to execute on recent Windows 10 Builds. Possibly been patched?

Original comment by greig.mi...@gmail.com on 31 Dec 2014 at 4:53

[GoogleCodeExporter]

I totally agree with all the points made in comment #5.
I find it hard to believe that a company like Google is automatically 
disclosing a vulnerability affecting billions of PCs during a holiday season.
No matter the rivalries between Google and Microsoft we, your users, deserve a 
more responsible behavior from both companies.

Original comment by idra...@gmail.com on 31 Dec 2014 at 7:04

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Just to pour water over previous comments over guesses that there has been no 
communication with Microsoft - the bug has a MSRC tag, which is Microsoft's bug 
database. Pure speculation makes it easy to paint people as the bad guys. :) 

Original comment by Russell....@gmail.com on 31 Dec 2014 at 7:27

[GoogleCodeExporter]

Agree with comment #5. This OS is run by billions. Exposing vulnerabilities 
like this has far reaching consequences. People could get hurt by this and it 
doesn't bring anyone closer to a solution. I find it difficult to believe that 
MSFT and GOOG don't have red-telephone access to each other if needed. This is 
a terrible oversight here. When an organization is as big and powerful as GOOG 
people working there need to think of themselves as stewards of a great power 
and work to be fair and regulate the harm that can come of misusing this great 
power when possible.

Original comment by mickrrus...@gmail.com on 31 Dec 2014 at 7:29

[GoogleCodeExporter]

Maybe there is someone already exploiting this vulnerability even before this 
was posted. I think it is a good thing to make it public to generate some 
pressure to the developer/manufacturer to fix its products. 

Keeping this kind of vulnerabilities private only helps the people that are 
exploiting it in secret. 

Original comment by martinit...@gmail.com on 31 Dec 2014 at 7:31

[GoogleCodeExporter]

@ #9 martinit... using chaos, mayhem, riots and discord to get something fixed 
rarely work. How does giving script kiddies, state sponsored hackers and 
criminals exploits help anything? Now they can back door and bot up the 
machines and do even more damage. 

@ #10 Russell...., so you know how easy it is for MSFT to fix these bugs? Can 
Microsoft employees have a Christmas Season with family without being carpet 
bombed by a paid script kiddie?

Shameful behavior. The lot of it IMHO. 

Original comment by mickrrus...@gmail.com on 31 Dec 2014 at 7:33

[GoogleCodeExporter]

Props to Google for sticking to their timetable. Today's release resulted in 
the following comment from Microsoft: 

"We are working to release a security update to address an Elevation of 
Privilege issue. It is important to note that for a would-be attacker to 
potentially exploit a system, they would first need to have valid logon 
credentials and be able to log on locally to a targeted machine. We encourage 
customers to keep their anti-virus software up to date, install all available 
Security Updates and enable the firewall on their computer."

Original comment by hdms...@gmail.com on 31 Dec 2014 at 7:34

[GoogleCodeExporter]

No one is done any good by keeping it secret. By exposing the vuln they allow 
those billions who may be running vulnerable systems to be aware of the threat 
to their own security and take countermeasures. A patch isn't the only way to 
mitigate the issue. Given the nature of this vulnerability, there are other 
steps administrators can take to start protecting their vulnerable systems 
while they await a patch.

Kudos to Google for sticking to their deadline.

Original comment by kohe...@oxiii.net on 31 Dec 2014 at 8:04

[GoogleCodeExporter]

Attackers are not going to take the day off because it's the Holidays. 
Microsoft dropped the ball, did not perform a security assessment of the new 
features before releasing them into production, and now have to deal with the 
consequences. 

Google isn't doing this to make friends. They are doing this to address a 
widespread problem of companies releasing insecure products. Ignoring a 
security vulnerability isn't going to fix it either.

Original comment by magne.ig...@gmail.com on 31 Dec 2014 at 8:09

[GoogleCodeExporter]

@ #13 mickrrus... chaos, mayhem, riots and discord .... I don't see that yet.. 
let's wait for tomorrow to see if you are right. For the moment it does not 
seems like a "Doomsday security exploit".  Hiding security issues is worst 
because you can be hacked/robbed continuously for years without knowing about 
it. IMHO. 

Original comment by martinit...@gmail.com on 31 Dec 2014 at 8:09

[GoogleCodeExporter]

You Google suck-ups are sickening. This is bad form by Google. No, attackers 
don't take the holiday off, that's precisely why you don't reveal the 
vulnerability when they can take most advantage of the head start they'd be 
getting before a patch is made. Think, people!

Original comment by freddyt5...@gmail.com on 31 Dec 2014 at 8:18

[GoogleCodeExporter]

Freddyt, the attackers are already using it because, as history has shown, 
those who are most likely to exploit systems en masse discover and build 
exploits for these kinds of vulnerabilities long before they're disclosed. It's 
not about sucking up to Google, it's about the reality that most people can do 
a lot to mitigate an unpatched vulnerability if only they know it's there. By 
letting everyone know, they at least allow those who are vulnerable to start 
taking their own preventative countermeasures.

Original comment by kohe...@oxiii.net on 31 Dec 2014 at 8:31

[GoogleCodeExporter]

@ #18 freddy - Microsoft had three months to resolve this and were aware of 
Google's disclosure timeline. If they chose not to address it, that is their 
decision. I have waited years (sometimes 4+) for Microsoft to address security 
issues I reported. A 90-day timeline makes a lot more sense in terms of 
improving overall security. 

Original comment by hdms...@gmail.com on 31 Dec 2014 at 8:36

[GoogleCodeExporter]

Disclosing vulnerabilities is like the prisoner's dilemma in game theory. You 
play by the rules until the other side does not. Google made the optimal move 
when responsible disclosure failed.

Original comment by jwal...@securityevaluators.com on 31 Dec 2014 at 8:36

[GoogleCodeExporter]

"Can Microsoft employees have a Christmas Season with family..."

They had 80+ days - well, subtract a few for Thanksgiving ?

Original comment by hallstev...@gmail.com on 31 Dec 2014 at 8:54

[GoogleCodeExporter]

90 days is *extremely* reasonable for an expected turnaround.  That is almost 3 
months for a vulnerability embargo, and companies should be expected to push 
out fixes for vulnerabilities like this quicker than 3 months.

If the embargo were extremely short (eg: like the 1-week (or less) embargos 
that some people give), then I would be sympathetic, but 3 months is more than 
enough time to triage, patch, QA, and release.

Original comment by jerem...@gmail.com on 31 Dec 2014 at 10:13

[GoogleCodeExporter]

Microsoft have been aware of escalation vulnerabilities with the UAC whitelist 
system for **years** and done nothing, I don't see why this should be any 
different. 

See e.g. http://pretentiousname.com/misc/win7_uac_whitelist2.html

Original comment by jpot...@gmail.com on 31 Dec 2014 at 10:27

[GoogleCodeExporter]

Thanks for the robust discussion everyone. We've been watching this thread 
develop, and although the bug tracker is intended for technical analysis and 
bookkeeping related to the specific issue described, we're happy to give a 
little bit of leeway initially as there are some important process/policy 
issues being raised.

Firstly, just to make this absolutely clear, the 
ahcache.sys/NtApphelpCacheControl issue was reported to Microsoft on September 
30. You can see this in the "Reported" label on the left hand panel of this 
bug. This initial report also included the 90-day disclosure deadline statement 
that you can see above, which in this instance has passed. 

Project Zero's disclosure deadline policy has been in place since the formation 
of our team earlier in 2014.  It's the result of many years of careful 
consideration and industry-wide discussions about vulnerability remediation. 
Security researchers have been using roughly the same disclosure principles for 
the past 13 years (since the introduction of "Responsible Disclosure" in 2001), 
and we think that our disclosure principles need to evolve with the changing 
infosec ecosystem. In other words, as threats change, so should our disclosure 
policy.

On balance, Project Zero believes that disclosure deadlines are currently the 
optimal approach for user security - it allows software vendors a fair and 
reasonable length of time to exercise their vulnerability management process, 
while also respecting the rights of users to learn and understand the risks 
they face. By removing the ability of a vendor to withhold the details of 
security issues indefinitely, we give users the opportunity to react to 
vulnerabilities in a timely manner, and to exercise their power as a customer 
to request an expedited vendor response.

With that said, we're going to be monitoring the affects of this policy very 
closely - we want our decisions here to be data driven, and we're constantly 
seeking improvements that will benefit user security. We're happy to say that 
initial results have shown that the majority of the bugs that we have reported 
under the disclosure deadline get fixed under deadline, which is a testament to 
the hard work of the vendors.

Thanks!
Ben (Project Zero Researcher) 

Original comment by haw...@google.com on 31 Dec 2014 at 11:34

[GoogleCodeExporter]

Anyone who thinks that unaddressed vulnerabilities should not be disclosed to 
hold the vendor accountable, I am assuming, also thinks that in situations such 
as GM covering up ignition switch issues, should have not been publicly 
released as well. Because GM thought they could get away with something, or let 
it ride.

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

[GoogleCodeExporter]

Interestingly enough on my Win 8.1 test box, "smartscreen" prohibited 
execution.  Sure I can bypass smartscreen, but thought that was interesting.  
On a side note as a vulnerability researcher, 90 days is more than enough time 
to respond to this issue. If MS needed more time to resolve the issue, they 
could have, or should have responded to the notification asking for such. 

Original comment by jti...@gmail.com on 1 Jan 2015 at 2:16

[GoogleCodeExporter]

very bad form on Googles behalf.
You guys should spend more time fixing all the bugs and exploits in your own OS 
before publishing in full how to exploit a windows machine, again very bad form 
for a company like google.

Original comment by isimp...@outlook.com on 1 Jan 2015 at 6:36

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I actually tried this. And UAC (at highest level) doesn't allow it to run and 
warns me that this program will make changes to my computer. I use UAC at 
highest level all the time by default for years.

If I change the UAC to the default level. Then calculator runs. However in this 
case I don't see any indication if it runs as an elevated mode. From the task 
bar the owner of the process is still my user. I will appreciate if some body 
can explain me how this has elevated priviliages

Original comment by empe...@gmail.com on 1 Jan 2015 at 7:33

[GoogleCodeExporter]

Regarding my post at #30 I think I was able to verify that calculator runs in 
elevator privileges. I tried to attach a debugger and then it asked my debugger 
to run in administrator mode. So it should have been running as elevated mode.
However, as stated, running UAC at highest mode solves part of the problem 
that, such an execution requires current users consent or it won't work

Original comment by empe...@gmail.com on 1 Jan 2015 at 7:38

[GoogleCodeExporter]

@empe I don't see a way in Task Manager (at least in Windows 7) to directly 
view the elevated state of a process. However there are a few indicators if you 
are using an unelevated (ie you did not click the "Show processes for all 
users" button) Task Manager:

1. Command Line column for elevated processes will not populate.
2. Right click "UAC Virtualization" option is disabled for elevated processes.
3. Attempt to change priority or affinity of elevated process will result in 
Access denied error.

I myself use a third-party task manager tool. Process Hacker includes a 
"Elevated" column which will show "Limited" or "Full" for all processes.

@jasoniv First, that is off topic for this discussion; if you feel you have 
found a bug in android you should check on the android bug tracker for existing 
issues and post a new one if it has not already been reported.

I will make an aside below to respond to your little rant, though.

There is no vulnerability there. It is part of the very core design of IAPs. 
The game itself is free, but users can choose to donate a few bucks to speed 
their progress in a game, for example. In essence, the game is free, and you 
are charging the user to increment some variable in memory. Apart from the 
monetary charge, everything happens on the user's device, so there is no remote 
server involved. Because of this, it is a service that is trivial to provide 
for free by other third-party tools such as the one you mentioned.

However, IAPs work because most users do not know about or want to use those 
tools, or can't (as mentioned on the page for that particular tool, it requires 
root). It's likely at least some percentage of users who use such tools would 
not pay for IAPs in any case, so it's hard to know the impact such tools would 
have on sales anyway.

Original comment by megazzt on 1 Jan 2015 at 8:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I commend Google for their great research and decision. 

Original comment by DKkid...@gmail.com on 1 Jan 2015 at 2:34

[GoogleCodeExporter]

In Task Manager for 8.1 (and probably 7 as well), you can right-click the 
column headers on the Details tab, choose "Select columns", then check 
"Elevated" near the bottom of the list. The resulting calc.exe shows "Yes" in 
that column after running this exploit, indicating silent elevation has 
occurred.

Original comment by ben.nord...@mediacombb.net on 1 Jan 2015 at 5:42

[GoogleCodeExporter]

Microsoft responded to the issue through a spokeperson, and is working on a 
security update. 
http://www.winbeta.org/news/google-researcher-exposes-unpatched-windows-81-secur
ity-flaw.

Original comment by jwal...@securityevaluators.com on 2 Jan 2015 at 7:56

[GoogleCodeExporter]

I'm a little confused if this is Elevation of Privilege or UAC bypass only. 
PoC only does UAC bypass.
(PoC does UAC bypass succesfully in my test, but not Elevation of Privilege so 
if users did not have admin rights)

Original comment by mei...@gmail.com on 2 Jan 2015 at 2:04

[GoogleCodeExporter]

Microsoft releases its main patches on the second tuesday of the month. The 90 
days deadline means that in most cases they won't be able to wait 3 patch 
tuesdays. 

Microsoft has 3 choices:
1/ fix it in time for the second patch tuesday.
2/ issue an out-of-band patch (usually a bad sign of 0day).
3/ or fail completely like this time.

This issue *might* be fixed on the january 2015 patch tuesday (2015-01-13)... 
but it might slip to and out-of-band patch in january or further in february 
2015.

Reminder: there is a pretty big prerequisite for issue to work... the user must 
have admin rights. AKA the 2015 version of "running with scissors". 
#FriendsDontLetFriendsRunAsAdmin

Original comment by faramir....@gmail.com on 2 Jan 2015 at 3:42

[GoogleCodeExporter]

for me the demo doesn't work. I see no calc.exe running after executing 
"AppCompatCache.exe c:\windows\system32\ComputerDefaults.exe testdll.dll".

I tried it on my Toshiba Encore 8 Tablet, 32Bit Windows 8.1 with December 
Update level.

Original comment by MagicAnd...@live.com on 2 Jan 2015 at 3:46

[GoogleCodeExporter]

RE: #37

That was my understanding when I read the description about the PoC.  It 
sounded like not only do you need to have valid credentials, but your user must 
be an administrator already.  So really, all it's doing is bypassing UAC which, 
if you already have Admin rights, isn't that impressive.

Can anyone confirm this?  That the PoC doesn't work if your user does not have 
admin rights on the local machine?

Original comment by imjee...@gmail.com on 2 Jan 2015 at 3:54

[GoogleCodeExporter]

in windows 10 tech preview w/latest update. it doesn't work as well,probably 
patched

Original comment by doga.ozkaraca@gmail.com on 2 Jan 2015 at 5:06

[GoogleCodeExporter]

Shame on Google for auto disclosing.  We know it was reported to Microsoft, but 
have no idea what the fix process looks like from their side.  Maybe they 
dropped the ball, maybe there were tons of app compat issues to work through.  
We'll never know.

All we truly know is Google just dropped the key to potentially a billion 
machines being owned.

If this company cares so little about our security (i.e. "being right instead 
of getting it right") why would you ever trust them with something important?  
Do no evil MY ASS.

Original comment by robbie.r...@gmail.com on 2 Jan 2015 at 5:30

[GoogleCodeExporter]

This is an incredibly bad policy on auto-disclosure, especially with a deadline 
over the holiday season.  Google is at best, being tone deaf about the 
realities of installed base software updating, which makes sense as they don't 
sell enterprise on-premises products as their business.  At worst, this is a 
calculated, reckless and childish attempt at 'competing' with Microsoft.

Particularly interesting to me is that Google is focused on security 
vulnerability disclosure, but doesn't allow third party testing of the 
Googleplex for security for customers prior to moving to Google's platform.  
This smacks of corporate competition wrapped up in the flag of 'doing right by 
the community', when in reality, they are doing great harm to the user base 
they hope to win and a great service to the Russian mob and the Chinese 
military.

As the former CEO of a vulnerability assessment firm, this behavior would have 
you listed as a 'grey hat' immediately for putting the public at harm.

I've said it before, if you have to make your company motto a reminder to not 
be evil, it's because your natural inclination is to be evil.

Really horrifically disappointing for a public company.

Original comment by Tommyaqu...@gmail.com on 2 Jan 2015 at 5:43

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

#42 - Can you show me any numbers where Windows 8.1 has been deployed to 
"Billions" of machines. 
http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcust
omd=0

They offered MSFT 90 days to address this. They did not. If someone at Google 
found this, then im sure its already up on 0day sites, and has been in use 
maliciously for months. Google shed light on the issue, called MSFT out on it 
and now it has prompted a response. All in a good days work.

Original comment by dpdoug...@gmail.com on 2 Jan 2015 at 5:51

[GoogleCodeExporter]

 too bad for those using windows

Original comment by ndumiso....@gmail.com on 2 Jan 2015 at 6:59

[GoogleCodeExporter]

kudos  , google security

Original comment by filipemu...@gmail.com on 2 Jan 2015 at 7:10

[GoogleCodeExporter]

#45 - if Google reported it to Microsoft, my guess is that they are working on 
it.  With regard to the billion comment, yes - look at market numbers.  
Microsoft always releases patches for every OS at the same time, so 90 days to 
patch Windows 10, 8, 7, Vista, Server 2008, XP, etc. all at the same time may 
be harder than we realize.  I don't know.  (Neither do you, though.)

All I know is that I'd much rather Google call Microsoft out publicly for being 
slow (and keep beating that drum until they fix it) than expose the problem in 
great detail, putting a billion customers at risk.

THAT's a company that I will not trust with a driverless car...

Original comment by robbie.r...@gmail.com on 2 Jan 2015 at 7:16

[GoogleCodeExporter]

This is a publicity stunt. It's a UAC bypass...not a priv esc exploit. UAC is 
not security feature...and Microsoft has publicly stated that. Look at how long 
they took to patch the original UAC bypass. This is just a publicity stunt to 
say Google releases Windows 0day. 

Original comment by bon...@gmail.com on 2 Jan 2015 at 8:34

[GoogleCodeExporter]

To all those complaining that Google shouldn't have disclosed this, enjoy your 
security by obscurity delusion. 

Original comment by dcapar...@gmail.com on 2 Jan 2015 at 8:52