back to article What happens when a security hole is fixed in WebKit's source but not released as a patch by Apple? Let's find out

A vulnerability in the open-source WebKit rendering engine used by Apple's Safari browser remains unfixed three weeks after a patch repaired the flaw in the WebKit source code. This patch-gap – the time between visible bug fixes in open source projects and the availability of those changes in publicly released applications – …

  1. Claptrap314 Silver badge

    security@ ? -security?

    This is supposed to be the sort of thing that gets handled via email to security@ or posts to the -security lists. The patches are supposed to be kept out of the public repositories until RIGHT before the release.

    Someone did not read the memo.

    1. Anonymous Coward
      Anonymous Coward

      Re: security@ ? -security?

      Yes, :) the memo reads: More projects depend on Webkit then Safari, therefore the patch was published to the public Repos of those open source projects as THEY patched them, not Apple. Those projects shouldn't have to wait for weeks to protect their users by fixing a critical bug just because Apple or M$ or Google is dragging it's heels.

      Also, some research teams have fixed disclosure windows to keep the vendors from dragging their heels too much on issuing patches on critical bugs or exploits.

      1. Falmari Silver badge

        Re: security@ ? -security?

        So Apple are dragging their heels, no problem IPhone/IPad users can just install a Webkit browser that has the patch. Oh but they can't Apple won't let them.

  2. gerdesj Silver badge
    Paris Hilton

    Methinks the lady doth complain too much

    "This bug yet again demonstrates that patch-gapping is a significant danger with open source development,"

    Why pick out open source? All software has bugs and all major lumps of software have have had multi decades old bugs squished recently.

    I won't be following.

    1. Lorribot Silver badge

      Re: Methinks the lady doth complain too much

      With closed source the developer works for the company that own the affected software and they manage the whole stack, with open source that relies on a number of pockets of deveolpers that maintain various components such as libraries that make up the whole you get those seperate developer patching their bit but that patch not being distrubuted by the wider applications that use it.

      Its a bit like Car industry where a component supplier may fix an issue on one component but the car manufacturer still uses up its supply of all the old faulty ones for a couple months.

      May be they should do a recall of their software when it is deemed to be broken.....

      1. Robert Grant Silver badge

        Re: Methinks the lady doth complain too much

        > With closed source the developer works for the company that own the affected software and they manage the whole stack

        This doesn't have to be true, and conversely can be true for open source. The problem here is there is a shared technology that's been patched, and one of its consumers is not upgrading their software that uses it.

    2. IGotOut Silver badge

      Re: Methinks the lady doth complain too much

      It's because the fix has been published and therefore is easily reverse engineered. Until the companies using the product patch, then the issue is for all to see.

      With closed source, attackers are not likely to reverse engineer until the patch is released.

      Just to clarify, the article is about patched software and rollout, rather than bugs being found and not patched.

    3. Anonymous Coward
      Anonymous Coward

      Re: Methinks the lady doth complain too much

      I'm not sure that open source is being picked on here.

      Rather it sounds like Apple are spurning the fix that the open source project has very kindly gone to the effort of creating for the benefit of all, and that benefit will be realised so long as recipients are awake and paying attention.

      The "gap" occurs when recipients don't bother checking their inbox, or don't cast a glance over their dependencies now and then, or simply don't bother running their CI environment to see what's changed. Basically it's trivially easy to not get caught napping like this, yet a trillion dollar company seems to be asleep on the job.

      Someone buy them an alarm clock, please.

      1. Ace2

        Re: Methinks the lady doth complain too much

        Or, a company with millions of customers using millions of products in the field has a responsibility to do at least basic release testing. A vendor shipping product is NOT going to just ship an update with a fix that was merged upstream as “looks good to me.”

        If said fix crashes Safari or makes gmail render funny, no one is going to call the WebKit devs out on it. It would be “Apple shipped a bad update!”

        The exact same principle applies to Google, MS, vmWare, and every other commercial vendor.

      2. Anonymous Coward
        Anonymous Coward

        Re: Methinks the lady doth complain too much

        Yes, but no need to go straight for the torches and pitchforks at three weeks. In better times someone might be out on their honeymoon or vacation, these days, you gotta hope the dev isn't laid out from Covid.

        Sometimes there is a reason that isn't incompetence for these delays. And in some cases another team can/has provided cover, i.e. by releasing updated AV sigs to address the exploit.

        Though in this case Apple doen't have a full AV, and it seems to be launching the sploit without tripping their "secret" security code that blocks certain other exploits.

      3. DS999 Silver badge

        Re: Methinks the lady doth complain too much

        Apple isn't "spurning" anything. The patch was only submitted three weeks ago, and they were probably locking down iOS 14.6 for release candidate testing around that time. Should they just take a patch submitted to the WebKit open source and stick it in the iOS code base shortly before they release a new version? Testing, what's that?

        If this was a "instantly p0wn your phone" bug such haste might be more justified, but all it does is cause a crash. It isn't a "security hole" unless/until it can be shown to be able to bypass PAC and would STILL need to be paired with another exploit to escape Safari's sandbox. Bugs that crash browsers and can potentially be upgraded to security exploits are a dime a dozen these days, unfortunately.

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–2021