To make the exploitation work in real-world scenarios, however, an attacker would still need to bypass Pointer Authentication Codes, or PAC, an exploit mitigation system that requires a cryptographic signature before code in memory can be executed. Without the signature or a bypass, it would be impossible for malicious code written by the WebKit exploit to actually run.
“The exploit builds arbitrary read/write primitives which could be used as part of a larger exploit chain,” Becker said, referring to proof-of-concept attack code his company has released. “It does not bypass PAC. We consider PAC bypasses to be separate security issues and thus should be disclosed separately.”
Theori said that company researchers independently discovered the vulnerability but that it had been fixed upstream before they could report it to Apple.
“We didn’t expect Safari to still be vulnerable weeks after the patch was public, but here we are… ” Becker wrote on Twitter.
This exploit was a fun challenge. We didn't expect Safari to still be vulnerable weeks after the patch was public, but here we are… https://t.co/jkEH7w498Q
— Tim Becker (@tjbecker) May 26, 2021
Eight Apple zero-days and counting
While the threat posed by this vulnerability isn’t immediate, it’s still potentially serious because it clears a significant hurdle required to wage the kinds of in-the-wild exploits that have bedeviled iOS and macOS users in recent months.
According to a spreadsheet maintained by Google’s Project Zero vulnerability research team, seven vulnerabilities have been actively exploited against Apple users since the beginning of the year. The figure rises to eight if you include a macOS zero-day that Apple patched on Monday. Six of the eight vulnerabilities resided in WebKit.
Apple representatives didn’t respond to an email seeking comment for this post.