Google discloses another Windows security issue after deadline exceeded
code.google.com
code.google.com
[1] https://code.google.com/p/google-security-research/issues/li...
Maybe there's a similar story with OS X, but there doesn't seem to be a public record of it.
Microsoft supports all versions of all their products for 10years+ after release, integrated with a combination of all other products they have shipped in that same time-frame.
Needless to say, Microsoft needs to do more QA on their bug-fixes before they can safely release it to all customers without the risk of causing new issues.
It's easy for Google to be big in the mouth when they don't bother to support their existing customers properly.
Speaking of being big in the mouth: Did you know that Google isn't back-porting security fixes to older versions of Android either (only 2 last minor releases)? I guess supporting more than 40% of your user base is too much work.</sarcasm>
Guess which side my sympathy is leaning to in this case.
IIRC Microsoft also releases pre-versions of their patches to select customers so sysadmins can test the patch doesn't cause issues on their deployments.
90-day, you mean. It's only zero-day if they had zero days to come up with a solution. That's what "zero-day" means.
Anyhow, the Wikipedia article disagrees with you, too. Got any sources for your definition?
Put another way, Google may have just notified the world of black-hat hackers of an issue they weren't otherwise aware of, an issue that demonstrably will not be patched for some time. If that is the case, then Google just recklessly endangered people's computers in the interest of raising awareness of Microsoft's poor turn around time on these issues. There is also the very real chance that this issue was already known by the black-hat community, in which case there isn't nearly as much lost by reporting here, but that's a gamble Google is making in order to make a point.
People wouldn't think that if MS didn't have a long history of doing exactly that.
http://blog.washingtonpost.com/securityfix/2007/01/critical_...
... and yet others think that both of those statements are true :)
Google seems to think Windows is a poorly written php app where you can just change a line and walk away. Windows testing has to be top notch and handle a huge about of 3rd party software, libraries, and drivers. The 90 day deadline really speaks to how web devs think and not how application engineers with massive install bases on a variety of equipment and running a variety of software think.
It does piss me off to be honest. MS isn't saying no to the updates its just saying, "We're doing them in 100 days, not 90 as out of band patches are really bad for the ecosystem and we need more time to certify our changes." Google is saying, "Fuck you. Buy an android tablet, microserfs."
Imagine if Google found the Kaminsky DNS bug. The internet would have melted on day 91 when google told everyone, "Sorry, too bad." I think this kind of "fuck you" disclosure should only be for attacks that have been demonstrated to be in the wild. Now they will be in various crimepaks, botnets, and trojan droppers within hours.
The point behind having a deadline before publicly disclosing is that if one person has discovered a security problem, then some other people probably have as well. It is fair enough to give vendors time before you make disclosure but if the vendor is moving too slowly -- for whatever reason -- you want to give the consumers a chance to implement their own security work around. Because if you don't they are vulnerable.
Giving Microsoft 90 days to fix an issue is fine. They can prioritize it anyway they want. If they think it is super urgent, they can almost certainly get a fix out. If they think it is not so urgent, then they don't have to make a fix -- but they know that the problem will be disclosed.
Nowhere in Google's documentation of this problem do I see a massive issue. Google gave MS 90 days. MS found a fix but there was another bug so they couldn't meet the window. Google released the information. Nowhere do I see MS requesting more time or any indication that anybody in the process thinks that anything went badly at all. It didn't meet the disclosure deadline. That's just the way it goes sometimes.
The still-supported Windows versions, by contrast, are 50+ million lines of code EACH installed on hundreds of millions of machines EACH.
Your telephone switch analogy is just not even in the same solar system as what Microsoft is dealing with.
I'm not saying 90 days is necessarily too little time, I'm just saying your reasoning is totally flawed.
"Imagine if Google found the Kaminsky DNS bug. The internet would have melted on day 91 when google told everyone, "Sorry, too bad."
Given this, if the Kaminsky bug was fixed in 31 days, that seems like a very bad example to use.
Say I patch a security flaw in a webapp I run. If I screw up the phone starts ringing, and then I undo the patch I made and think some more about it. Meanwhile no one has any clue about the flaw.
If I have to deploy a release to fixed endpoints, I have to think about what could possibly go wrong on every device out there running my software. Plus, if I didn't fix the problem completely, the nature of distributing the patch has now told the rev-eng community exactly where the problem was.
Google once pushed out a version of their browser that stopped the entire browser from working when their sync server went offline (for anyone using sync in their browser). Microsoft does not want even 1% of their users to suddenly be unable to use their computers.
As for the Kaminsky DNS bug, it was leaked more than a solid week ahead of the time he intended to release it. Sure, patches had already been released, but how about if other companies had said, "We need a full month to test this patch prior to rolling it into production."? They would have been putting themselves at risk. Mind you, this bug was simply an extension of an earlier flaw - too small a range of transaction IDs, and some DNS projects (`djbdns` comes to mind) had already mitigated it (ostensibly fixing the root cause as opposed to the symptom). Had the other vendors mitigated that flaw in a similar fashion (they had almost a decade since djb pointed it out), they would not have been vulnerable. However, there was no looming deadline, so few of them even noticed until an actual attack was possible (as opposed to fixing issues as they come up).
What happens if someone leaks the bug early? Or if a malicious adversary discovers the bug at the same time? The whole idea of these deadlines is to force security bug fixes to be released ASAP, taking precedence int time and importance over all else.
Deadlines can't be adjusted just so MS can screw around for longer doing nothing. If it's really taking them more than three months to fix a bug and release patches, perhaps they need to rethink their priorities and dedicate more resources to the task. And perhaps we need to seriously reconsider our dependence on their products.
When it actually affects them, they aren't hesitant to do whatever the hell it takes, with no regards as to the consequences for others, with zero warning at all, as was shown during the whole fiasco when they effectively took down NoIP's services. Meanwhile, when Google holds them to a perfectly reasonable deadline, for the extremely valid reason that bugs should be fixed on time, Google is evil?
Given their scale, they can afford to dedicate larger teams of people to the task of fixing security vulnerabilities. They can afford to hire independent security researchers and whatnot to help them find and fix such vulnerabilities.
If they need to break some third-party application in fixing a security vulnerability, that's okay. Because that application can also be fixed by its developer, and security needs come ahead of an app here or an app there. Besides, it isn't as if users of Microsoft's products are not used to the concept of having stuff break all the time anyways.
Have you noticed how quickly MS starts releasing patches and updates when a 0day comes out? That shows that they are clearly capable of doing whatever they need to do pretty damn quickly. They just don't do that with all security vulnerabilities, due to "business reasons", and as a result their customers suffer.
That is exactly the opposite of what Microsoft's customers think. If Microsoft began taking this attitude, there would be mass outrage. And maybe rightfully so: for countless applications in the Windows world, the developers are no longer around or ask for money to update the software. People are more likely to simply not update or roll back the update after they get it.
> Besides, it isn't as if users of Microsoft's products are not used to the concept of having stuff break all the time anyways.
They actually aren't. It certainly happens, but it's very rare that a Windows update (or even upgrade) breaks anything.
I think what Microsoft is doing is really hard. I don't have insight into their process, having never worked there. So yes, we can speculate that they could do things much faster. But can they? I find it rather tasteless to just assume so with no evidence and to then go on and call them names. I dunno, maybe they are falling flat on their faces internally, or maybe the team is performing heroics at the cost of personal lives, or maybe it is just business as usual.
But, it was also an honest question. Maybe there is evidence out there that Microsoft is just failing, and I haven't seen it or my reading comprehension failed me and I saw it but didn't register it.
But mostly, I am tired of the hurl accusations and drag people&companies through the mud meme that happens here, and this seemed to be more of the same (again, open to evidence, not claims, to the contrary).
[1] http://arstechnica.com/security/2015/01/google-wont-fix-bug-...
If manufacturers / carriers change that to check for updates on their own servers, rather than google's - which they can do since Android is open-source, and so they all do - then that's how the system update mechanism will work.
I don't follow what you're suggesting google could do about that, apart from moving more and more OS functions out of the core OS and into google play services. Which is exactly what they've been doing.
But I obviously do not approve what the OEMs are doing.
Aka, no longer part of Android. The millions of users without Google Play will have an even less functional OS than they used to, all in the name of greater control by Google.
At least they're starting to own more of the ecosystem. I wouldn't expect this to be as big of a problem on newer devices.
It's not an excuse.
I really don't see how Google is stopping them from updating their handsets.
Perhaps if Google provided the update and the pressure could be put on the manufacturers to roll out the update to their paying customers...?
> is really all Google's fault because they let the carriers get away with it and have never reigned them in even after years of incompetence on the carriers' part.
You are again blaming Google for the carriers policy of updating phones not even belonging to Google. Do you really think Google is involved with a carriers agreement to carry Samsung phones?
Last time I checked, Nexus phone's can also be updated without the assistance of the carrier.
Security updates aren't sexy and don't get applied unless they include shiny things along with them.
Releasing the update gives the customer power to press for pushing their manufacturers.
The whole model where carriers or manufacturers can send updates is ridiculous. Carriers update baseband. Manufacturers should defer to google for Core OS updates and Google Play. The fact that they're even involved is simply a recipe for disappointment.
It's bad for everyone because compromised machines simply reward and embolden the criminals which will eventually increase the harm to everyone who ins't a criminal.
Separately, complaining that the vulnerabilities are unpatched in Android is a rubbish argument. They are fixed in the latest release.
Also, they took a major step in Android L by removing the WebView from the Android Framework and distributing it via the Play Store, thereby, enabling them to push security updates to all newer devices without the devices themselves having to update to a newer version of Android to get security fixes.
I don't understand why Google hasn't build an update process for Android in the first place. Everyone knows the OEMs won't update if they don't have to.
So now they're having to lock the gate after the horse has bolted.
But if you want to compare it with Windows, the early versions of Windows didn't have an automated update process in place either.
Google supports Play Store and related services, but webview on 4.3 and older is not part of that.
When i buy a Laptop from HP, Dell, Lenovo or any other OEM, i still get Windows updates (even if i don't upgrade to the latest Windows version). I would really like to know why it is not possible for Google to implement such an update system? Blaming carriers is easier i guess.
Which parts are they coding in secret? (Honestly, I don't know, please help me understand)
[0]: https://android-review.googlesource.com/#/q/status:open
Why doesn't Samsung / LG / HTC manage Long Term support for Android versions, back port the patches and roll them out? Alternatively why don't they all pool together and manage an LTS version for customers.
It seems crazy that the company that has a relationship with the customer doesn't have to support the customer, and everyone instead blames google who wrote the code. The android vendors could back port, create alternative patches or simply make the device able to be updated to a more recent version.
AHAHAHAHAHAHAHAHAHAHAHA
I ended up halting development of my project while I waited for Adobe, to the point where I no longer wanted to work on it. I had stopped for too long and I didn't want to dig anything else up. Having no legal type knowledge myself or knowing anyone who could offer such advice, I was also too concerned to reveal anything for fear or any legal reprise.
So, the threat of security disclosure is warranted to pressure others into putting in the effort. However, the impact of the disclosure should be considered. If it will seriously affect others (who aren't responsible for the fix) and put them at risk, there should be the flexibility there to work with them on a deadline.
But I should probably pull my thumb out and check ;)
The statement that "if 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public" is little more than Google claiming the computer made them do it.
In any case, I think both Microsoft and Google would be high value targets for all sorts of infiltration by the NSA, whether it's sanctioned by the power structures of these companies or not.
Apple was on one of those slides. I suppose they're an NSA front organization as well?
I also said that I suspect that's the case, not the I assume it to be. Given that the NSA seems to do what it wants and the obvious motivation for infiltrating or starting companies like Google...I think the suspicion is warranted.
I doubt the fix for this and testing takes 90 days, or even 45 days.
If that's the case, then either Microsoft forgot about them, or they carefully orchestrated a PR scandal against Google (wouldn't be the first time - like the time they built an unauthorized Youtube app that Google specifically told them not to build, and then notified the whole media about it, putting words in the reporters' mouths).
What I find interesting is that there are at least a couple of cases in which bugs were marked as being subject to the 90-day disclosure deadline, but not made publicly visible until days or weeks after the deadline had passed.
https://code.google.com/p/google-security-research/issues/de...
https://code.google.com/p/google-security-research/issues/de...
Microsoft informed us that a fix was planned for the January patches but has to be pulled due to compatibility issues. Therefore the fix is now expected in the February patches.
So, they met the deadline and fixed the vulnerability, but due to compatibility issues had to pull it before being released through Windows Update.
But this is bugfixing, not creating new programs. It shouldn't take this long.
Often the size, scope and wealth of resources induces an increasingly slower response to such things.
Flat out 'more money to fix the problem' should never make things slower. Worst case you can ignore the money.
Even if it's too late to add people for project X, you should be able to use the money for something to improve productivity on project X+3.
If I'm wrong about something please explain.
I don't know how I can my my point more clear.
If a manager shoves in more workers and slows things down, they are failing at their job.
They are worse than useless.
Because someone useless would take the extra budget, not hire anyone, and not slow down the work. Perhaps they would waste it in vegas.
I am saying nothing that contradicts that book. Just two simple points:
1. More resources only slow down a project when they are misused. They are never inherently bad.
2. It's not even hard to speed up work on security bugs, because each bugfix is a different project and can have its own dedicated team.
Please actually point out something I said that was wrong, instead of making vague references.
Ignoring more money is pretty unlikely to be an option as a whole, and inefficiencies generally cascade down to some extent.
But even more important is that these outside slowdown effects are pretty minor. If this was software development then you might have no recourse and you'd be somewhat slower overall. But this is handling many many independent projects. You can hire more teams without having man-month problems, and then handle bugs efficiently.
>Ignoring more money is pretty unlikely to be an option as a whole, and inefficiencies generally cascade down to some extent.
Again, I blame management. A nice sturdy cardboard box as a manager is impervious to social effects from other departments, and it can soak up extra cash too.
I expect anyone being paid to manage to do a better job than a box. Not to go along with the flow uncritically.
The point is that Microsoft has the money to hire 100x more developers than the other guys, they should at least be well organized enough to deploy a part of that man power effectively.
Lets put it this way, there are 7 companies out there (at least) maintaining various different distributions of UNIX that can patch quickly, why can't Microsoft patch their 7 operating systems as quickly? From my view what you are saying is that because Microsoft is a monolithic company with 7 code bases it is somehow harder than 7 companies with 1 code base each? How does that track? Especially when Microsoft has a 100x more money than each of those other companies.
I'm not saying there is such a thing as a man-month. I'm saying there are ways to organize production, teams, and software so that people can provide more work than in poorly managed environments.
Maintaining code is not a trivially parallelizable function.
Yes, I know this, thank you.
But we are talking about billions of dollars vs. millions of dollars (for Linux / BSD). We are talking multiple orders of magnitude(!) more money. I realize there isn't a Silver Bullet, but the fact that what we have heard coming out of Microsoft about they're management practices year after year is ABYSMAL, it is not an excuse. Especially when people who are working for free, with no/little organizational support, can beat them at releasing security fixes.
> because of organizational overhead involved
So maybe they should fix it? How is their incompetence at running an organization a valid excuse? If it was a problem they cared about they would be researching how developers and teams of developers perform best, how best to organize code, etc. Instead they used stacked teams for years on end. I have no sympathy.
If it's as serious problem maybe they should stop making new operating system features and devote more resources to fixing, cleaning up, depreciating, etc. the ones they already have?
They are making business decisions, and their ineptitude at security is a result of them. There are no excuses of "they are the only one's doing X" for "they are bad at doing Y when they do X" when they are promising Y!
RedHat is POSIX compliant so why don't you just lump in every POSIX compliant device ever made? /s
The most recent one is somewhere in the User Profile Service, which is about as far away from the hardware as possible. Shellshock didn't need testing on every possible hardware combination it runs on either, did it?
If Microsoft says "100 days", saying "okay" instead of " no, 90" gives a timeline 100 days, not 101.