back to article 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 …

  1. Anonymous Coward
    Anonymous Coward

    Who cares what Microsoft is doing?

    1. Anonymous Coward
      Anonymous Coward

      Yeah, code injection into Chrome, what's the big deal? It's only the most popular browser in the world.

    2. TVU

      "Who cares what Microsoft is doing?"

      However, in this instance, Microsoft's Jordan Rabet does make a valid point in that it might not be such a good idea to inadvertently highlight that a security liability is present before patching that same liability.

      1. Teknogrot

        There's at least a little irony in this position given how MS's own patching schedule reveals unpatched vulnerabilities in older but still supported versions of Windows.

    3. phuzz Silver badge
      Facepalm

      "Who cares what Microsoft is doing?"

      Well, you read the article and were moved to comment, so er, I guess you do AC.

      1. Doctor Syntax Silver badge

        "Well, you read the article and were moved to comment, so er, I guess you do AC."

        Moved to comment, yes? But read the article? Maybe. Read and understood? Maybe not.

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

    5. Anonymous Coward
      Anonymous Coward

      original AC here, just saying that MSFT suddenly pretending they care about timely patches because one of the 1000 engineers they put on the 'Google keeps finding Windows holes... lets find a hole in one of their products' project isn't interesting.

      1. JLV Silver badge
        Trollface

        well... if you're a Windows user, running Chrome and you get pwned through that browser, that still ends up on MS 's plate as insecure Windows, so makes sense to spend some time.

        Plus, that poor MS pentest team probably is so tired of being ignored by the rest of their company...

  2. Oh Homer
    Childcatcher

    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.

    1. 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?

    2. SuccessCase

      Re: They're right but it's a moot point

      @Oh Homer The article quite clearly describes a scenario where the exploit can be applied when the unsupecting user simply visits a web page. That’s a long comment to have written when your fundamental premise is, er, compromised.

    3. Anonymous Coward
      WTF?

      Re: They're right but it's a moot point

      "How many people upgrade apps on the same day the updates are released?"

      99.9999% of the general public, the ones with auto update turned on (Default).

      1. Anonymous Coward
        Anonymous Coward

        Re: They're right but it's a moot point

        Most of the NHS these days too (Assuming they aren't in England still running XP.)

  3. Herby

    This reminds of...

    Pot...Kettle...Black.

    Enough said.

  4. heyrick Silver badge

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

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

    2. Def Silver badge
      FAIL

      Re: Does Microsoft's approach not imply...

      That two repositories are necessary. The hidden one used to hold the code to actually build the product

      You do know how git works, right?

      1. sabroni Silver badge

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

      2. JLV Silver badge

        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.

        1. Def Silver badge

          Re: Does Microsoft's approach not imply...

          My point was that the distributed nature of Git automatically means everyone working on a project will have their own local copy of the repository.

          As for having an internal repository that people work towards before code is shared on Github or any other public repository, I would have thought that would be fairly standard practice. You certainly shouldn't be pushing changes to a public facing repository before any such changes have been reviewed by other team members, validated by a build server, passed any unit and regression testing, and signed off on by a QA team. Add in the security implications highlighted by this article, and you have even more reason to tightly control when code is made public.

          I realise the vast majority of open source projects don't bother with such mundane things as doing it properly, but if we were to ever open source our code there's no way in hell I would let any of our developers work directly on a public repository.

    3. Roland6 Silver badge

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

      1. Doctor Syntax Silver badge

        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.

      2. Ken Hagan Gold badge

        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.

    4. Phil Endecott Silver badge

      Re: Does Microsoft's approach not imply...

      > two repositories are necessary

      Isn't this exactly what git is supposed to be good at?

  5. Sanguma

    I wouldn't read too much into this: it's just a quiet little tiff between two sets of developers.

    1. sabroni Silver badge

      Yeah, that's what everyone was saying when Google were dissing MS's security practices!

  6. Will Godfrey Silver badge
    Meh

    Sometimes it's impossible

    I do some work on a relatively small project. If I post a bugfix to github/sourceforge I have no way of compelling the distros to update as well.

    1. Anonymous Coward
      Anonymous Coward

      Re: Sometimes it's impossible

      Err were not talking about a minor project. we're talking about Google

      By default Chrome and Play apps are set to auto update, unless permission changes are required.

      1. heyrick Silver badge

        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.

    2. sabroni Silver badge
      Thumb Up

      Re: I do some work on a relatively small project.

      Well that's comparable to Chrome.

  7. Charlie Clark Silver badge

    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.

    1. I ain't Spartacus Gold badge

      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.

  8. Tigra 07 Silver badge
    Trollface

    Tongue in cheek

    "The advertising giant did not respond to a request for comment"

    Google copying apple for a change?

  9. Nick Kew Silver badge

    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.

    1. Charlie Clark Silver badge

      Re: This is a real issue ...

      Relying on innocuous commit messages sounds optimistic but might your only option if you really need to provide public release candidates.

    2. Ken Hagan Gold badge

      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.

  10. Anonymous Bullard
    Thumb Up

    Yep, that's the thing about open source. Everyone knows about it, no favourites.

    What's the alternative? Sit on it for a few months, then slip it in when PR give the all clear, but to only your latest product leaving the widely used one still vulnerable.

    1. Charlie Clark Silver badge

      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.

  11. teknopaul Silver badge

    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.

    1. Ken Hagan Gold badge

      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.

  12. John Robson Silver badge
    Facepalm

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

    1. Ken Hagan Gold badge

      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.

  13. Networking Dude

    Finger Wagging

    Microsoft gets few chances to "wag their finger" at anyone regarding security patches and holes... Give them an ataboy for this one and let them wag a bit....

  14. Kiwi Silver badge
    Trollface

    It all makes sense now!

    Microsoft Offensive Security Research

    Did anyone think to tell MS that if they shut that dept down, then their (lack of) security wouldn't be so offensive to the rest of us?

    Thank you, thank you. I'm here all week, at least until they fire me.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019