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

In a write-up this month, Maddie Stone, a top researcher on Google’s Project Zero team, shared details of a Safari vulnerability that folks realized in January this year was being exploited in the wild. This remote-code-execution flaw could be abused by a specially crafted website, for example, to run spyware on someone’s device when viewed in their browser.

The bug was tracked as CVE-2022-22620, with a CVSS severity score of 8.8 out of 10. It had been patched in 2013 and then reintroduced in 2016 during a code refresh. In February, it was fixed again by Apple in Safari and iOS/iPadOS updates.

“Almost halfway through 2022 and it seems like we’re seeing a similar trend” in such zombie flaws, Stone wrote. “Attackers don’t need novel bugs to effectively exploit users with zero-days, but instead can use vulnerabilities closely related to previously disclosed ones.”

Last year Stone wrote that a quarter of the zero-day vulnerabilities tracked in 2020 by Project Zero were closely related to flaws that had been publicly disclosed in the past. Typically, this happens as a result of incomplete patching by the developer or manufacturer – a software update doesn’t fully address the underlying flaw, leaving it still exploitable in some way.

That said, the situation with the Safari hole is a bit different. In this case, Apple completely patched the hole when the vulnerability was detected in 2013, but “its fix was just regressed in 2016 during refactoring. We don’t know how long an attacker was exploiting this vulnerability in-the-wild, but we do know that the vulnerability existed (again) for five years: December 2016 until January 2022,” she wrote.

That is to say, engineers tidied up and reordered some parts of their source code, and as a result, inadvertently reintroduced the exploitable bug. See Stone’s technical analysis for the full details.

The vulnerability in 2013 was a use-after-free() flaw in the History API code in the open-source WebKit engine of Safari. The API provides access to the history of the browser session and allows the user to modify the history.

The bug from 2013, and the closely related one spotted being exploited this year, both involve the History API and could be abused via a specially crafted piece of web content, giving cybercriminals the chance to gain arbitrary code execution capabilities on victims’ devices.

“It’s the same bug, but triggered through a different path,” Stone wrote. “That’s why the 2013 test case wasn’t crashing the version of WebKit that should have been vulnerable to CVE-2022-22620.”

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.

Source code commits in October and December 2016 were large, according to Stone. The first one changed 40 files with 900 additions and 1,225 deletions, while the second commit changed 95 files, with 1,336 additions and 1,325 deletions.

She listed refactoring among the key challenges facing developers – joining such others as legacy code, short turnaround expectations for reviewers and legacy code. And she argued that developers and security teams need time to review patches – particularly those done for security reasons. In addition, rewarding these efforts “will save the vendor resources in the long run,” Stone wrote.

“In this case, nine years after a vulnerability was initially triaged, patched, tested, and released, the whole process had to be duplicated again, but this time under the pressure of in-the-wild exploitation.”

Apple fixes the issue, but isn’t alone

In February, Apple released patches for the CVE-2022-22620 flaw.

Stone noted that the Apple Safari flaw wasn’t the only zombie vuln situation this year. In 2022, Project Zero also has seen in-the-wild zero-days that are variants of previously disclosed bugs in Chromium, Windows, Pixel devices, and iOS.

In 2020, the group found that six of 24 zero-day exploits were closely related to vulnerabilities that had earlier been disclosed in Windows, Firefox, Chrome and Safari.

“Some of these 0-day exploits only had to change a line or two of code to have a new working 0-day exploit,” Stone wrote last year, adding that in 2020, “[One] out of every 4 detected 0-day exploits could potentially have been avoided if a more thorough investigation and patching effort were explored. Across the industry, incomplete patches – patches that don’t correctly and comprehensively fix the root cause of a vulnerability – allow attackers to use 0-days against users with less effort.”

John Bambenek, principal researcher with cybersecurity vendor Netenrich, told The Register that zombie 0-days typically result from incomplete patching. Software firms need to reward and value security in their products and give developers and security professionals time to audit commits for robustness.

“Companies that value features above all else will, in particular, keep seeing this problem,” Bambenek said. “This problem is with software development generally. Humans are creatures of habit, so the patterns of thought and action that led to vulnerabilities also lead to their reintroduction.” ®

READ MORE HERE