Who cares what Microsoft is doing?
You're doing open source wrong, Microsoft tsk-tsk-tsks at Google: Chrome security fixes made public too early
A few weeks ago, Google paid Microsoft $7,500 after Redmond's security gurus found, exploited and reported a vulnerability in the Chrome browser – a flaw that would allow malicious webpages to run malware on PCs. Now Microsoft isn't entirely happy with the way Google handled it, and having been schooled a few times on security …
COMMENTS
-
-
Thursday 19th October 2017 21:49 GMT analyzer
I do
Even though I do not use MS at home I do have to use it at work, I care a great deal about what MS do because it is in my entire work week.
I care a great deal about when they foul something up because it is my entire work week.
I care a great deal about when they get it right, because it is my entire work week.
We have started testing Linux based systems via HyperV because MS said that's cool and this affects my entire work week.
Companies use MS extensively, just because I think it is not fit for purpose on a personal basis does not mean that I can throw it out everywhere. So I really do care what MS do as it has a real effect on my working life.
I am sure that I am not the only person in this situation either, everybody has to pay the bills. As an aside, I have found that MS security ( server side ) is much better over the last 5 years.
As another aside, your post received not up or down vote, a reply was more in order.
-
Thursday 19th October 2017 02:59 GMT Oh Homer
They're right but it's a moot point
How many people upgrade apps on the same day the updates are released? Damned few, I'd bet. So the fact that an exploit is made public before the fix is published makes little practical difference, as it could be days, weeks or even months before users upgrade anyway, assuming they bother at all.
The PC (and tech. in general) is the new Idiot Box. The primary demographic doesn't work in tech., and doesn't even have much interest in tech., they're mere consumers pushing the "on" button and expecting it to "just work".
This is why so many apps, and browsers in particular, try to automatically update themselves in the background but, like any automatic update process, that's a double-edged sword. On the one hand it theoretically keeps the masses safe, but on the other hand a borked update can brick vast hoards of the Great Unwashed and leave them screaming about the evils of automatic updates, prompting them to turn it off.
I've personally been forced to do this in the past with Firefox, due to Mozilla's tendency to persistently break my extensions, which frankly I value more highly than the browser itself. Mozilla doesn't exactly go out of its way to promote ESR, which the average Joe has probably never even heard of.
Things are somewhat better under Linux. At least it has a consolidated update process for both the OS and apps (in fact it doesn't make any distinction between them), but under Windows the best you have is stuff like Chocolatey, which only supports a limited subset of apps, and Steam which only supports games purchased from Valve. The rest comprises apps that spam your startup process with their own individual automatic update services (prompting users to simply disable them), and the majority for which the only update method involves periodically checking the vendors' respective websites, something that most users are disinclined to do.
It's little wonder there are so many vulnerable systems out there.
-
Thursday 19th October 2017 04:57 GMT DougMac
Re: They're right but it's a moot point
> but on the other hand a borked update can brick vast hoards
Sort of like the latest Flash build breaks anything VMware or other enterprise interfaces in Flash,
and Chrome updates keep removing the "buggy" old flash that still can run the only interface we have into vSphere?
-
-
Thursday 19th October 2017 06:07 GMT heyrick
Does Microsoft's approach not imply...
... That two repositories are necessary. The hidden one used to hold the code to actually build the product, and the public one that contains the product source code which may or may not be in step with the product itself at any given moment?
If so, I think they're still doing it wrong. There's no easy answer, and as noted above the issue that an update available doesn't mean it is applied (especially when Google etc is fond of just saying "Bug fixes" as the reason for the update); however to suggest that something open source is released it of step with the actual source code seems a bit disingenuous...
-
Thursday 19th October 2017 06:16 GMT 9Rune5
Re: Does Microsoft's approach not imply...
"the issue that an update available doesn't mean it is applied "
...is still a lot better than having a documented issue out in the wild but no patch for users to apply.
Plus, it takes time to develop an exploit. Giving black hats an entire month to perfect an attack is just bonkers.
-
This post has been deleted by its author
-
Thursday 19th October 2017 07:59 GMT sabroni
Re: If so, I think they're still doing it wrong.
Only if you don't care about security. I notice you don't have an alternative option that allows the repo and product to stay in step without leaking vulnerabilities before the fixes are in use.
If I didn't know better I'd think some people's animosity to Redmond clouds their judgement.....
-
Friday 20th October 2017 15:03 GMT JLV
Re: Does Microsoft's approach not imply...
>You do know
I'll bite. I do know git, somewhat, as a git user, not admin.
So I'd read the OPs remark as valid, unless you can have a private work branch to a public github, which was asked on SO before: no. Remember too : that private "view" needs to be writeable by many, we're not talking about keeping local changes private on people's branches.
I get what the OP is saying, at least in terms of intent rather than git mechanics. From you, I see a one line snarky answer that may or may not be right but is certainly not informative. Enlighten us, if you can.
-
This post has been deleted by its author
-
-
-
Thursday 19th October 2017 11:03 GMT Roland6
Re: Does Microsoft's approach not imply...
That open source is insecure and closed source (ie. MS code) is more secure!
What MS are complaining about is a natural facet of the open source development and release process, namely the (public) master source code repository will be updated before a (public) build containing the fixes is made available. Simples!
The only solution to this problem is to make the master source code repository closed - available to the few and only update the public source code repository at some date after the release of a new build...
However, this prevents the timely cascading of source into other projects...
-
Thursday 19th October 2017 11:52 GMT Doctor Syntax
Re: Does Microsoft's approach not imply...
"What MS are complaining about is a natural facet of the open source development and release process, namely the (public) master source code repository will be updated before a (public) build containing the fixes is made available."
The developer will have built an executable before updating the main git repository. That could be released as the production version but on the whole most people might not be comfortable with that. They could, however, have a staging repository which is, in effect, their main one, build the release version from that, release it and then bring the public repository into line.
-
Friday 20th October 2017 16:57 GMT Ken Hagan
Re: Does Microsoft's approach not imply...
"However, this prevents the timely cascading of source into other projects..."
I fail to see why you've used the words "However" or "timely". Some of the other projects in this case are malware and preventing the cascading of exploits into malware before the fix cascades onto the machines of potential victims was the whole fucking point of waiting just three days.
-
-
-
-
-
Thursday 19th October 2017 16:40 GMT heyrick
Re: Sometimes it's impossible
"By default Chrome and Play apps are set to auto update"
Auto update is the first thing that I turn off, having been bitten several times by useful apps where an update takes away half of the useful features and makes them paid extras. If there's an app I like, I'll back it up so if I don't like the update, I can roll back.
-
-
-
Thursday 19th October 2017 08:34 GMT Charlie Clark
Meh
In this case Google got the process slightly wrong. You can compare this with how it deals with CVE issues which are kept private until the updated working code is released. I'd expect Google to be better on this next time but really there isn't much to see.
When it comes to security patches fixing the code as soon as possible is priority. You must assume that if Microsoft has been able to discover the flaw, then the NSA and others will have been as well. Then there's distribution: Google made it possible for Chrome to update itself very early on because it knows that many people don't always know how to deal with requests to update software. Even so, corporates and distros, and in this case, possibly Android is affected through WebView. But the inability of others to supply their customers with the patched software should never be an excuse for holding back a release. And even if they released the binaries without publicly visible changes to source code or issue tracker, then black hats would probably be able to detect the changes quickly.
-
Thursday 19th October 2017 11:35 GMT I ain't Spartacus
Re: Meh
But the inability of others to supply their customers with the patched software should never be an excuse for holding back a release.
Why not? Surely this is something you should risk assess. Rather than adopting rigid rules, you should look at the risk and particular circumstances and choose the policy that exposes your users to the smallest risk you can.
That means taking the real world into account. MS decided on one patch day a month in the hopes that more of their patches would be applied quicker - as there was only one set to test per month. On a schedule when people could plan for it. It has a risk, in leaving people unpatched for vulns that are known about, but the upside is that more patches will actually be applied. They also retain the ability to do emergency patches, if they deem that necessary. It's not a perfect solution, but that's because this is the real world, not the perfect one.
-
-
Thursday 19th October 2017 10:40 GMT Nick Kew
This is a real issue ...
In order to make a release, we need to push out release candidates. Those, at the very least, will contain whatever security fixes are required. And if a release candidate differs from the relevant public code repo, eyebrows will be raised, and blackhats very interested.
Our preferred solution typically involves committing the fixes quietly, with commit messages that don't mention any security implication of what's being done. The fix, but not the issue, is then public for as long as it takes to release. The security issues are announced when the release candidate successfully becomes a release.
-
Friday 20th October 2017 17:10 GMT Ken Hagan
Re: This is a real issue ...
"In order to make a release, we need to push out release candidates. "
That's your problem then. You've imposed a process on yourself that makes it impossible to deploy fixes before disclosing the bug. Your process has a race condition between "disclosure" and "fix".
Whilst you might get away with that for an app that isn't network-facing, in the same way that you might get away with real race conditions on a uniprocessor box, you can't get away with it in a web browser.
-
-
Thursday 19th October 2017 13:19 GMT Charlie Clark
I'm not even convinced that access to the source code or commit log really make that much difference anymore. Spooks, et al. now have advanced techniques for diffing binaries and running them in an environment where that can trace what effect the changes have and I suspect these are also the tools of choice when it comes to finding exploits in the first place: even highly automated static code analysis only gets you so far.
-
-
Thursday 19th October 2017 12:11 GMT teknopaul
who fixes the fixes
if the bug fix is not a complete fix sooner its known the better. Delaying any fix delays all responses including other mitigation that might be possible. like not using that browser in some particular high risk situation.
its foolish to presume that you're the only people that know of a bug. imho.
-
Friday 20th October 2017 17:14 GMT Ken Hagan
Re: who fixes the fixes
"its foolish to presume that you're the only people that know of a bug. imho."
It is also foolish to assume that you are the *last* person to know of a bug. Premature disclosure will always widen the risks to some extent. You might estimate the relative obscurity of a given bug by considering how much time elapsed between you adding it and some kind person telling you about it. The more obscure, the greater the risk in disclosing it before you have a fix.
-
-
Thursday 19th October 2017 12:31 GMT John Robson
So MS think...
...that they are the only people to have tried such futzing?
That's quaint.
If they can discover the bug then so can someone else... To claim that there is nothing people can do when the source code is updated is also wrong. Most people won't compile a new version, but the option is there.
When MS release a patch to a subset of their OS versions then it announces the bug in older versions pretty reliably (and this is despite the lack of source code) and those people will *never* be protected, because they can't recompile a fixed version from the source...
-
Friday 20th October 2017 17:22 GMT Ken Hagan
Re: So MS think...
"If they can discover the bug then so can someone else."
Like, Google ... who wrote the original software and might reasonably be expected to have gone to the trouble of trying the commonly available techniques.
And yet they didn't find it, which kinda suggests that even though futzing is not unknown outside of MS there is still a fair chance that this bug was not widely known. Consequently, splashing the fix all over the internet three days before you splashed the fix almost certainly increases the risk of this bug being widely used.
-