GRENADE! Project Zero pops pin on ANOTHER WINDOWS 0-DAY Google has once again decided Microsoft's moving too slowly on the security front – by dropping yet another proof-of-concept attack against a Windows 7 and 8.1 bug that Redmond tried and failed to fix this week. The flaw is present in Windows on 32- and 64-bit architectures, and can accidentally disclose sensitive information …
Your most important customers are enterprise so you devise a regular patching scheme to keep them happy. Then Google find a bug, notify you, wait for an arbitrary 90 days, decide they can't wait two days longer when the patch comes out, and release an exploit for it.
Either they've all got Aspe's down at Google or the real reason for Project Zero is to kick the competition repeatedly in the balls under a guise of corporate responsibility. It's not even due to their open source background, there are disclosure embargos between major UNIX/Linux distributions until they've all got their patches out.
>>aw what's the matter? They disturbed your blissful ignorance?
Errr, no, they're releasing details of vulnerabilities before they're patched.
So the only people who benefit are people exploiting those vulnerabilities, get it? Google don't benefit, they look bad.
"Errr, no, they're releasing details of vulnerabilities before they're patched."
You know who else is releasing details of vulnerabilities before they are fixed?
The security companies who sell the details to governments (of all persuasions) around the world, the black hats who discuss them on closed forums, the criminal groups who are looking at the next ransomware exploit.
The thing is they release them between themselves and so you don't know about them until they are in the wild (or often many years later).
If a 'white hat' decides to do responsible disclosure (they don't have to they could just give no notice and tell everyone and post it to pastebin) and decides that 90 days is enough that any company who cares completely about their security can urgently find the resources to fix it then that seems like a good deal.
Waiting for a company to patch before you disclose could go on for years, by which time every criminal worth his salt may have found the hole way before the users, who were blissfully unaware of the issue.
>>> You know who else is releasing details of vulnerabilities before they are fixed?
I'm trying to work out what your point is. The SSL vulnerabilities, X Windows and all the other unix security holes were no doubt found and exploited for years before they became public.
But the fact is google have nothing to gain from this, it is just a cheap shot that has gone wrong.
Like others have pointed out, you don't know where MS were in the release cycle when this came to light, and they have the small matter of making sure their products are backwards compatible with everything written in the last 20 years.
A white hat may decide 90 days is enough, but google - the people who gave us the Android malware - could have acted with a bit more corporate responsibility.
Hate it or love it. Google is more accustomed to the Open source community culture where everyone is free to find bugs through the source code. Remember HeartBleed? 2 groups (one being from Google) found it independently and was reported before a reliable patch. Who could argue against it.
Microsoft on the other hand have enjoyed unfair benefits from obscurity.
Also, if Google fails to honor its commitment to fixes for its own OS, it is taking calculated risk knowing that other forks of its OS may find favor. Not so urgency with MS.
It's pretty clear this is some kind of strategy decided at top exec level, not something a single group within Google can do without asking permission.
Why? It looks Google has some troubles (the step back in the Glass program, after all the hype including the agreement with Luxottica, can be a hint) and decided to become a bully to put competitors in bad light. What are they afraid of? Maybe the new free license model for some Windows version could start to make a dent into low-price Android devices market share? Flat ChromeOS sales?
The worst thing is they are increasing risks for users, and they don't care. And it could start an unecessary "war". Very childish behaviour, from Google.
The worst thing is they are increasing risks for users
The thing that increases the risks for users is not fixing security vulnerabilities in a timely manner. Microsoft have caused us to be sitting ducks for too long, and it's about time someone large enough stood up to them (regardless of who - I'm no Google fan either).
Funny you should say that, I am having many problems in windows 8.1 trying to remove some files that are virus related but I can't because I am not an admin, yet I am an admin in groups and profile, 8.1 simply doesn't believe itself.
So when you don't want to be, you can be.
When you really frikkin' need to be, you can't. Gotta love MS.
Still if Google actually were keen on security they would fix any issues thrown there way to maintain the moral high ground. So it is a bit petty and childish name calling all this. Even though carriers and manufacturers not just giving default android with OTA when Google does are kind of to blame as well.
Back in the stone age, Microsoft ran adverts that 'proved' Windows was more secure than Linux. The proof was to go through all the software in all the Linux distributions, and add up all the security patches in a year. The number was huge in part because it included types of software that Microsoft did not sell, multiple forks of the same software, multiple pieces of software that did the same things and all multiplied by the number of distributions. The 'equivalent' number for Windows was 52.
Decide for yourself:
A) I like patches to be delayed so they arrive on a known day of the week.
B) I like patches as soon as they are ready.
C. I like patches that don't **** up more than they fix. B is a nice to have. A seems a bit daft. One does not NEED to install a patch as soon as it is available but it would be better to have the OPTION to do so.
I suspect A actually results in more bad patches; in order to squeeze in a patch to a particular time table there will invariably be new things landing at the last minute with significantly less time to test.
Feature and normal minor bug fix patches should be bundled together and pushed out occasionally. That way you don't end up with routine low priority patches coming in every day. Bundling them together lets the user deal with them all at once.
Security patches however should be pushed out ASAP. Delaying them to fit an arbitrary schedule simply provides a bigger time window for the holes to be exploited in.
New exploits are often found by poking around in areas where known old exploits had previously been found, often using automated tools. That means that exploit discovery isn't random and that a vulnerability that you know about is more likely to be exploited in the near future than one in an unrelated area that you don't know about. The longer you delay releasing a patch, the greater the risk to the end users.
No need to slander MS, they're bad enough without it.
Patch Tuesday originated back when MS was releasing patches ad hoc and Windows Admins complained they were spending all their time installing and fixing the patches and not on the other work they also needed to do. So MS instituted Patch Tuesday with the option to go out of band if they deemed a patch sufficiently critical.
It may be a bad solution, but in this case it was one customers were actually requesting.
Now, on the whole patch speed and bugs issue, yeah MS has a horrendous track record. And I think on the whole the Google program will hold their feet to the fire. I think the public release 2 days before patch Tuesday was bad form and I would have given them the two days, but I can't really fault them for sticking to their policy. I might update the policy to indicate that if a software provider has a regular patch schedule, I'll release the exploit on (90 days + time to regular scheduled patch + 1 day) so long as the regular patch schedule is less than 90 days.
the option to go out of band if they deemed a patch sufficiently critical.
And they haven't deemed this critical enough, even with the pending "release" deadline. That's Microsoft's call.
These bugs are quite trivial, when all said and done - in order to exploit, they all require some sort of trust to already be established; completely blown out of proportion by fanboys that have no idea for the sake of two days.
I don't blame Microsoft for not releasing two days early (it was low risk + low impact), and I don't blame the Project Zero team for sticking to their guns (give one person an exception, and everyone else will want one).
If MS or any other vendor ignore reports of bugs, then they should be disclosed in order to shame them in to sorting it out.
However, in both the recent cases, MS have said they have a fix and have asked Google to withhold disclosure for a short amount of time until they can get it out. Where a software vendor is clearly taking the bugs reported by Google seriously and is doing something about it, but just needs a little extra time to issue a fix, Google should be more flexible and work with the vendors in that situation.
In my work, we have a few software packages that run on WES7/8, XP, 7 and 8. To fix bugs and fully test them can take a week or more depending on their severity and how many platforms the issue is present on, and I dare say MS have a lot more platforms to test against. Testing takes time, and sticking to the 90 day limit rigidly either exposes users to flaws unnecessarily or will encourage vendors to rush fixes out without proper testing, which may cause more damage than it prevents.
Unless you know the code, you can't really know how easy is to patch that code. It could be changing one line of code only, it can require extensive changes even for what may look a "simple patch" from outside. You have to assess and consider the ramification of any change. You need the people in charge of that codebase to be available to work on it.
But it looks most people here, if ever they wrote real production software, adhere to the "Hey, it compiles, ship it!" way of delivering it....
The other day I read on HN this wall of text from someone who actually worked on a vulnerability for Microsoft: https://news.ycombinator.com/item?id=8874587
TD;DR - He struggles to justify (to developers) 90 days isn't enough.
Yes, but
Given the MS track record on patches, I'm not going to believe them just because they send out the PR flack. We've seen them use that dodge in the past. I probably would be willing to fiddle a bit if the 90 day count is close to a release date, but only because of the issues with calendars, not because I trust what MS says.
For us that have to use Microsoft community, Google shouldn't be releasing detailed HowTos with example code to the hacking community!
Announce that there is a bug? Okay, but preferably after a patch is available. If the supplier says, we can't meet 90 days, we need 92, then delay by a couple of days FFS! If they need an extra month, where is the problem? They are showing willing.
If they tell you to go screw, then release general information.
Do not release code to exploit the bug, do not help the hacking community!
If you are going to release full details, including exploit code, then you better release a damned mitigation BEFORE you release the code and full details!
we can't meet 90 days, we need 92
And then next time it will be 94 days, and so on. With the last issue Microsoft said it wouldn't be available until February - but when Google said "No, still 90 days" Microsoft suddenly managed to push it forward a month. Looking at it objectively (ignore your fanatical bias), can you see the effect of having a rigid deadline provides? They already managed to reduce the time from 4 months to 3 months.
Do not release code to exploit the bug, do not help the hacking community!
The "hacking" community don't need the proof of concept code - It just takes is a vague description of the bug, and a working exploit will be available before the day is over, and that's assuming it's not already known. The PoC is mainly to prove to the vendor (and their users) that the vulnerability isn't theoretical, it's real - working, right in front of them.
If you are going to release full details, including exploit code, then you better release a damned mitigation BEFORE you release the code and full details!
That's up to the vendor to provide, but they stalled on having it available by the deadline even though they knew the consequences.
I doubt anyone here is considering that any vulnerability discovered by an "ethical" researcher, might not be the first time the bug was discovered - just because it isn't "in the wild" doesn't mean it wasn't being quietly exploited, targeted and undetected. Security research isn't (only) performed by geeks in their bedroom, but by governments and criminal organisations who are highly motivated and have a lot more to gain than the ethical researcher.
They pushed out a patch for the last issue, perhaps the testing wasn't as thorough as it could have been to do that. Imagine what shit could hit the fan if MS pushed out a patch for this issue which screwed up checking the impersonation level of the token which the caller passed for cached executables (for this is what it does). Would you like it if a load of Windows machines ground to a halt because some key executable couldn't run?
If this were a 0 day discovered in the wild then MS might have pushed out the patch ASAP. But it was Google who discovered it, Google who reported it to MS, Google who should show a bit of responsibility, and Google who made it 0 day by releasing it two days before it was patched in a regular patch cycle. I think most security researchers would have managed to wait till the next release in the patch cycle if they found this bug, if Google are going to behave like blackhats then we might as well pack up and go home.
It's not 0-day. They had 90 days. What part of that can't you people grasp?
Not only that, the actual patch was ready before day 90 - but the release was delayed for two days beyond that, because the "enterprise" are unable to employ engineers who can handle more than one patch per month.
Well I'm sorry but if you're employed to look after equipment and you only able to maintain it just once a month at a pre-defined time then, quite frankly, you need to find another fucking job and let Microsoft do the right thing and give security patches out ASAP to those of us who are more able.
If you were an enterprise engineer, you wouldn't be happy to work most of the nights and weekends to run after every patch released for every software you use...
Patching complex systems that run critical software is very different than patching your bedroom PC you use to download porn...
While I broadly agree with your argument, I think this request was actually reasonable.
The clear intent of 90 days is to give 3 months to fix a patch. MS has a monthly patch schedule. Therefore if the deadline is just shy of a release date, I'd give them some flexibility. But not more than 3 days, which is the most you can accumulate for calendar irregularities. As to the whole at Christmas everything shuts down argument, not buying it. That certainly doesn't apply to my work place.
[pedant] Sadly, scheduling the second Tuesday of each month as "Patch Tuesday" does not correspond to a 90 day cycle. I have to wonder at the selection of 90 days as the interval but that's pretty much a standard with humans choosing intervals even if there isn't an exact correspondence with reality. [/pedant]
Whilst true, that comparison is not fair to Google.
As pointed out in the article (and in several other places) Google do not have control over the deployment of new fixes to the core OS in the Android space. They may well publish a fix, and also issue new releases of Android that would technically work on a multitude of devices, but the devices are tweaked and locked by the manufacturer of the device, and sometimes by the service provider who ship the device, both of whom have no interest in allowing users to extend their use by installing patches.
I would love to see some legislation which mandated manufacturers and particularly service providers to free up boot loaders and other locking mechanisms a fixed time after their final update/patch is made available so they could take a generic release of Android. Maybe something from the reduction of waste legislation.
But it is difficult. Unfortunately, many Android devices have binary blobs, which are pieces of closed source code included in their Android release to handle communication, multimedia or other components in the device. There is nothing Google can do about this, short of changing the licensing model of Android. So even if the devices could take later versions of Android, unless the regression tested versions of the blobs are released (or open-sourced!), some devices will not take new releases of generic Android and remain fully functional.
I guess if you prattle on long enough you can find excuses for Google. The truth is their behaviour was shameful. I hope someone does the same to Google because then you will hear them scream about it and their legions of Google fans will go on about how it is unfair to do it. Me, I really don't care about Android too much.
"Google said it was difficult to fix the WebView hole due to its integration into the core system"
Sort of - It was difficult to update WebView, because it was part of the core - which is the responsibility of the OEMs.
(This kind of stuff is changing now because the phone carriers and manufacturers are so inept at pushing updates - about fucking time!)
What MS said about IE being integrated was complete bullshit, because they wanted to abuse their monopoly (and this has since been proven in court).
Microsoft would have a simple time of it - the Android source code is out there, so is Linux for you to pick through at your leisure.
Microsoft are closed source so when an issue is discovered only they can see what caused it and how much time to spend on it to get it fixed within three months. I can say for sure that if I had 3 months to fix a bug that was serious enough to break security and would be publicly disclosed after a countdown had expired I wouldn't be waiting for a random Tuesday to deliver it!
My thoughts exactly - Microsoft, please return the favor for Android and Chrome users.
I have better things to do than dig through Google's bloated source, but for MS it's marketing... their favorite kind: FUD. Justifiable FUD, even. If a program segfaults, you can bet it's insecure.
BTW, Google isn't all open source. You could say that's just marketing...
Dear El Reg
Please stop putting huge irrelevant annoying pictures on every article. Not all of your readers are on SuperFast 6G ultraband and they waste not just paid bandwidth but precious time in loading.
If you do insist on continuing with pictures, if you're going to put a a picture of a man giving the bird (even a cartoon) then please put NSFW in the article title.
And please feel free to copy this comment to the forum about recent changes to the format of El Reg - I couldn't find a link to it.
Thanks
Velv
"And please feel free to copy this comment to the forum about recent changes to the format of El Reg - I couldn't find a link to it."
It's the one with a 1000+ comments, strangely most people are not in favour.
http://forums.theregister.co.uk/forum/1/2014/12/11/Drewc_El_Reg_Redesign_leave_your_comment_here/
I'm sure Google are leaving themselves open to claims. It could be argued that they are assisting/enabling criminal activity. Class action anyone?
If flaws are found and they aren't fixed in a timely manner and/or those responsible for trying to fix them say they aren't going to fix them then yes publicise that. But do they need to go into so much technical detail and help criminal hacking?
I'm sure Google are leaving themselves open to claims. It could be argued that they are assisting/enabling criminal activity. Class action anyone?
You are insane. Any defence of Microsoft is based upon the unverifiable assumption that no one else had discovered the bug and developed a possible exploit. The resources open to the various secret services, but also to organised crime (the difference between the two groups can often be difficult to tell), dwarf what Google can through at the situation. And you can still cling to the belief that no one else may have discovered (and already be exploiting) this or other bugs?
As for making disclosure of defective software open to legal challenge? That will drive disclosure underground and should make all of us worried about the safety of our systems.
Google should be judged on its own response to similar issues. The WebView one does not count, technically because it's already been fixed, but most obviously because Google cannot deploy a fix. Manufacturers of kit with Android who do not provide security updates are the ones you should be targeting with any legal action.
Google said it was difficult to fix the WebView hole due to its integration into the core system.
No its not, just lean on the phone manufacturers / mobile companies and demand that they offer firmware upgrades or replace the phones. They took the money now support the user !
Why don't MS just have two patch feeds - one 'immediate release' feed and one 'patch tuesday' feed, and admins can subscribe to whichever one suits them best?
(I have some vague ideas of why there might be problems but not really sure. Please enlighten if there are issues with doing things this way)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
