September 4, 2019
Last week, Google published a series of blog posts detailing five iOS exploit chains being used in the wild that were found by Google’s Threat Analysis Group (TAG) team back in February. The reverse-engineering of how these exploits work by Google’s Project Zero team is very complicated and detailed, and for professional exploit developers or platform security engineers, there’s lots of information in these posts on how these specific exploits worked, along with how Google approached analyzing them.
Between the technical details, hex dumps, and code-snippets lies a great story about the strategies and thought processes of the exploit developer themselves. Highlighting this story, and showing not just what the exploit developer did, but the strategy behind it might be helpful to people getting started at exploit development, as well as those who need to defend against memory corruption vulnerabilities in adjoining fields like platform security.
For this reason, I want to do a write-up of one of the iOS exploits that Google found with a slightly different focus. As we walk through the various stages of what the exploit is doing, we can also look at some major vulnerability categories and exploitation strategies in general, and hopefully by doing so we can pull back the curtain a little on the magic of modern memory-corruption exploits, and see the huge amount of engineering that enables exploit developers to turn software defects into reliable exploits.
In this first part of the series, I will give an overview of the different stages in this exploit chain. In the next few parts, we will cover the various stages of the exploit, and how it builds up tools (called “exploit primitives”) that it can use to take full control of the operating system.