KeenLab iOS Jailbreak Internals: Userland Read-Only Memory can be Dangerous

The presentation discusses the exploitation of a vulnerability in iOS 10.3.3 to bypass security measures and achieve code execution.

• The vulnerability involves manipulating the M channel index and using heap spray technologies to allocate kernel memory
• Arbitrary memory read and write are possible, but writing is limited due to the size of the M in line array element
• The congruence theory is used to solve the problem of writing to an arbitrary offset in a page
• The exploit involves filling a slot P with an HX GL context object and modifying its lower four bytes to bypass the KSAR and achieve code execution
• The presentation provides a demo of the attack on iOS 10.3.3

The presenter demonstrates how they were able to bypass the sandbox and achieve code execution on an iOS 10.3.3 device. They explain the technical details of the exploit, including the use of heap spray technologies and the congruence theory to overcome limitations in writing to memory. The presenter also provides a demo of the attack, showcasing the steps involved in manipulating the M channel index and filling a slot P with an HX GL context object to achieve code execution.

Modern operating systems nowadays implement read-only memory mappings at their CPU architecture level, preventing common security attacks. By mapping memories as read-only, the memory owner process can usually trust the memory content, eleminating unnecessary security considerations such as boundary check, TOCTTOU(Time of check to time of use) issues etc., with the assumption of other processes not being able to mutate read-only shared mappings in their own virtual spaces.However, the assumption is not always correct. In the past few years, several logical issues were addressed by security community, most of which were caused by operating systems incorrectly allowing to remap the read-only memories as writble without marking them COW(copy-on-write). As a result, the memory content of the owner process is not trustable anymore, yet causing memory corruption problem or even leading to userland privilege escalation. With operating system evolves, such issues are rare though. On the other hand, with stronger and more abundant features provided by peripheral components attached to the mobile device, DMA(direct-memory-access) technology enables the ability for fast data transfer between the host and peripheral devices. DMA leverages IOMMU(Input/Output Memory Management Unit) for memory operations, thus memory protection mechanism provided by CPU MMU is not available during the DMA transfer. In the middle of 2017, Gal Beniamini of Goole Project Zero team utilized DMA to successfully achieve device-to-host attack on both Nexus 6p and iPhone 7. Nevertheless, this new attack model usually only applies for device-to-host attack senario, where a firmware bug is needed to fully control the device. Unfortunately, DMA related interfaces are not exposed to userland applications directly. With months of research, we found an exception case on iOS device: the Apple Graphics. At MOSEC conference in 2017, we demonstrated jailbreak for iOS 10.3.2 and iOS 11 beta 2, the latest version at that time, on iPhone 6s and iPhone 7. Details of the demonstration have never been published yet. In this talk, we will introduce the concepts essential to our bugs, which includes:- Indirect DMA features exposed to iOS userland- The implementation of IOMMU memory protection- Notification mechanism between GPU and Apple Graphics driverThe next part will cover two bug details: one in DMA handling with host virtual memory, and another out-of-bound write issue caused by potentially untrusted userland read-only memory.Lastly we talk about how we combine two flaws across different Apple Graphics components to achieve reliable kernel code execution from iOS application sandbox.