Skip to content
An analysis of an in-the-wild iOS Safari WebContent to GPU Process exploit
projectzero.google | blog | #sandbox-escape | #ios | #exploit | #safari | #webkit | #in-the-wild | #gpu-process
Summary
A step-by-step analysis of an in-the-wild iOS exploit that escapes Safari's WebContent process into the GPU process, covering the underlying bug and exploitation strategy.
- Published
- Collected
Related coverage
blog ·
projectzero.google
Implant Teardown
Here's a conversation in Google Hangouts for iOS and the corresponding database file uploaded by the implant. With some basic SQL we can easily see the plain text of the messages, and even the URL of the images shared. The implant can upload private files used by all apps on the device; here's an example of the plaintext contents of emails sent via Gmail, which are uploaded to the attacker's server:
blog ·
projectzero.google
In-the-wild iOS Exploit Chain 1
TL;DR This exploit provides evidence that these exploit chains were likely written contemporaneously with their supported iOS versions; that is, the exploit techniques which were used suggest that this exploit was written around the time of iOS 10. This suggests that this group had a capability against a fully patched iPhone for at least two years.
blog ·
projectzero.google
In-the-wild iOS Exploit Chain 2
This was an exploit for a known bug class which I had been auditing for since late 2016. The same anti-pattern which lead to this vulnerability, we’ll see again in Exploit Chain #3, which follows this post.
blog ·
projectzero.google
In-the-wild iOS Exploit Chain 3
This chain targeted iOS 11-11.4.1, spanning almost 10 months. This is the first chain we observed which had a separate sandbox escape exploit.
blog ·
projectzero.google
In-the-wild iOS Exploit Chain 4
This exploit chain supported iOS 12-12.1, although the two vulnerabilities were unpatched when we discovered the chain in the wild. It was these two vulnerabilities which we reported to Apple with a 7-day deadline, leading to the release of iOS 12.1.4. The sandbox escape vulnerability again involves XPC, though this time it's a particular daemon incorrectly managing the lifetime of an XPC object. It's the kernel bug used here which is, unfortunately, easy to find and exploit (if you don’t believe me, feel free to seek a second opinion!). An IOKit device driver with an external method which in the very first statement performs an unbounded memmove with a length argument directly controlled by the attacker:
blog ·
projectzero.google
task_t considered harmful
A Project Zero deep dive into a design flaw around task_t in the XNU kernel, demonstrating sandbox escapes and privilege escalation and how each mitigation was defeated.