Abusing iPhone Co-Processors for Privilege Escalation

The talk starts with a phishing text that pushed a victim to install an enterprise-signed app. The app bundled several exploit frameworks. Five of them followed a familiar pattern of kernel memory corruption, but one did not. Its logging referred to a display co-processor very early in the flow, before the usual kernel exploitation steps would make sense.

The speaker explains the display co-processor, which took over display setup work that previously ran in a kernel driver. It runs a custom real-time operating system called RTKit, which has no authentication, no address space layout randomization, and predictable heap addresses. Requests the co-processor could make up to the kernel were permissive enough to map arbitrary memory into its IOMMU-style address table. Code running on the co-processor could therefore read and write kernel memory. The underlying bug was a C++ memory corruption in the display uniformity compensation code. It was not a novel bug class, but the weakened mitigations made exploitation far easier.

The main takeaway is that moving driver code onto co-processors can quietly regress security boundaries, even when the bugs themselves are ordinary. Practitioners should treat co-processor firmware as part of the attack surface, not just the main processor and kernel. The talk closes by listing many other co-processors on Apple silicon as areas for further research.