What's in a Jailbreak? Hacking the iPhone: 2014 - 2019

amazing keynote this morning we have such a privilege to have this speaker I'm talking to you guys and the keynote is about what's in a jailbreak hacking the iPhone 2014 to 2019 onwards with marked out and a lot of you probably have heard of mark there but mark dad is an expert in application security specializing primarily in low-level operating system vulnerability research for both desktops and popular mobile devices he is currently the director of azimuth security now l3 trenchant a security company founder that specializes in code review and cutting-edge security research prior to citing azimuth his professional experience includes several years as a senior researcher at a fortune 500 company where he uncovered a variety of

major vulnerabilities in ubiquitous Internet software he's also worked as a principal security architect for McAfee where he was responsible for internal code audits secure programming classes and undertaking new security initiatives markers also co-authored a book a very very well-known book actually on the subject of application security named the art of software security assessment and has spoken at several industry-recognized conferences this bio really doesn't give him justice but can we please welcome mark the out to the stage

I think Sylvio so as Silvie I mentioned my name's marked out I'm going to be talking about what's in a jailbreak and essentially in this talk I want to basically go through the components that make up a typical jailbreak I'm going to be focusing on browser-based remote jailbreaks in the in the intro in the abstract I wanted to also mention that I was also going to go through usb-based ones but I quickly realized that that was going to take two and a half hours if I did that so I'm basically going to have to do two talks I suppose sílvio introduced me already so I don't need to go through this I would like to

point out that I've rescued several people from Apple though so that they've been a great help for putting this speech together so the reason I wanted to talk about iPhone jailbreaking is you hear a lot about it there's a lot of you know jailbreaks are released to great fanfare and also you sees the Rodian bounties and they're offering millions of dollars for for a complete iPhone jailbreak and for people that are not as familiar with with how jailbreaks work this seems like a crazy amount of money and fanfare but I basically want to show that it's it's actually pretty difficult so when we talk about iOS jailbreaking we're talking about the removing of software and strict restrictions imposed

by iOS which is Apple's operating system on devices running it through the use of software exploits and it's always been quite difficult but over the past five years and in the past two years in particular it's their bracelet bar quite significantly so in order to in order to talk about the anatomy of a jailbreak I sort of have to cover a little bit about the iPhone security model in general this is a topic that's sort of been covered a lot in the past however if you're a bit unfamiliar with it then the anatomy of a jailbreak wouldn't make much sense after that I'm going to go through a practical example which was the Pegasus jailbreak found in the wild

and then the post Pegasus world which so Pegasus was found in iOS 9 and this is I don't know why this is going without me going from iOS to iOS 12 so we start off with the Apple security model basically I've identified the elements that I consider quarter apples security model which is code integrity isolation exploit mitigations and something that I've called environment preservation encryption and strong encryption and data privacy is also a large part of I phone security but it's not really relevant to remote jail breaks it's more relevant to the USB style attacks and so I'm not really going to cover that here but anyone that's interested should go and read Ivan Kerr sticks talk which is

really excellent and covers it in great depth so with code integrity basically the idea with the iPhone ecosystem is that only Apple approved code is ever run on the system and this is quite a quite an impressive feat really and to achieve it they do a multi-pronged approach they have a trusted boot chain because if you're if you can't basically Trust your kernel or anything below it then you can't really trust the rest of the operating system at all and then following that they have user mode integrity essentially every single application that's run on an iPhone is signed by Apple and and then there's runtime integrity which is some additional security security features about the iPhone iOS runtime so with

boot integrity this is a simplified version of what an iPhone what the iPhone boot chain looks like I say simplified because it doesn't account for some of the things that again are more relevant to USB such as the saffron SEP and booting to Deere for your recovery mode but for basically booting to iOS you have wrong which has the establishes a root of trust with apples certificate because it's immutable they can embed their certificate and they can know it's trusted and then each additional stage up until you load the iOS kernel each additional stage cryptographically verifies the stage before it so that each stage can be can be validated that it hasn't been modified by anyone

user mode integrity like I said all user mode binaries are signed by Apple and by that essentially we mean all binaries contain a code signature that is cryptographically verified by the kernel or by a user mode service called MF ID which is trusted by Apple the code signature essentially contains information about the executable and most importantly a list of hashes about every page from the binary that's that gets mapped in and and then also entitlements granted to that binary which is something that we'll be discussing later so we have two methods for verifying binaries now the mechanics of how this works is not really important for this talk so I'm not really going to talk about it here but

essentially I wanted to put it on the slide deck for people that are interested in following that up so after that we have runtime integrity so basically if you could just map readwrite executable memory and execute whatever code you like then essentially having all the verification of the binaries and all that kind of thing is not very valuable so the runtime integrity basically disallows read write execute mappings execute executable code must belong to something with a valid code directory and then they've done some additional runtime security checks to prevent you from doing some other things at runtime these were things that were introduced over time because of the result of jail breaks so the next thing we're talking about is

isolation goals so essentially we want to prevent prevent compromised applications from being able to adversely affect the system so we want to sandbox them reduce the attack surface and enforce granular control over this over system resources so there's basically three factors that govern how an application is isolated it depends on the user running the system it depends on the entitlements granted to that application and it depends on the sandbox in restrictions imposed on it user is either route or mobile iPhone is essentially a to use a UNIX system most things run as mobile a couple of things run as route like system services entitlements special privileges that are granted to the application that'll that allow them to do something

that isn't allowed by the system or isn't allowed by that particular user entitlements are immutable and they can't be modified at runtime so the entitlements that are present in the code signature is what that application has and that's it so this is some examples of entitlements and really the there's tons of them but the only one that really matters for us in the context of web shell breaks this dynamic code signing which is a special permission that allows you to map read write executable memory once in the lifetime of a process and specifically the web browser does it for dynamic generation of JIT code lastly we have isolation so obviously iOS has quite a robust sandbox nearly any resource that

you want to access from the system is the request is proxied through the sandbox the sandbox kernel extension and it decides what you're allowed to access and that's based on a sandbox policy most App Store apps have a standardized app profile that only allowed them to access you know basically their container and system applications typically have their own sandbox which is based on a built-in profile that's bundled with in iOS there's actually a really excellent talk about about Sam boxing and the mechanics of it by Jonathan Levin which I've put the link up to there so essentially entitlements as Sam boxing is something that restricts access that the user would normally have and entitlements is something that

permit access the the user or or no one would normally have such as being able to map executable memory okay so obviously um like any contemporary operating system iPhone has a gamut of exploit mitigations that have become increasingly complicated over there over the over the last few years and the idea is to prevent them from being reliably exploitable prevent vulnerabilities from being reliably exploitable I've sort of talked about before early stage mitigations which ones that attempt to detect or obscure critical data structures such as heap or saved return address and/or prevent basically you getting code execution and then there's late stage mitigations where you've completely corrupted data control structures but they want to try and

prevent you from actually executing code so you have things like control flow integrity PAC in this case deep hardening code signing that kind of thing there's a lot of them that are present in iOS but these are the ones that are relevant for this talk firstly ksl are and ASLR is something you probably would have already heard of address space randomization in iOS they basically slide binaries by randomized amount the second thing is kernel he pardoning there's been multiple iterations of this over the span of iOS is lifetime and they've done Stephan Esther has done multiple talks about this but basically there's zone isolation which is essentially they create isolated zones for like data structures so that you can't replace one

data structure with another one by grooming memory there's zone data structure hardening essentially encrypting encoding things in memory there's block verification which when you free a block it makes sure that you're freeing it to the correct zone there's poisoning where where they you know will write junk over a over a block so that for use after free type vulnerabilities you can't exploit them and there's free list randomization Safari has also done its own he pardoning again it's got an isolation strategy and one that's called the Giga cage most recently again the idea of this is that objects of certain types are segmented off from objects of other certain types in the heap and so when

you try and do a use after free or something you can't replace a freed object with you know arbitrary data contents you're restricted by you're restricted by only being able to replace it with the other objects at the same time bulletproof jet is another important thing this has had two main iterations in the a-10 iPhones they had an execute only bit which means you could map pages that were executable but not readable and the way what they did with the jet mapping in Safari is to map it at two locations in memory one that was executable only but not readable and one that was writable but in a hidden location and they would only refer to it

in the in executable only pages the idea was that even if you had full read and write access to memory you couldn't really find out where the writable pages were so you couldn't write arbitrary code into this region they switched that out in 11 for a different thing called fast permission switching where they went back to one mapping for the jet but a special system register would control whether it was writable or executable and they would basically enforce access to the access to the jet through through one gate that only that switch that bid around depending on what they wanted to do the last thing I guess I want to talk about here is pointer authentication

which is something you probably would have heard a lot about it was something added in the arm 8.3 a spec and essentially it uses some unused bits in 64-bit pointers to take a more or less a hash of the pointer encoded with another arbitrary piece of data that you can choose and so largely the idea was was that and they they introduced this in the H rolls the new iPhones that came out fairly recently in September so the idea with pact is that you can't overwrite you know do data point do pointer over writes because you won't know how to do the how to do how to do the correct hash and the hash will be

invalid and the pointer will basically be rendered invalid so environment preservation is the last thing and I think this is fairly tip unique to Apple actually this is basically we talked about a you know a protected runtime and we're you know we've protected the boot chain we've protected the the code that's running only I you know only Apple things are running but Apple has recently done something that lets say you fully compromised the kernel in the past obviously if you compromised the kernel you can execute kernel code that you want you can execute user mode code that you want so they've started trying to limit the impact of even if you fully compromised the kernel to preserve the

system integrity to some degree and there's there's several protections that they've done in in the in the attempt in an attempt to do that the first one is a PFS remount think so the the file system in the the root file system in iOS that contains all the system binaries is is mounted read-only usually when you're putting down a payload or something you want to remount it with with right access and this has typically never been especially difficult you have to modify some data structures in in memory in the kernel but once you get kernel access but but they never went out of their way to protect it but with the recent introduction of a new file system a PFS

they started using snapshotting and they started also utilizing some of the other protections and I'm going to talk about shortly to try and protect the integrity of the data structures describing the mounts so that you couldn't easily remount the file system another really important late stage mitigation is something called pre map protected layer this is going to be something that's talked about a lot over the next year it's part of the the a12 by OS kernel and it works in conjunction with PAC which we already talked about essentially what PPL is is it isolates a certain amount of kernel memory and makes it not not executable except through a certain trampoline and also protects some data so that it's not

writable even if you can write to other kernel memory what and then what they protect in this area is code that governs sensitive data structures such as page tables and codes code signing information the result of which is that even if you get kernel level access if you don't have a ppl bypass then it is it is quite difficult to be able to you know inject executable code into user mode processes modify entitlements and and and signatures at runtime and also add to the trust occasionally kernel code signing is something you're probably already very familiar with again it's been talked about at length so won't really cover that here and the last thing is a Katy RR which is

the successor to something called KP p so KP p was an original kernel patch protection it was a hypervisor like technology that would um it it infrequently through execution of the kernel would try to validate that the kernel hasn't been patched and if it found something that it that that was patched then it would panic the kernel they they eventually abandon this for something called kernel text read-only region which is a newish Hardware mitigation and essentially what this does is it just marks they they mark an area of the kernel specifically with the kernel text segment and executable code read only after it's been mapped in initially and you you can't undo it so essentially even if you get a full

read/write access to kernel memory if K trro is active and you don't know how to bypass it then you can't patch kernel code directly so that was a quick tour of iPhone security the the takeaways as far as remote jail breaks are concerned really is one thing is code integrity and the other is controlling the hardware so a big differentiator for Apple I think is code integrity basically nearly all the code that's run on the system with the exception of the the JIT mapping thing that I talked about code is essentially whitelisted all of it has been verified by Apple and rather than blacklisting or just using code integrity for a small part of the

system like a boot chain it's it's very rigid and it's quite mature now whereas before when they first implemented it it was a little bit it had a lot of weaknesses code integrity has been done before of course for trusted boot chains and you know signed ActiveX controls and things but no one has really done it as completely as iOS in a commercial product Windows S is sort of getting there but not quite the second differentiator is that Apple controls their there where there their ecosystem so they can enforce security at the hardware level and they're increasingly doing that you know where where is someone like Microsoft's might do CF GE as a as a

control flow integrity thing Apple can just go straight to hardware and and you know use pack and things like that and because they don't work with a committee or something like that they can generally get Hardware mitigations to market a lot more quickly than competitors so you know a lot of Android phones are likely going to have pack in the near future but you know Apple will have beaten them by like six months to a year some of the protections that I've gone through actually you'll notice that most of the protections that I've gone through have been implemented in hardware to some degree and that speaks to speaks to Apple's ongoing strategy hardware mitigations are often much more

difficult to bypass it sort of depends how complicated they are and how much the software side of it has to do but they can provide a much more robust security mechanism there's a few gotchas of course with this with this approach one is you need the latest devices to get the latest mitigation benefits pack you need an a12 the iPhone XS and XR otherwise you just don't have it and in theory if you found a hardware level bug it they might not be able to work around it in software and you essentially just have to wait until the next device comes out so that's a really quick introduction to iOS security now we're going to talk about what constitutes a

jailbreak so basically in order to bypass this we need a multitude of vulnerabilities into a chain and one of the difficulties of this is that any broken link in the chain might render the chain in partially or entirely useless so we're going to consider remote jail breaks today like I said USB is a really interesting use case in particular and it's worthy of its own talk but I just didn't have to fit it in there's also another kind of jailbreak a near access type one where you deliver an exploit via baseband or via Wi-Fi project zero has done a really good example of that before but again it would warrant its own talk so the goals of our jailbreak

to compromise runtime integrity be able to execute arbitrary code at runtime and to compromise the bus trusted boot chain so that we can regain code execution after after the phone has been rebooted so basically this is the template for what a typical jailbreak will look like there's five real stages basically the five stages of grief firstly you want to compromise runtime integrity so this this essentially involves getting a foothold in the system in our case it's going to be Safari but you could also get it through like a messaging app an email client you know anything the second stage is extending access breaking out of a sandbox perhaps getting an unsigned code execution this is an optional step as

we'll see the third step is getting kernel access so elevating your privileges to kernel and then getting complete control the system it's not really complete anymore because of pack-in ppl and then stage four once you've got kernel execution you want to weaken all the security mitigations as much as you can remove code signing at the entitlements you need inject into processes whatever whatever you happen to be doing and then to compromise the boot chain you basically want to place data on the system to so that when the phone is rebooted your data is passed or whatever it is you're using to get code execution each each each chain is generally about three bugs of this of a

web race web-based jailbreak some stages may not be required but often stages require more than one bug in particular information leaking is often a separate bug but typically you'll have a safari exploit you'll have a kernel and either a code-signing bypass or some kind of boot time exploit so I don't know why PowerPoint keeps running ahead of me okay so the first step is you like I said you have a variety of potential vectors the reason the browser is the most attractive target is because it's got so many things going for it that are in the attackers favor it has a large attack surface it has interaction with a complex state a number of complex state

machines the the Dom the JavaScript engine CSS etc you have the ability to groom memory is easily you have a programmatic feedback with the JavaScript language and most importantly for iOS you like I mentioned before you had the run unsigned code entitlement which means you don't need a code signing bypass once you corrupt critical data structures if you're able to write to the JED if you if you target and other things such as you know a messaging app or or a email client or something that doesn't have this entitlement then there's a huge problem in that you corrupt data there's several huge problems really one of them is that you don't have a programmatic interface

it's often harder to groom memory but also you won't have you'll have to bypass code signing which might mean having to do everything in Rob and even Rob is might not be an option with pack on the a12 the second stage like I said it's optional if you can't go directly to kernel sometimes they'll be a sandbox escape stage or a partial sandbox escape or something like it after that you want to escalate to achieve kernel level access in in jailbreak parlance this is generally referred to as TFP 0 or task for pin 0 and essentially that means you get access to the kernel task so the kernel task is a mark port and when you

have access to kernel task then basically you're able to read and write to kernel memory arbitrarily notwithstanding the protections that I mentioned earlier like I said this used to in like code execution but now it really doesn't the xposed kernel attack surface is very large and there's a lot of speeches on this but essentially you would you might be attacking in in kernel mark services system calls or iokit drivers to name a few things and again these are really restricted depending on what sandbox you're attacking from the next thing is post exploitation so once you've got TFP zero largely what you want to do is it depends on exactly what you're doing but essentially you want to weaken security

controls and installed your persistence payloads so that when the phone reboots you're able to regain control of the phone often like I mentioned this involves remounting the file system with with right privileges so regaining code execution after reboot is actually really quite difficult because of the trust boot chain that we that we briefly mentioned before essentially you have to break the chain of trust somewhere now essentially you can do this by perhaps now creating a malformed file system that gets parsed you might be able to attack executable parses image theory image for parses which is a format that Apple uses to unpack a lot of its data structures or you might be looking for a

logic floor a weakness in their cryptographic implementation so I've sort of gone over like what options you have here the exploiting the boot ROM is something that's happened once before a long time ago with an exploit called 24k pone if you're able to exploit the boot ROM it's pretty great because it's a ROM so the bug is ever-present until they release a new device in in reality though it's actually very difficult to to find a vulnerability in the boot ROM because it's very sparse it does nearly nothing specifically because of the the reason that they can't replace it there's also been a number of iboot exploits in the past I boot is is basically the thing

that loads the iOS kernel it has some similar advantages to boot ROM but it does have some mitigations in place in particularly pack on the a12 and the attack surface is is larger than the boot rom but it's still fairly slim pickings and Apple has spent a lot of time working on it due to past jailbreaks the next stage is attacking the kernel itself I feel this is a very difficult target to attack if you're going for a memory corruption type flaw because basically the full scale of memory corruption mitigations are present you have to contend with a SLR you have to contend with pack perhaps you know he pardoning all that kind of thing and

because you're not actually executing code yet your ability to grow in memory and perform race conditions and stuff is very low to non-existent so it's a very difficult target option for is attacking the user mode itself so basically there's a couple of options here firstly finding a logic flaw in the code signing machinery failing that you could try and find a memory corruption or similar floor in an Apple binary that runs at startup or you could replace an apple binary that runs at startup and exploit that again it's difficult for memory corruption because you aren't actually executing code yet so your ability to groom memory and things like that is quite limited however it's a bit

less difficult from than the kernel in that you might be able to do multiple tries and have it keep crashing until it works essentially option 4 by the way is by far the most popular vector most jail breaks that you've heard of do something in this category finding finding a floor in the code signing machinery is is by far in my opinion and most desirable option firstly it's reliable you don't have to worry about grooming memory and like that it allows privilege escalation to be performed in in native code you don't have to worry about doing rap or anything like that which again is is you know Rob is a very significant cost to the attacker so being able to bypass

that is really useful and like we said with PAC your ability to do Rob might be effectively mitigated anyway and then lastly if you have a code signing bypass you might be able to reuse it elsewhere in your chain such as if you're doing a zero click option where you're attacking a male client or something along those lines and you could control critical data structures you might be able to then launch your code signing attack and get unsigned code and then you gain back one of the advantages that the web browser would traditionally have there's various places to target this kind of vulnerability and in the past we've sort of seen ones attacking the kernel binary

loader the Marko loader the dynamic loader you know dial D and user mode which is usually responsible for loading libraries and also loading the shared cache the code signing faulting in logic which is exists within the kernel or the Apple mobile Apple mobile file integrity daemon amf ID which is also responsible for verifying and validating code signatures so these are all attractive targets and they've been numerous they're been exploited many many times in the past I've put some examples up there one on iOS 9 by Pangu they talked about in their presentation they exploited a logic vulnerability in loading the shared cache the problem is like I said it is these areas have been rather regular rigorously attacked and

undergoing a lot of scrutiny but so it's a lot more difficult target but then again that doesn't necessarily mean that there's nothing there and and be approved that with as recently as iOS 11 so now that we've sort of talked about the device the five typical stages I wanted to look at the Pegasus jailbreak this was caught in the wild and targeted a number of iOS versions but basically iOS 9.3 was about current when it got found so this was a 2016 jailbreak and this guy max did a really excellent write-up of this and and a talk about it which you can go and look at more of the details about but I just wanted to show

you how they follow the typical structure of the jailbreak like we talked about in the previous section so iOS was a tough target but not quite as tough back then so their first vulnerability was a JavaScript core exploit exploiting the JavaScript engine a use after free in something called the marked buffer implement marked argument buffer implementation this was triggered by JavaScript and there was limited heat protections I had to work around but like the chip hardening the bulletproof didn't exist yet at the time so they didn't need to worry about that so they basically had three stages that they needed to accomplish one was triggering the vulnerability which again max has done a really comprehensive write-up but

essentially when defining when defining an object with a large amount of properties there was a vulnerability there was a mistake in the marked argument buffer thing that would essentially cause it to fail to mark some of the JavaScript objects that are in use so that if a garbage collection happens they would accidentally get freed but you would still have a JavaScript variable pointing to them so a use after free vulnerability essentially so they basically exploited this vulnerability and then had to and then had a stale reference to to you know to a JavaScript object and they would then create a new object that basically reallocated that same amount of that same memory but pointed to a

different type of object and using this type confusion they were essentially able to then corrupt a UN 32 array object if you to type to raise in them in JavaScript before it's very common that you will corrupt an object such as this and then use it to sort of index the entire process address space after that they would get arbitrary code execution using a very standard method this basically what you do generally is create a new function call it repeatedly so that dynamic code gets generated it gets pointed into the JIT region then you use your a SLR primitive to find you know the J's function data structure in memory that will contain a pointer to

the JIT code for this function you can then write over that JIT code and then you call the JavaScript function essentially and execute the code you wanted to Pegasus went straight to Colonels so they didn't have a sandbox escape so they got to skip stage 2 stage 3 they had a pair of vulnerabilities like I said some stages require more than one vulnerability in this case I had a both in a function called OS uncie realized binary they had an information leak to bypass kernel a SLR and they had a use after free exploit as well they had to contend with various heap hardening things in particular internal randomization of free lists and block poisoning and of course KS allow so to

defeat KS SLR essentially like I said they had a separate vulnerability which allowed him to read excess kernel memory adjacent to to a buffer that that they had allocated from doing that they were able to get a V table and from that they were able like a V table pointer and from that they were able to calculate the the slide that the kernel has been moved by so they know where the kernel is in memory furthermore then they go and trigger the bug again this was in effect not unlike the JavaScript vulnerability that they found in that there they were able to essentially cause a use after free and maintained a reference to a stale object that had

been freed and reallocated as something else in in this particular instance basically later on this object will have a have the retained function called on it which basically involves going through a V table and so by over overriding by freeing the object then overwriting it with data that you can control you can craft your own fake V table pointer and then kick off a rope chain essentially and and you know get arbitrary code execution so once they did that in in their case they essentially installed a few rock chains in the kernel that allowed them to do D word reads and writes to kernel memory and also to perform an arbitrary kernel function call the post exploitation they

had to contend with kernel patch protection like I said this was KTR hours predecessor and it worked okay but like I said it would infrequently check the kernel and so it was basically still possible to patch the kernel and then patch it back and avoid Kate kpp to some extent also there was some publicly known complete fairly complete by palaces of it so their fourth stage obviously they did a lot of implanting malware and stuff like that but we're really only interested in weakening the kernel because that's what's relevant to our talk so the first thing they do is instead of relying on their rock chain any further they get kernel tasks the way they do that is they patch the code

in the kernel temporarily the task for bid functions so that they could perform that and get kernel tasks back into their process they escalate their own process to root by doing another kernel code patch on to set our a UID system call they then would go and beta basically new to the sandbox by modifying a policy that the sandbox installs disabled code-signing which is again they did by setting a couple of global variables and also some code patches in VM map enter and VM map protect which is that should have been VM fault enter sorry which is which is basically the entry points at which code signing at the time would you know examine pages and decide whether they're

allowed to be mapped in or not lastly they would remap the the root file system with readwrite access which basically back then involved patching a partition array in one of the kernel extensions for stage 5 again the root filesystem back then was read-only but it wasn't really protected once you had tough app it 0 so in in in their persistence strategy basically what they did is they replaced a system binary with another Apple signed binary called JSC this is a JavaScript core command-line tool which is sort of a developer and debugging tool that Apple considered trusted at the time and essentially it's it's essentially the JavaScript engine from from from WebKit from Safari except that it also has some

debugging like features and as a result of being a developer to all the code was subject to much less security scrutiny so it had some a lot a lot easier bugs than the actual JSC engine that's in WebKit so basically they would replace a binary one of the startup wineries on on disk with the JSC binary they can essentially then run a javascript file at boot they would exploit a vulnerability that they found you know in a function called set impure get a delegate and then that was a type confusion much like the other one and then exploit similarly to have exploited the other one it should be noted that the JSC binary also has to

run unsigned code entitlement so again by exploiting this this is a very attractive target because you don't have to get around code signing so that's essentially how they did it back then a lot of things have changed in spaces iOS 10 11 and 12 have added in a lot of new protections in various different areas and I've gone over a lot of those protections there's been some level of kernel heap hardening the Safari chip hardening the Safari Giga cage and then Katie RR introduction of the Apple file system and of course the pea map protected layer ppl and pointer authentication which is the things I talked about in the first section many of these mitigations have been

talked about at length in the past and if you want to learn the machinery of how they all work Luca Tedesco did a really good talk last year and I've put a link up there the new mitigations with a 12 have not been talked about a great deal because they're new but they're going to be talked about at length over the over the next year and I'm sure blaka is gonna be full of of talks about these mitigations having said that there's a little bit of discussion available online there's a really good pack discussion by Brendon hazard at project zero that I put a link to there and there's a very brief overview of ppl

available at the link I've put there ppl has been barely mentioned at all in public and is an interesting area for further research so the biggest changes in the post Pegasus world are Safari exploit mitigations refinements which affect our stage 1 the safari sandbox is always getting tightened or restricting your ability to do kernel exploits or to reach vulnerable kernel code kernel exploit mitigation refinements and runtime integrity mitigations at this point in speech I discovered about SmartArt in PowerPoint and I thought it looked way better than point slides so basically all the rest of my slides look awesome actually I found out about it back here so with Safari hacking I've gone through most of these already but

iOS 10 introduced the dual the dual mapping went from the dual mapping thing to the fast permission switching which became a thing in iOS 11 again this is to prevent the strategy exactly the strategy the Pegasus used which is get a you know run a JavaScript function a lot of times to get it entered into the jet find the pointer to the jet code and then and then just overwrite the destination with whatever code you want this is a very common strategy and so these jet mitigations are intended to make that more difficult so that complicates the arbitrary execution stage the gig occasion is an isolated heat mitigation that got added in in iOS 11 and this makes it very difficult to

exploit use after free vulnerabilities and type confusions and think things like that particularly because it prevents you from being able to map essentially arbitrary data over you know what was previously a data structure full of pointers and when you can't do that then your ability to exploit some of these vulnerabilities is is restricted and then iOS 12 on the a12 s at least prevents rhop with with pact there's been various kernel hardening mitigations the most important one that I wanted to make sure I mentioned was something I mentioned in passing in the first section which is freeing to the wrong zone so essentially the way that the kernel API works in in iOS the kernel allocator API is

you would specify a size that you wanted to allocate in the allocation of something and you would also specify it when you're freeing it and it would use that size to decide what zone it's what zone it's going to go to in many cases so essentially again Stefan Esther has talked about the kernel heap in great detail but there's basically different areas of memory that are reserved for different sized allocations and so obviously if you got say a 16 byte block accidentally freed to a 64 byte zone the next person that allocates a 64 byte allocation is going to get that 16 byte block back and you can trigger that vulnerability to then work it into an

overflow and do something useful so they've eliminated that also by also as an exploitation technique it was quite useful because you know if you overrode a data structure and such that you got you know you override a pointer and get it freed to the wrong zone then you might be able to get it allocated into a different zone that you weren't easily able to access before and then and then do some memory corruption in that zone they also did a number of metadata heap hardening techniques which again has been talked about at length but more or less moved metadata out of the actual zone and into its own isolated zone runtime integrity is the thing that I think has changed the most

in the last few years remember the first goal of a jailbreak is to compromise the runtime and that took four stages to do pre iOS 9 run time integrity was completely undermined once you've got task for pit zero basically once you've got read and write access to kernel memory you can patch the kernel you can run arbitrary kernel code you can change page permissions you can do anything you want you can and that would also imply that you could run arbitrary user mode code because you could modify the trust cache which is used to validate you know system binary is so you could add your own so you could run any binary you want you could remove code

signatures you could replace them you could inject entitlements all that kind of thing Apple is trying to address this shortcoming quite aggressively and this is the sort of environment presentation stuff that I was kind of talking about in the first section so this is another awesome smart by the way so basically with the a9 is the iOS 9 is where they started started trying to do this and that and the first attempt was with kernel patch protection which again was a hypervisor type technology that would infrequently validate parts of the kernel and cause a panic if any of the kernel code had been modified so this was a problem but you could sort of work

around it by temporary patching which is what a lot of jail breaks sort of did there was also a couple of bypasses that have been published in particularly Pangu mentioned one of them in a talk that I that I gave a link to earlier the a-10 then changed that and and introduced in a new feature called kernel text read-only region or ktdrr which is intended to replace kpp this one was much more a much more complete solution you could basically set up a kernel region in memory at early boot and then say ok this can never be this can never be written to from now on and so the kernel text and the text segment

and executable code basically can't be modified after that and so basically that was a real problem because it essentially means that even with tasks for pin 0 you can't execute kernel code anymore and you have to rely on kernel rock which is not very nice and then the a12 switch came out just late last year in September they took this one step further and added pack and this now means that not only can you not do kind of Rob even if you've got full read/write access to kernel memory but you need to buy a pack bypass enable to even do kernel Rock so this makes it really difficult to actually execute any code in the context of the kernel the

other thing is injecting into user mode is is also now quite difficult because you can't easily run unsigned code because the critical data structures managing you know the code signatures and page tables and things like that and now protected by the ppl region which even if even if you could Rob you you can't just arbitrarily modify the kernel data structures that you need to you need to find a bypass in ppl you basically need to find an entry point a defined entry point in ppl that will allow you to you know modify the trust case or do arbitrary code manipulation so this is our solution I don't know what you guys are going to do but I'm

just gonna ask Cyril and Taji for the answer for bypassing PAC so if you look at how Pegasus worked and Pegasus was only two years old the structural changes that Apple have made have really significantly impacted how a jailbreak might work they used to gain code execution just writing to the jet now they have to worry about bulletproof jet to get around that they used to do a V table overwrite which is effectively mitigated by pack they have they previously installed Rob backdoors to get started again pack is a problem they're when they're weakening the the controls for the system they did multiple kernel patches now no longer an option because KTR are remounting the

file system they have to get around the AP FS integrity stuff and to backdoor any user mode processes they now need a ppl bypass and the other thing worth noting is that JSC has been removed from apple's trust case which means it's no longer considered a trusted binary much to the chagrin of many jailbreakers so if you look at the iOS 9 jailbreak it was a difficult task you needed Safari possibly a sandbox escape kernel maybe kpp bypass and persistence but if you compare it to what we have today you need to do all of those things plus a bulletproof kit bypass a user mode pack bypass potentially a kernel mode pack bypass potentially ppl bypass and a PFS

remounting bug in order for persistence so in summary it's always been a difficult task to jailbreak an iPhone but in particular with the recent mitigations especially the a12 a full compromise of the ecosystem is is really difficult you know often your combined to confined to rhop and don't have the ability to do unconstrained code execution and even then pack and ppl once they have matured a little further are going to represent a very significant barrier to even doing that so I think in the future we're going to likely see increasingly relying on data only attacks programming weird machines and things like that and I expect in turn that Apple will have newer mitigations that will expand on this by

verifying data structure integrity and you know making sure that you can't modify critical data structures or that they detect and panic or something along those lines so that's the end of my talk thanks for listening and if anyone has any questions I can take them now

you