Deadline exceeded - automatically derestricting

nice

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.

Nice!

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

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.

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. :) 

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.

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. 

@ #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. 

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."

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.

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.

@ #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. 

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!

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.

@ #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. 

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.

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

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

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.

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

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) 

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.

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. 

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.

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

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

@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.

I commend Google for their great research and decision. 

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.

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-security-flaw.

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)

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

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.

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?

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

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.

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.

#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&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.

 too bad for those using windows

kudos  , google security

#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...

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. 

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

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."

It's 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.

These comments are generally terrible.

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.

Let's say that Google didn't 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 didn't feel comfortable releasing it."

That scenario seems infinitely worse and more irresponsible.

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 it's worth.

Honestly now public vulnerability disclosure is not a new thing and it was done appropriately in this case people don't make me put my hands on my hips or sigh derisively.

Fixed on Windows 10.

Also fixed on Windows 11!
How does that help anyone?

Are the people who are confidently saying this has been fixed in Windows 10, basing that on any more evidence than that the PoC doesn't 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.

this bug is more like meh! this is not even a great or critical bug. its a normal classic bug anyone could've find. you can't 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 didn't 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!

I have found that the included Binary does the exploit reliably on Windows 8.1 x64. However - if I recompile it I no longer get the desired effect. This just makes the PoC unreliable.

It doesn't surprise me that newer versions that aren't released won't work - the way this runs (from reading  the code) means that any changes in certain Windows Internals render it mute - but that doesn't mean it can't be quickly changed.

Privilege escalation bugs are serious things. Let's hope they sort it out.

What is the motive to publicise any vulnerability in public and even with all the steps to break in? MSFT must have few patches to consolidate and then planning to release in one go, considering the size and versions (32 and 64 bit both). Since we clearly do not know what communication that happened with Google and MSFT on this, but if "grace period" was sought and given, then it should not go "automatically" visible after 90 days got over. Lets just hope for the best with Windows 10

I study this a little more and yes, this is not only UAC bypass.

However, I'm quite sceptical there is any other use for this vulnerability than UAC bypass. (With this cache poisoning, you can’t just do direct shim)

Also, I'm not saying UAC bypass is not serious.

Modifying one word in the source file of the DLL made me open command line in elevated privileges. Nothing more to say!

"Don't be evil"

I fully agree with google's disclosure policy, 90 days is enough to address the issue actually the time ought to be smaller than that. 

Hm it appears not to be working on windows 10 x64 (tech preview) in vmware and windows 7 x64.
both give me "Error adding cache entry: C000000D"

Virus Scan (virus total)
https://www.virustotal.com/en/file/4c3a29a77d663d99039eac3046a3e11e0e73a6043e269517d91cf6b3a2a06998/analysis/1420305224/

Hi All,
   I wanted to test this one out. In order to do so I recompiled the TestDll.dll to execute cmd.exe (calc gives no flexibility!) and then tried the following command: AppCompatCache.exe c:\windows\system32\ComputerDefaults.exe testdll.dll

Tried this on a standard command prompt and it doesn't appear to give a system shell.  My version of Windows is: Windows 8.1 (Version 6.3.9600).

I've verified that items 1-3 above have been satisfied but no success.  Has anyone else been able to verify this exploit?

Also, as an aside, requirement number three above (by OP) indicates the user has to have "split token" admin privileges. Having access to a user with this level of privileges is essentially game over from a hacker's point of view.  What I am wondering is how is this exploit any better than performing (as a split-token admin):

1. Find cmd.exe
2. Right-click and select run as admin
3. From the administrative prompt run psexec like this (psexec -i -d -s cmd.exe) 
4. Execute 'whoami' from the new cmd prompt. 

The above will provide a system shell to *any* split-token admin.

So am I missing anything?  Or is this a real non event? Why would you bother having to trigger an exploit when you have all the access required anyway?  It might explain why MS haven't done anything as from what I can tell this exploit doesn't give you anything you don't already have as a split-token admin.

If I am incorrect please help steer me back on the right path, I'm always trying to learn more in this area.

Thanks,
Patrick

@ #73, I tried the cmd thing myself and it worked.. Windows 8.1 x64, You might want to try multiple times though. Your points regarding being a split-token admin are valid though, I hardly think a standard user on a domain would be able to use it for instance.

its best google published it ... than in the hands of underground russian hackers thats if they aint using it yet... because i find it amazing microsoft dont do alot in making sure there os is not exploitable ... every now and then cases on exploits from microsoft products... thanks Google..

You Google suck-ups keep saying 90 days is enough time, but why is 90 days the APPROPRIATE amount of time? Why not 100 days? Why not 120 days? Who cares? The fact that Google mindlessly disclosed it like an automaton without using any discretion and consideration of the realities of life is what is disturbing. The fact that you Google fanbois commend this behavior is even more so.

doesn't seem to work on windows 10 technical previews.Error adding cache entry,

I agree with freddy (#77). Google want to troll Microsoft than want to help

Anybody read #51? It says, the POC is not the real thing, it has limitations.
If it were the real thing, this would be only a UAC bypass. Lately I learned in an MS forum how UAC bypasses are treated: they are not even called security vulnerabilities by Microsoft... Read for yourself: http://technet.microsoft.com/library/cc751383.aspx says "A weakness that would allow to bypass the “Consent Prompt” is not considered a security vulnerability, since that is not considered a security boundary". Now as funny as this may sound, this together with the fact that MS is concerned about this, should mean it is not "only" a UAC bypass... or MS has changed its mind :)

No, I have not tried the POC myself as comments suggest it's not the real thing.

This looks like a simple privilege escalation weakness and not a vulnerability. If you report something like this to Microsoft you will get an email thanking you for reporting the "bug", they will also tell you that the issue will be fixed in the future and that Microsoft does not think this weakness should be fixed through the release of a separate patch. 

Microsoft does not consider "UAC Bypass" as a security vulnerability.
so its totally fine to disclose this.

This is in follow up to my questions posted in @73.  Post @51 points out that UAC was simply used to demonstrate the issue but there are other ways a user without split admin rights can trigger the vulnerability. @80 says the same thing.

From what I can tell this POC uses an auto-elevate function to create a cache entry which the exploit can leverage to gain higher privileges.  In the real world there may be existing cache entries, from previous admin access, to use or there may be other vectors to trigger this issue.

The OP says "the trick would be finding a suitable pre-existing app compat configuration to abuse."  So I guess this is the pre-condition a limited user would need in place for successful exploitation. This POC contrives this situation with the requirement to run ComputerDefaults.exe as a split-admin to populate the cache and then attempt to trigger the exploit.

Heartbleed was fixed in 1 day as long as I can remember. If you have big security hole and nearly unlimited resources as Microsoft, then they can fix it in few hours. 90 days is way too long. 3-5 days is normal for fix. The rest 85 days are for users to update.

Note that Microsoft has often advertised UAC (or at least, vaguely specified "new security features" that could only in context have meant UAC) as having security benefits to end-users. To security researchers, in contrast, they consistently claim that any attack on it is not a security vulnerability in order to avoid having to fix its --deep, structural, and probably unfixable at this point-- design flaws.

Although it probably wasn't the original plan (see below), this has had the effect of allowing them to benefit from marketing it as a security feature without the engineering effort of actually having to make it secure. (Considerable effort was still needed to stop UAC from breaking too many existing apps, which required a bunch of complex virtualization.) Yay!

In case it isn't obvious, a "security mechanism" that doesn't enforce any security boundaries is no security mechanism at all.

UAC absolutely *was intended* to enforce security boundaries when it was originally designed -- as was the closely related UIPI, which they've since taken a similar position on. You don't spend as much effort on implementation and maintenance or impose the kind of usability costs that UAC and UIPI impose (on both end-users and developers), without intending there to be a security benefit. Actually, they completely fluffed it and there is no real security benefit against competent attackers; the inconsistent stance described above is a consequence of trying to avoid losing face over that.

Sorry for the mildly off-topic rant. It is off-topic because *actually this bug is not just a UAC bypass*. But the margin of this message is not large enough for a proof of that.

@5

It is infinitely more irresponsible not to disclose this bug. I won't comment on usage, however more likely then not, if Google has found it, so has someone else, and how much are you willing to bet that this theoretical individual is of the same moral fiber as the researcher who posted this bug? I will not bet any of my systems on them being benign, I will assume they are malicious. Now that the vulnerability is disclosed *I* can do something to attempt to block it, or something similar, from happening on my boxes. 

I think that the probleam was that google publish the vulnerability, if was an independent researcher, maybe would not be attacked in this form.

I think that Google deserves a kudos for releasing this vulnerability. Blissful ignorance is not a security strategy. If a researcher at Google was able to find this and report it to Microsoft then that is a win. A less ethical person may be able to find the same issue and exploit it rather than report it. The 90 day window in my opinion is too large. The fix should be made available much sooner. Millions of computers are left exposed for 90 days. 

Public interest is best served by addressing issues transparently. The infrastructure that we call the internet should have safety standards that are reviewed and brought to accountability. Lulling users into a false sense of security is not the best way. Vulnerabilities are a bigger problem when they are out in the wild before they vendor is aware. 

Thanks Google. 

Google was wrong with what they did. They don't have all of the OS code so they have no idea how much other code would have to be rewritten to correct the problem. That extra coding takes time to ensure that something else doesn't get broken in the process.

As a semi-reformed black hat, I find it interesting how those that think Google is correct with what they did don't realize that Google is also one of the biggest sellers of personal information which is gleaned from the data they collect whenever any of their products are used. This includes those background programs that most end users are unaware of such as the analytics that are a well hidden data collector on a majority of web sites these days. If you think Google is right for disclosing the information then you most likely also condone their selling of your information to whoever wants to pay for it. The bottom line is that Google is the biggest single security risk on the internet to anyone that goes online. I have all the proof I need that they do sell your information as they are the ONLY site I ever gave a certain email address to and within a matter of two weeks there were over 500 spam emails sent to the account. I know for a fact that Google was the ONLY company the email address had ever been given to or used with because it was a test to prove what they are really doing with personal data. Based on the content of the spam that was received, they sold my information to everything from cosmetics companies to  pharmaceutical companies to porn sites. All of this from the day I signed up for gmail and had to give an alternative email address. Funny how none of the spam ever ended up in the gmail account.

As for comment #89 - "The infrastructure that we call the internet should have safety standards that are reviewed and brought to accountability." How in the hell do you think that something as open as the internet could have any type of safety standards or accountability? You do realize that can only be accomplished by some country actually controlling the internet with censorship, etc.

This is *not* a difficult bug to fix. Look at the description; it says:

"[NtApphelpCacheControl] 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 [...]"

The needed fix is just in that specific code. Nothing else needs to be rewritten. 90 days is perfectly sufficient; for this particular bug, 9 days should have been sufficient. Microsoft just dropped the ball.

More generally: the most important thing about a disclosure policy is to *STICK TO IT*. The policy was clear in advance and has been correctly followed. It is a really bad idea to make ad-hoc exceptions for particular vulnerabilities.

(That's not to say there shouldn't be a procedure for requesting an extension. Maybe there is, and Microsoft just didn't follow it. Remember that there will have been communication between Google and Microsoft that isn't visible on this bug ticket.)

We already disliked Google for "Being Evil" now this make us dislike Google even more.

Wow... so many retards. Bug was reported to Microsoft 90 days prior to the publication of this bug. Microsoft were aware that this would be happening. If you think this is a bad move on Google's behalf, you are an idiot.

I think public this bug or any other bug after 90 days is a good solution, it ask all software company to fix it asap instead of hide it from the end-users.

Such as: The same bug also be found on Windows NT 4 (used to use by many company long time ago) which allow every guest user can get the administrator privilege. It is more dangerous than windows 8 because this OS was use by many IT company, school, ...

But Microsoft never fix it until now, they leave all bushiness company leaving with a serious problem without any note.

Google is not evil. Microsoft just slept and did not fix the vulnerability in time. Good job google

#94 The bug that you mean, is to use the "escape" button at login session ? It's very different that we have here. 
For example it work too (in different way) in Windows 7/8 : http://www.technibble.com/bypass-windows-logons-utilman/

What we have in this topic is to get elevated privilege in a already logged session which is not administrator. (Ex of use : Installation of malware with admin right silently)

It's a "little bit" different. :)

#97: No, the bug on Windows NT 4 is allow any logged in user (even guest) can get the administrator privilege to install, remove, create new admin account or even delete the current admin account.

I don't know how to do it but we able to download the tools from the Internet with only few click (year 2002-2004, I don't know we can now find that tools or not ^_^)

That bug did same thing with this bug.

All most windows NT 4 versions (Windows NT 4.0 Workstation, Windows NT 4.0 Server) got that problem. I never check on Windows NT 4.0 Terminal Server Edition so I don't know how about it.

Did someone test it on domain computer?

@99 Yes, it work too.

first post

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

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.

@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.

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?

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.

#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

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

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.

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.

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... ;-)

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. 

Thanks for coming back to clear that up!  Keep up the good work.

(Comments relating to the disclosure debate are welcome on this issue, but any comments that are not constructive, or involve ad-hominem attacks, etc. may be deleted.

See https://code.google.com/p/google-security-research/issues/detail?id=118#c5 as the first example of a reasonable and respectfully constructed argument against the 90-day disclosure.

See https://code.google.com/p/google-security-research/issues/detail?id=118#c12 as the first example of a reasonable and respectfully constructed argument for the 90-day disclosure.)

Security not obscurity.

It's unbelieveable how people think that letting lazy devs get away with not fixing a vulnerability after 3 months is fine.

As time goes, this will happen less and less because microsoft will know that they actually can't get away with not fixing a vulnerability for so long after being aware of its existence.

The 90-day disclosure is necessary and it will help making the internet safer.

One would think that, after seeing and fining the same security issues in EVERY release of the Windows operating system, they would have a process in place for banging on each (already) exposed vulnerability BEFORE a release.  So sad that these are being promulgated from version to version.  Well done, Google.

I support google and advise everyone to choose another operating system where security is taken seriously, 

it is unacceptable that microsoft thinks it is OK to wait until last minute , instead of fixing it in the NEXT patch tuesday.

Reading the news articles about this is quite fun. A lot of the early articles have absolutely no clue what this "Zero" initiative is supposed to be about and pretty much the only thing of substance they contain is a quote from comment #5.

Many articles say "We contacted Google and got no response", while there are already "Project member" comments right here starting from #25 on Dec 31, 2014. This is much better source of official information than some "we contacted their PR division", why journalists don't use it?

Now this article on BBC http://www.bbc.com/news/technology-30779898 says "On 11 January, Google publicised the flaw. Microsoft said it had requested that Google wait until it released a patch on 13 January." I wonder where they got the January 11 date¸

Anyways, that BBC article has a link to Microsoft's senior director of research Chris Betz's blog post "A Call for Better Coordinated Vulnerability Disclosure" http://blogs.technet.com/b/msrc/archive/2015/01/11/a-call-for-better-coordinated-vulnerability-disclosure.aspx

Remedy for this is easy. Until MS patches this, run a batch at start up that checks the tmp and temp path, if they differ from what is expected write the correct path to the registry and alert the user of the deviation. 

This is no real big deal. 
Google has their 90 day policy, for good or for bad. Microsoft knew that this was the case, they decided to wait. Reading a little more into it, if Microsoft did not think it a big deal, then it might not really be. 

Go back and read the bug. You will find that wile it is a gaping hole, a short term fix as what I propose above will act as a finger in the dyke, until Microsoft has a patch ready. If this bug affects your security, then you should not be using Microsoft for whatever you are doing. 

If you want real security use another OS. If your security needs do not exceed the needs of the NSA, then Microsoft is fine!

At everyone complaining over this:

Imagine the 90 day disclosure policy would not be adhered to, and the message this would send.

The message would be something like "There's no 90 day disclosure policy, just a 90 day disclosure empty threat" which would remove the entire point of the policy; to pressure software developers into actually fixing their problems within a reasonable time.

How about, instead of disclosing a bug completely, have a 2-step deadline?
You could disclose all information necessary for sysadmins to find and apply a patch without giving away every detail on how the bug can be exploted.
This could be done after 90 days, with the full disclosure happening a month later or so.

Totally irresponsible by Google.
 
Google are not the "net security police" and after a request by MSoft to delay the public announcement Google decided to tell everyone. If my system was attacked by this irresponsibility who would be at fault, clearly MSoft for the flaw and Google for publicising it. For me Google clearly have some responsibility to end users. It is not always so easy to patch any software in a short time as code changes may introduce more vulnerabilities . Although I agree with highlighting vulnerabilities it does need control over what is actually made public.

#122: For background to the BBC article information please refer to issue 123. It has a PublicOn-2015-Jan-11 flag and January 13th is the first 2015 patchday for Microsoft Windows.

Fwiw it looks to me like this could have been planned by MS all along to force this discussion. On the other hand that thought instantly gets irrelevant when applying Hanlon's razor.

Anyway, in order to ensure a more sophisticated discussion of the matter (especially in the media) I'd vote for the Google Security Research Team / Project Zero to have an updated statement (not the 2010 one with a 60-day disclosure still written in it) about their responsible disclosure policy and timeline, probably like a "media-relations"-page. This should also address the first paragraph of comment #122. It can be as simple as an update to the 2010 article with inclusion of some thoughts from the "Announcing Project Zero" Blogpost, written into a background/media-relations page that not "just gets lost" like a Blogpost but has several links to it so even the laziest / most time-limited journalist get a grasp of the background and the greater cause of this project.

And while I'm here: Thank you Google Security Research Team for making the Internet a safer place for all of us, even for those who (have to) use software from one of your main competitors.

#127 Oh, there are two privilege escalation entries! Did not notice the second one.

Since this become sort of an ad-hoc discussion group, what do you people think about the other side of this issue -- patching and planned obsolescence. Regarding especially https://community.rapid7.com/community/metasploit/blog/2015/01/11/google-no-longer-provides-patches-for-webview-jelly-bean-and-prior

My take on it is that phone vendors are not delivering the updates to customers anyways, so it does not really matter whether Google is making them or not. Microsoft here is at least doing _some_ patching. And Apple managed to keep the iPhone ecosystem under their control so they can also guarantee security for their customers. This is the aspect where "united, but not the same" does not pay off.

What happened to do no evil?  Listen, you could have posted this bug without all the detail to allow anyone to use the bug to elevate themselves.

Why post all the detail?

This is absolutely disgraceful behaviour for an individual to post let alone for a supposedly responsible company.

While 90 days seems adequate, high value issues in Q4 should probably get some extra time, no? It's unlikely that fixes in Q4 could get the same QA resources as other quarters.

While I fully agree that public disclosure is a good thing, releasing this POC just a couple of days before the fix was to be released during Microsoft's (very well established) "Patch Tuesday" cycle is bad, bad form - especially if they had specifically requested you not to.

I understand that you are trying to hold yourselves to higher standards, but in truth, you've just come across as a bit petty and unprofessional as a result. If Microsoft failed to adhere to their deadlines, then fine, go ahead and release. But to not even give them a chance, is pretty poor in my book.

I like the fact that you have referred to your own internal defined schedules that you agreed "earlier in 2014". Patch Tuesday was introduced in 2003 as a way to reduce workload and overhead for IT departments when releasing security patches to large infrastructures, rather than having them come through piecemeal during the month. Of course, being important security researchers, I guess you'd know that...

Sorry guys, but I'm pretty disappointed here. I'd have thought that you'd have taken a more mature attitude to this :-/

I kind of agree that automatic disclosure is bad, there should be a person who makes the decision based on certain facts. Like if 90 days have passed and the next  release is within few business days, then hold off on disclosure. But that would require companies to have well documented release cycles (arguably MS does), however if the next release is another 15-20 days later, then Google should release the details. 90+/- a few days is more than enough to fix issues. 

These companies are large corporations, so "lack of/tight on resources" argument doesn't fly. If the disclosure is made flexible, no business/project manager is ever going to find a resource to work on the issue immediately. I have been in the software industry long enough to realize that without the spotlight on a particular issue, there will always be another project that will have higher priority.


Should there be an allowance for "Holiday" season? Probably not, all of these companies have a global workforce, it is going to be "Holidays" somewhere in the world, does that mean we have a perpetual delay in disclosure? Even if it is not a global company, the workforce is diverse enough. These companies already staff crews during the holidays (with additional incentives), why can't developers (I am one), be given a choice to work during holidays? 

#132 The problem is that they are not manually releasing these. The PoC is attached to the post at the time of reporting and these tickets are automatically set to public after the 90-day deadline. Microsoft has released emergency patches before regarding certain vulnerabilities, the 90-day disclosure policy with attached PoC is more than adequate.

They also may have asked Google to hold off releasing, however that itself is bad form, holding back a vulnerability report is as bad as it not being fixed and if Google extended it for Microsoft, why shouldn't they do it for other companies? It sets a bad precedent that requires Google to change their automatic 90-day disclosure policy simply because developers/vendors would rather have a vulnerability hidden under a rug, so to speak. Not only that, but if Google can find these vulnerabilities, then who's to say that hackers don't already have them?

hackers already have them.

On Mon, Jan 12, 2015 at 10:41 PM,
<google-security-research@googlecode.com> wrote:

I am under the impression that the 90 day limit is to encourage vendors to fix vulnerabilities.  Is there reason to believe MSFT isn't/wasn't doing this?  MSFT has a well publicized, repeatable, and reliable release schedule for fixes.  It fits poorly with the automatic reveal that GOOG uses, but by not being sensitive to this, GOOG is arbitrarily appointing itself as the keeper of release standards.

I can understand GOOG releasing information if MSFT had not/does not release a patch on their publicized patch date that is APPROXIMATELY 90 days after report.  Enforcing without sensitivity to reality is arrogant at the least and evil at the worst.

#134 I'm quite sure that Google could have manually extended the automatic release by a couple of days without hurting anyone.

The thing is that these are complicated pieces of software and it can take time to evaluate, fix and test a release. And that's before you even consider the numerous versions of Windows that Microsoft have to manage - even a small patch can result in multiple different versions, each one having to be tested and validated individually.

And from an IT point of view, it's much more preferably to be able to bulk-test patches once per month and release them in one go, rather than the enormous overhead of having them come through in an ad-hoc manner. Microsoft introduced monthly patch cycles as a response to requests from IT professionals who much preferred to handle patches in batches rather than one by one.

While I appreciate that 90 days /is/ a reasonable time period to resolve issues, a failure to be flexible on this (especially when the vendor was clearly engaged and working on the issue) is, frankly, amateur behaviour. It's the sort of thing that a spiteful script-kiddie might choose to do, not an employee of a trusted IT business.

I'd like to think otherwise, but I do wonder if there was an ulterior motive here - to release the vulnerability 2 days before the patch, hide behind an arbitrary deadline and point the finger at a vendor who didn't patch the problem.

Google should have been congratulated for finding this bug, but I'm afraid that I find myself unable to do so because of the way they did it. Sorry guys :-/

Disclosure and patch policies have been commented on in great detail. This just made radar: https://community.rapid7.com/community/metasploit/blog/2015/01/11/google-no-longer-provides-patches-for-webview-jelly-bean-and-prior

Fixed in https://technet.microsoft.com/en-us/library/security/ms15-001.aspx

#134 Holding back a vulnerability REPORT is a bad thing indeed but releasing the full exploit to a vulnerability because they did not release a patch within an 3rd party's self induced deadline is irresponsible.

So what's the appropriate amount of time to give when a vendor asks for an extension?

Considering that MS already had 3 "regularly scheduled" patch tuesdays (fine... 1 of which was one day after the report, so let's just say 2, where 1 of them was with 30 days notice), how much more time do you provide MS (and others) on request?

2 days? 20 days? 40 days? Always round up to their next regularly-scheduled patch date (even if that's in 29 days)? What if regularly scheduled patches are every 2 months? 

And what do you do if you have reason to believe that the exploit has already been discovered by black-hat hackers and is being used in the wild? Let's say Google found this because it was being used against them. How does that affect your responsibility to alert the public? Is it responsible to not make it public (allowing sys admins to detect and prevent) it for 90 days? 110 days?

 

Damn! Who has CVE-2015-0001 then?

wordpress, obvs.

On Tue, Jan 13, 2015 at 10:49 PM,
<google-security-research@googlecode.com> wrote:

You all respect.

Also, the way you assume your few dozen reports are the ONLY thing that Microsoft needs to handle at any given moment. Well, guess what, they have millions of other things to do as well (just like YOU), so no, 90 days may not necessarily be enough just because you decide it is, according to YOUR standards, YOUR processes and YOUR schedules.

Well,it's is paying for support that is promised by MS,  and I expect them to fulfill their duties. I am happy about every exploit that is discovered in any software so the manufacturer can fix it in order that nobody will be able to use the exploit in secret. 
And for a crucial system component like an OS  I expect the manufacturer - that is Microsoft in here - to react to those exploits as fast as possible.  I pay for the system,  entire production facilities depend upon this OS,   so yes,IMHO I am in the position to demand from Microsoft to fix exploits with highest priority.   

I believe what Google doing is right in long term:


1. 90 days is enough time to make a patch: MS argues Google should wait until MS release patch. What if it's not ready on the day? Google should wait another month? It's MS's responsibility to patch ASAP; They are not supposed to ask Google to hold the information disclosure. I would say Google can wait if it would not happen again, but this may bring up same situation again and again. At the end, customer would be the one who will take disadvantage using the vulnerable software.


2. I believe Google apply all rules to all company depends on vulnerability risk level. If it cause more issues to MS, that means MS has some issues on their end:
 a. MS might have more vulnerabilities on their software 
  OR 
 b. they don't have good enough system to fix vulnerabilities in time. If MS don't have good enough system to handle this situation, is MS good enough company to lead the computer industry? MS complains Google was pushing the risk to customer. But on the other hand, MS is taking customers as hostage to claim 'easy deadline' for MS. Is it really right thing?

And its gone. Tried it today Windows 8.1U1 no dice.

Really awesome!

Adding PoC for getting local system on 32 bit Windows 8.1 update.

PoC_AppCompatCache_LocalSystem.zip 22.2 KB Download

Hello ,
 Two weeks ago I was able to locate some binary/executable in protected
 directory on windows 8.1 machine,i used a technique to span cmd shell
 instead of that binary, since the binary runs with NT Authority
 /Network service privilege and in service session I was unable to
 interact with it ,I changed my hack and used netcat in my plan and I
 was able to interact with the cmd shell in user session, now I get
 privilege escalation from user/guest does it count ?

This is really fantastic it will create security awareness and Let us know what we have to do in order to mitigate these RCE besides it will give a massive boost to windows security researchers, Awesome ....Thanks

<img src=x onerror=alert(1)>