back to article How refactoring code in Safari's WebKit resurrected 'zombie' security bug

A security flaw in Apple's Safari web browser that was patched nine years ago was exploited in the wild again some months ago – a perfect example of a "zombie" vulnerability. That's a bug that's been patched, but for whatever reason can be abused all over again on up-to-date systems and devices – or a bug closely related to a …

  1. Pascal Monett Silver badge

    "engineers tidied up [..] their source code, and [..] reintroduced the exploitable bug"

    So, they "tidied up", but did not test.

    Or, at the very least, did not test against proven vulns.

    Coding is not always easy, but this seems slightly sloppy.

    1. TeeCee Gold badge
      Facepalm

      Re: "engineers tidied up [..] their source code, and [..] reintroduced the exploitable bug"

      Why would they test something, when they've been brainwashed to believe that "it just works"?

    2. Brewster's Angle Grinder Silver badge

      From the article: "That's why the 2013 test case wasn't crashing the version of WebKit that should have been vulnerable to CVE-2022-22620."

      So they relied on the existing test, and it passed.

    3. Al fazed Bronze badge
      Mushroom

      Re: "engineers tidied up [..] their source code, and [..] reintroduced the exploitable bug"

      Well it took Apple many years to admit that MACstuff can actually get a virus. Now they are admitting that it takes them years to reintroduce a virus that MAC Users couldn't get.

      FFS !

      The future sure isn't rosey, unless that's from the glow of burning software houses...........

      ALF

  2. Jonathan Richards 1 Silver badge

    ...allows the user to modify the history

    ...to what purpose? Delete, purge and expunge the history, I can see might be useful, but what is the use case for an API call which is modifying it?

    1. Anonymous Coward
      Anonymous Coward

      Re: ...allows the user to modify the history

      Single page webapps often want to add new entries to the history to allow people to go back to a previous page without actually loading a new page.

      There's an argument for not allowing replacing an existing state, but that could be emulated by removing and adding a new state anyway so there's no harm in having it.

      1. Ididntbringacoat

        Re: ...allows the user to modify the history

        Kind of makes "forensics" a problem, yes?

        To allow modification of browser "history" is to invite all sorts of mischief when a malicious individual, group, or Government, decides to fabricate or enhance a potential case against someone.

        Paranoid? Really?

        1. JessicaRabbit

          Re: ...allows the user to modify the history

          Yes

          From the Mozilla docs - https://developer.mozilla.org/en-US/docs/Web/API/History/pushState

          "The new history entry's URL is given by this parameter. Note that the browser won't attempt to load this URL after a call to pushState(), but it might attempt to load the URL later, for instance after the user restarts the browser. The new URL does not need to be absolute; if it's relative, it's resolved relative to the current URL. The new URL must be of the same origin as the current URL; otherwise, pushState() will throw an exception. If this parameter isn't specified, it's set to the document's current URL."

          Note that the URL has to be the same origin, so you can't inject the URL for some illegal site into the history unless the user was already on that site (and then there's no framing required).

        2. Ignazio

          Re: ...allows the user to modify the history

          Paranoid. What do they need history changes for, if they can run anything on your machine?

    2. Ignazio

      Re: ...allows the user to modify the history

      Add + Delete = Modify

  3. yetanotheraoc Silver badge

    Not enough comments

    "She noted that developers in 2013 patched all the different paths that triggered the vulnerability, not only the one in proof-of-concept exploit code that was submitted at the time to prove a flaw existed. However, the refactoring done in December 2016 revived the vulnerability."

    /* Here be dragons. We put in all this cruft to protect against all the ways such-and-such CVE could be exploited. __Do not remove this code without complete testing.__ */

    Of course the critical code *will* still be removed in refactoring. Q: "What's all this? It's too complicated, I don't understand it." A: "Dunno. I don't understand it either, just get rid of it. Simpler is better." But at least then the old comments will show up in the diff, which hopefully the team lead is reviewing.

  4. dboyes

    Jeez

    Another case of ‘ain’t broken, so why are you messing with it?’. Programming will never be a true engineering discipline until we start pressing this into developers heads with a cluebat.

  5. dboyes

    Jeez

    Another case of ‘ain’t broken, so why are you messing with it?’. Programming will never be a true engineering discipline until we start pressing this into developers heads.

    1. Ignazio

      Re: Jeez

      Repeating a pointless comment twice doesn't add to signal.

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

Other stories you might like

Biting the hand that feeds IT © 1998–2022