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

Three weeks and counting for Cupertino to update Safari's engine


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 – has become particularly problematic because attackers increasingly mind the gap, so to speak, and create exploits based on patched code that hasn't been distributed. ("Patch gap" has also been used to refer to time between vulnerability discovery or disclosure and patch distribution.)

"This bug yet again demonstrates that patch-gapping is a significant danger with open source development," said Tim Becker, a security researcher at Theori who was involved with finding the bug, in a blog post on Tuesday. "Ideally, the window of time between a public patch and a stable release is as small as possible."

As if to prove that point, the firm released a proof-of-concept exploit [ZIP]. To run the exploit, the pwn.html file must be served from a secure origin, such as an HTTPS server (or a HTTP server running on localhost). And at least one other PoC exploit has been released.

Apple released security updates for Safari, macOS, iOS, tvOS, and watchOS on Monday, including more than a few WebKit fixes. But not for this particular issue, which can crash Safari.

Hearing problems

The bug arises from WebKit's implementation of AudioWorklets, a part of the WebAudio API that provides a way to process audio data using single-threaded JavaScript via a separate audio processing thread, similar to a Web Worker.

"To construct a new AudioWorkletNode, the main thread posts a task to the AudioWorklet thread to call the registered constructor for a given processor name," explains Becker. "This constructor is expected to return an object of type AudioWorkletProcessor, but this was not explicitly checked."

Failure to check the object type provides an opportunity for an attacker to create a type confusion error capable of crashing Safari.

Developing a more serious exploit that enables arbitrary code execution would require additional work to create exploit primitives that bypass WebKit defenses like Pointer Authentication Codes (cryptographic signatures for pointers on Arm-compatible devices). Becker nonetheless suggests this malware defense can be overcome by attackers, pointing to recent Project Zero research.

"This exploit is only the first stage in compromising a user's device," said Becker in an email to The Register. "Attackers would still need to bypass PAC (an exploit mitigation present in newer iPhones and M1 Macs) in order to execute arbitrary code. Also, most user data is not accessible until an attacker escapes the Safari sandbox, which likely involves exploiting additional vulnerabilities."

Be open or not?

While the consensus in the security industry has been that responsible vulnerability disclosure and public PoC exploits encourage companies and open source projects to patch problems in a timely manner, recent research from Kenna Security argues otherwise.

Kenna contends that disclosure of exploits prior to patch availability helps attackers. The company's recent "Prioritization to Prediction" report, carried by the Cyentia Institute, indicates that in a third of the cases where exploit code was made public prior to patch availability, attackers had a head-start of nearly 100 days before a fix was deployed.

The report also found that while just 3.7 per cent of 150,000 vulnerabilities in the CVE database showed evidence of exploitation in the wild, about 85 per cent of exploit volume can be traced to vulnerabilities with public exploit code.

Given that industry disclosure practices aren't likely to change much in the near term, closing the patch-gap seems like a sensible strategy.

"We're not the first to point out the issue of patch-gapping, but this example proves it is still a feasible attack scenario," said Becker. "Advanced attackers can build an exploit from a public patch in a few days or less, so omitting security fixes for weeks gives ample time to exploit them in the wild."

The Register asked Apple for comment and you know how that typically goes. ®

Similar topics


Other stories you might like

Biting the hand that feeds IT © 1998–2021