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 doesnt correctly check the impersonation token of the caller to determine if the user is an administrator. It reads the callers impersonation token using PsReferenceImpersonationToken and then does a comparison between the user SID in the token to LocalSystems SID. It doesnt check the impersonation level of the token so its 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. Its 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. Id 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 doesnt 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. poc.zip 110 KB Download Oct 1, 2014 Project Member #1 fors...@google (No comment was entered for this change.) Labels: MSRC-20544 Dec 2, 2014 Project Member #2 fors...@google (No comment was entered for this change.) Labels: -Product-Windows Product-Windows-Kernel Dec 29 (6 days ago) Project Member #3 fors...@google Deadline exceeded - automatically derestricting Labels: -Restrict-View-Commit PublicOn-2014-Dec-29 Deadline-Exceeded Dec 30 (5 days ago) #4 wangwei...@gmail nice Dec 30 (5 days ago) #5 [email protected] Automatically disclosing this vulnerability when a deadline is reached with absolutely zero context strikes me as incredibly irresponsible and Id have expected a greater degree of care and maturity from a company like Google. My reading of the disclosure is that its your average local privilege escalation vulnerability. Thats bad and unfortunate, but its 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 theres an MSRC ID? Has there been a delay on Microsofts end because of certain engineering complexities? Christmas has just passed and today is New Years Eve, so realistically, many employees from both Google & Microsoft are likely on leave. Thats unfortunate, security issues dont care about the time of year, but its 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 isnt typically quick or easy. Mistakes from rushing cost lots of time and money; anyone whos 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 & MSFTs respective security teams is fairly poor. Seeing things like this certainly goes a way to explaining why. Dec 31 (4 days ago) #6 st33lf...@gmail Nice! Dec 31 (4 days ago) #7 greig.mi...@gmail Couldnt get this to execute on recent Windows 10 Builds. Possibly been patched? Dec 31 (4 days ago) #8 idra...@gmail 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. Dec 31 (4 days ago) #10 Russell....@gmail 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 Microsofts bug database. Pure speculation makes it easy to paint people as the bad guys. :) Dec 31 (4 days ago) #11 mickrrus...@gmail 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 doesnt bring anyone closer to a solution. I find it difficult to believe that MSFT and GOOG dont 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. Dec 31 (4 days ago) #12 martinit...@gmail 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. Dec 31 (4 days ago) #13 mickrrus...@gmail @ #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. Dec 31 (4 days ago) #14 hdms...@gmail Props to Google for sticking to their timetable. Todays 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. Dec 31 (4 days ago) #15 [email protected] 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 isnt 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. Dec 31 (4 days ago) #16 magne.ig...@gmail Attackers are not going to take the day off because its 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 isnt doing this to make friends. They are doing this to address a widespread problem of companies releasing insecure products. Ignoring a security vulnerability isnt going to fix it either. Dec 31 (4 days ago) #17 martinit...@gmail @ #13 mickrrus... chaos, mayhem, riots and discord .... I dont see that yet.. lets 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. Dec 31 (4 days ago) #18 freddyt5...@gmail You Google suck-ups are sickening. This is bad form by Google. No, attackers dont take the holiday off, thats precisely why you dont reveal the vulnerability when they can take most advantage of the head start theyd be getting before a patch is made. Think, people! Dec 31 (4 days ago) #19 [email protected] 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 theyre disclosed. Its not about sucking up to Google, its about the reality that most people can do a lot to mitigate an unpatched vulnerability if only they know its there. By letting everyone know, they at least allow those who are vulnerable to start taking their own preventative countermeasures. Dec 31 (4 days ago) #20 hdms...@gmail @ #18 freddy - Microsoft had three months to resolve this and were aware of Googles 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. Dec 31 (4 days ago) #21 jwal...@securityevaluators Disclosing vulnerabilities is like the prisoners dilemma in game theory. You play by the rules until the other side does not. Google made the optimal move when responsible disclosure failed. Dec 31 (4 days ago) #22 hallstev...@gmail Can Microsoft employees have a Christmas Season with family... They had 80+ days - well, subtract a few for Thanksgiving ? Dec 31 (4 days ago) #23 jerem...@gmail 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. Dec 31 (4 days ago) #24 jpot...@gmail Microsoft have been aware of escalation vulnerabilities with the UAC whitelist system for **years** and done nothing, I dont see why this should be any different. See e.g. pretentiousname/misc/win7_uac_whitelist2.html Dec 31 (4 days ago) Project Member #25 haw...@google Thanks for the robust discussion everyone. Weve been watching this thread develop, and although the bug tracker is intended for technical analysis and bookkeeping related to the specific issue described, were 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 Zeros disclosure deadline policy has been in place since the formation of our team earlier in 2014. Its 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, were going to be monitoring the affects of this policy very closely - we want our decisions here to be data driven, and were constantly seeking improvements that will benefit user security. Were 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) Dec 31 (3 days ago) #26 illusio...@gmail 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. Dec 31 (3 days ago) #27 jti...@gmail 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. Dec 31 (3 days ago) #28 isimp...@outlook 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. Dec 31 (3 days ago) #30 empe...@gmail I actually tried this. And UAC (at highest level) doesnt 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 dont 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 Dec 31 (3 days ago) #31 empe...@gmail 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 wont work Jan 1 (3 days ago) #32 megazzt @empe I dont 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 users 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 cant (as mentioned on the page for that particular tool, it requires root). Its likely at least some percentage of users who use such tools would not pay for IAPs in any case, so its hard to know the impact such tools would have on sales anyway. Jan 1 (3 days ago) #34 DKkid...@gmail I commend Google for their great research and decision. Jan 1 (3 days ago) #35 [email protected] 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. Jan 1 (2 days ago) #36 jwal...@securityevaluators Microsoft responded to the issue through a spokeperson, and is working on a security update. winbeta.org/news/google-researcher-exposes-unpatched-windows-81-security-flaw. Jan 2 (2 days ago) #37 mei...@gmail Im 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) Jan 2 (2 days ago) #38 faramir....@gmail Microsoft releases its main patches on the second tuesday of the month. The 90 days deadline means that in most cases they wont 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 Jan 2 (2 days ago) #39 MagicAnd...@live for me the demo doesnt 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. Jan 2 (2 days ago) #40 imjee...@gmail 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 its doing is bypassing UAC which, if you already have Admin rights, isnt that impressive. Can anyone confirm this? That the PoC doesnt work if your user does not have admin rights on the local machine? Jan 2 (2 days ago) #41 doga.ozkaraca@gmail in windows 10 tech preview w/latest update. it doesnt work as well,probably patched Jan 2 (2 days ago) #42 robbie.r...@gmail 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. Well 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. Jan 2 (2 days ago) #43 Tommyaqu...@gmail 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 dont 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 doesnt allow third party testing of the Googleplex for security for customers prior to moving to Googles 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. Ive said it before, if you have to make your company motto a reminder to not be evil, its because your natural inclination is to be evil. Really horrifically disappointing for a public company. Jan 2 (2 days ago) #45 dpdoug...@gmail #42 - Can you show me any numbers where Windows 8.1 has been deployed to Billions of machines. netmarketshare/operating-system-market-share.aspx?qprid=10&qpcustomd=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. Jan 2 (2 days ago) #46 ndumiso....@gmail too bad for those using windows Jan 2 (2 days ago) #47 filipemu...@gmail kudos , google security Jan 2 (2 days ago) #48 robbie.r...@gmail #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 dont know. (Neither do you, though.) All I know is that Id 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. THATs a company that I will not trust with a driverless car... Jan 2 (2 days ago) #49 bon...@gmail This is a publicity stunt. Its 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. Jan 2 (2 days ago) #50 dcapar...@gmail To all those complaining that Google shouldnt have disclosed this, enjoy your security by obscurity delusion. Jan 2 (2 days ago) #51 davidsar...@googlemail To the people who are missing the point of what the vulnerability is, read the description more carefully: NOTE: This is not a bug in UAC, it is just using UAC auto elevation for demonstration purposes. Its a local privilege escalation bug and it does not depend on the user already having admin rights, even though the proof-of-concept may have limitations in that respect. The 90-day automatic disclosure is entirely reasonable. It absolutely should be automatic, in order to give engineers for the vulnerable product a predictable deadline and to eliminate politics. BTW, Windows is chock-full of local privilege escalation bugs. It always has been and always will be; the architecture makes them inevitable. Jan 2 (2 days ago) #52 jason.st...@gmail These comments are generally terrible. Jan 2 (2 days ago) #53 mjhouse...@gmail 90 days is more than enough time for a company, especially one the size of Microsoft, to issue a patch to fix this. Yes, this makes current operating systems vulnerable, however it also makes Microsoft take ownership. I bet next time there is an issue like this Microsoft will think twice before letting the 90-day window expire. Jan 2 (2 days ago) #54 jamesc...@gmail Lets say that Google didnt release the bug until MSFT patched it (and, according to the logic of many people here, the patch is deployed to all machines). In that time millions (or billions (?)) of computers are taken over by a hacker or a botnet or the NSA. Huge scandal, lots of news stories, etc. At some point a GOOG security researcher mentions, oh? that? yeah... we knew about that for a year but we didnt feel comfortable releasing it. That scenario seems infinitely worse and more irresponsible. Jan 2 (2 days ago) #56 bra...@gmail I was testing this vulnerability and while I was not able to replicate either chaos, mayhem, riots or discord, it does appear that my dog and cat are now living together for what its worth. Honestly now public vulnerability disclosure is not a new thing and it was done appropriately in this case people dont make me put my hands on my hips or sigh derisively. Jan 2 (2 days ago) #57 office.m...@googlemail Fixed on Windows 10. Jan 2 (47 hours ago) #58 davian...@gmail Also fixed on Windows 11! How does that help anyone? Jan 2 (46 hours ago) #59 davidsar...@googlemail Are the people who are confidently saying this has been fixed in Windows 10, basing that on any more evidence than that the PoC doesnt work for them? Because the PoC is somewhat fragile and there are many reasons why it might not work on a particular system, regardless of whether the underlying vuln is fixed. I assume Google is in communication with Microsoft and will close this bug if and when it is actually patched. Jan 2 (43 hours ago) #61 habte.yi...@gmail this bug is more like meh! this is not even a great or critical bug. its a normal classic bug anyone couldve find. you cant blame Google or Microsoft. As I am sure, there are more critical bugs Microsoft is trying to fix that are silent. I am sure Microsoft didnt lie on a bed for 90 days. that obviously tell us they are addressing more critical issues than this one. the fact this gained media attention might seem like this is a very bad issue but given the prerequisites this needs to succeed, this is no more than a very low issue. and Kudos for Google for sticking for their policy. Thanks!
Posted on: Mon, 05 Jan 2015 01:39:31 +0000
Trending Topics
Recently Viewed Topics
© 2015