Skip to content
Naked Security Naked Security

Zero-day in Windows 8.1 disclosed by Google

A new zero day vulnerability has been disclosed in Microsoft Windows 8.1. Who is behind releasing the attack code behind this flaw? Google.

Project Zero Full DisclosureSome situations in life call for a zero-tolerance policy. Drunk driving, sexual harassment and murder come to mind. But do security vulnerabilities pass the test?

Google seems to think so. Google’s Project Zero team publicly disclosed a zero-day vulnerability in Microsoft Windows 8.1 on December 29th after giving the software giant 90 days to patch the flaw.

Before I go any further, if you are a Windows 8.1 user, don’t panic (Thanks Doug)!

The flaw is a elevation of privilege flaw (EoP) in NtApphelpCacheControl, a function used for caching application compatibility information.

For example, it can be used to bypass User Account Control (UAC), allowing a malicious application to promote itself to administrator even if it started off with the privilege of a regular user.

Fortunately this means you have to already have been compromised for this vulnerability to be of use. There are also mitigations that can be employed to reduce the risk from this flaw.

People testing the vulnerability are saying that using UAC at its maximum setting prevents the attack, at least as demonstrated by Google, from working without a warning being presented.

The controversy isn’t so much about the severity of this vulnerability, but rather Google’s policy regarding disclosure of exploits.

The Project Zero team gives software developers 90 days to fix vulnerabilities before automatic full disclosure occurs. In this case Microsoft was notified on September 30th, leading to the disclosure on December 29th, 2014.

Is 90 days enough? Hard to say. Google says it picked 90 days as a sort of happy medium.

Short enough time to put pressure on vendors to fix flaws, but long enough that most issues should be able to be resolved within that timeframe.

In this case, 90 days clearly wasn’t enough for Microsoft to feel confident in shipping a well-tested update. Redmond has had a bit of a rough time with QA of security updates as of late.

DontBeEvil courtesy of Tangi Bertin's Flickr pageWithout getting into the full disclosure debate, there is one thing about this particular disclosure that doesn’t lend credibility to Google’s arguments that Project Zero is doing a public service and abiding by its famous “Don’t be evil” policy.

The public disclosure included proof-of-concept (PoC) code that allows anyone with interest the immediate ability to exploit the vulnerability.

In my book, that’s not compatible with behaviour that is allegedly in the public interest.

Hopefully, Microsoft will give us a New Year’s gift of a fix next Patch Tuesday, which will be on January 13th, 2015.


Creative Commons “Don’t be evil” image courtesy of Tangi Bertin’s Flickr photostream.

0 Comments

And what a stupid time of year to disclose it ! Most sys admins will be off for New Year … Thanks Google … ar** ho***

Reply

Just to be clear – disclosure of this vulnerability isnt what causes the problem, the vulnerability causes the problem.

Google sat on this for 90 days and there is no telling how many bad (worse?) people have known about it and have been exploiting systems – especially as they can take advantage of the fact that during the Christmas period, most networks are rich pickings.

Announcing the vulnerability gives admins the chance to implement alternative controls and monitoring, even if a patch isnt available.

Keeping it quiet because the mighty Microsoft hasnt been able to patch it doesn’t help anyone except the hackers.

Reply

“The flaw is a elevation of privilege flaw (EoP)”….So it’s a privilege escalation flaw. Why start throwing new acronyms and terminology out there?

Reply

EoP is pretty widely known and used, if only because the expression “elevation of privilege” abbreviates so nicely to EoP.

And my own linguistic preferences find “elevation” a clearer term in this context than “escalation”.

Certainly, we’ve used “EoP” on Naked Security as our standard terminology for…er, years, I’d say. For example:

https://nakedsecurity.sophos.com/2013/09/18/sophos-techknow-understanding-vulnerabilties-podcast/

And:

http://www.sophos.com/en-us/threat-center/threat-analyses/vulnerabilities.aspx

So it is hardly “new”…and no-one has taken exception to it before.

Reply

I’ve worked in the infosec slave for 15 years. Elevation is not a common term. Vendor specific for many years, maybe.

Reply

I think that when Microsoft adopts a term and uses it exclusively, it becomes common by any definition :-) Like saying “admin” instead of “root”. When Microsoft patches this, I betcha *they* call it an EoP, too.

As I said, we’ve used EoP for years on Naked Security, apparently without causing confusion, and without previously being criticised as neologists.

(Neologism and word-borrowing have fine traditions in English. See any Shakespeare play or visit any former British colony. Indeed, the willingness to adopt new words- and the absence of anything as crazy as an Academie Anglaise to try to regulate the language – is one reason why English is so rich and widely-used. You can overdo it with new words, but in this case, not least because it simply isn’t new, I think we’re fine.)

Without doubt, a lot of our readers are already entirely familiar with “EoP” from Microsoft bulletins, and those who aren’t can surely understand “elevation of privilege” perfectly well.

Except for *very* well established acronyms such as RAM and SMS, we invariably write out our terms in full the first time, as in “Elevation of Privilege (EoP).” I cannot for a moment imagine that you had any trouble understanding what we meant by “EoP”, anywhere in the article.

Reply

Disclose vaguely the vulnerability after 90 days, as a means of ratcheting up the pressure not to ignore, but giving all the details is irresponsible. Details should be held off for (say) a further 90 days.

I trust Google is up to fixing any security issues they have within 90 days, because if you are going to start this type of contest, be sure that it will come back to bite you.

I know where Google is coming from when it took me over a year and a report to the banking ombudsman to get a UK bank to actually acknowledge a serious problem in their online security which would have allowed me to lock out their entire 15-20M customer base in minutes. But to be fair to Microsoft, there has been a change of culture and they do take security somewhat more seriously these days.

Reply

Since Windows keeps you all in business, it is rather obvious why you state you don’t like the disclosure.

Reply

I know. It’s not as though Linux servers ever get pwned by cybercrooks for conducting their criminal campaigns, is it :-)

Maybe we don’t like the disclosure because it seems a needless step too far to pump out a PoC *and* a discussion of the vulnerability on the basis of some automated human-out-of-the-loop 90 day counter expiring?

Reply

While I somewhat agree when you downplay the severity of the vulnerability saying, “you have to already have been compromised for this vulnerability to be of use,” I do take exception when talking about enterprise networks or systems that are shared. In the case of an enterprise, all users are just normal users on enterprise systems. A vulnerability like this allows a user to gain administrative access on a system they normally shouldn’t have. This doesn’t mean they were compromised beforehand, but it downgrades the integrity of the enterprise’s systems pretty heavily.

As far as disclosure goes, there is no way to disclose issues that one blogger/reporter won’t harp about. Either keep it fully quiet, wait 2 years, wait 90 days with POC, wait 90 days without POC, etc. As an admin, however, I much prefer holes be closed, and if it takes a POC to get someone to close it (or give me enough information to mitigate through other means on my own), I’ll take it.

Reply

Many thanks for this excellent article Chester.

It is the only article that I have read on this particular vulnerability that includes mitigations that can be used while a patch is not yet available. These recommendations were very well received. Happy New Year.

Reply

So… 3 months isn’t enough time to fix this check? If anyone reading this is a manager remember that fact. 3 months is not enough time to fix one bug. One bug requires much more than 3 months to fix. Adjust your release schedules accordingly. Your gantt charts should suggest 4+ months for each bug to be fixed. I, personally, like this precedent.

…or perhaps the argument here is that this bug isn’t important enough to get scheduled to be fixed within 3 months. If that’s the case then it’s not important enough for us to complain about.

As for when the PoC was released, it’s an automated process. 90 days is 90 days.

Reply

What did the author of this story expect? Vulnerabilities get disclosed by others all the time and most of the time people don’t have 90 days to patch.

Sometimes we find exploits online that we didn’t even know about in our own software. Be thankful to Google for those 3 months of time, they’re worthy a treasure.

Windows had a chance to fix it while it made more sense in those 90 days.., but who doesn’t love working under the stress to fix it when the exploit becomes public?

It would seem more appropriate to “diss” MS more than G on this one, but I’m not really fond of either.

I’m also leaving a chance they ran out of time, but I kind of personally doubt it.

Reply

Can someone explain why Google had to release the PoC code to the public? I suppose it proves that the exploit exists, but this doesn’t help Microsoft fix the flaw, but only gives hackers a head start with code that already works.

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!