A researcher published exploit code for a vulnerability in WebKit, the web browser engine that powers Apple's Safari, along with other apps on macOS, iOS, and Linux.
The exploit takes advantage of an optimization error with WebKit's matching of regular expressions, which could end with the possibility to execute arbitrary shellcode.
Linus Henze, the developer of the exploit, says that the vulnerability has been patched in WebKit sources but the fix is yet to reach the Safari browser.
When describing the bug, Henze emphasizes that both the iOS and macOS versions of the browser are affected, although currently his code does not have support for Apple's mobile platform.
In the case of iOS, the developer says that a vulnerable variant of WebKit exists starting with revision 12.0 of the OS. As for the desktop, if the browser engine is on macOS 10.14 and up, it is exploitable.
"This is an exploit for the latest version of Safari (as of Dec. 6 2018). Fixed in the current WebKit release, therefore I decided to make this public," Henze emphasizes on GitHub, where he offers details about how to make it work.
He also points out that the steps for reaching a successful result are similar to those for the exploit created by Samuel Groß for CVE-2018-4233, a remote code execution bug in Safari demonstrated at this year's Pwn2Own.
Will Dormann, vulnerability analyst at the CERT/CC, tried Henze's exploit code and failed to reproduce the bug at the beginning. After a hint from the author, Dormann was able to make it work.
Ah, it looks like that could have been it? pic.twitter.com/XdpKEFK625— Will Dormann (@wdormann) December 6, 2018
An unskilled attacker would not find the bug practical because Safari's sandbox protection should prevent code to run outside the browser. To do this, Henze's proof of concept (PoC) needs to be part of an exploit chain that also leverages a sandbox escape vulnerability.
But the PoC makes it possible to execute shellcode inside Apple's browser and enable an attacker to do everything Safari is allowed to do. One plausible scenario is to bypass the same-origin policy (SOP) the browser uses to restrict resources from different origins to interact with each other.
If the attacker's code runs within the confinements of Safari and with its privileges, "this shellcode doesn't have to obey any policies to prevent it from accessing any sensitive information that the Safari process itself is allowed to access," Dormann told us.
The CERT vulnerability analyst added that he is not aware of this scenario being demonstrated in the wild, but theoretically, it could be possible to use Henze's PoC to bypass Safari's SOP protection and access information from any loaded page.
He showed the most trivial shellcode by setting a new RAX value (a general purpose register the machine uses to manipulate data) and Safari did not object.
"It's not a stretch to extrapolate from that that the shellcode could possibly instruct Safari to do anything that Safari itself has the ability to do."