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.
“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. ®
Business News Governmental News Finance News
Need Your Help Today. Your $1 can change life.