1 of 42

the path to EL1 in iOS 11

@i41nbeer

Please expand the speaker notes if you’re reading this deck!

2 of 42

I find bugs, and sometimes exploit them

I joined chrome security in 2013, then project zero when Chris Evans started the team. This team has an expanded remit to look at the security of the internet. I mostly look at iOS these days with a major focus on sandboxing and kernel exploitation.

Why should you listen to me? I think I do have a pretty good idea how iOS actually works and how to exploit it. Since Apple launched their bug bounty two years ago I've spent a lot of my time writing exploits for iOS to make it easier for researchers to actually participate in the bounty, because Apple don't provide the necessary tools. If you've ssh'ed in to an iPhone in the last two years you probably ran one of my sandbox or kernel exploits (or used your own ;) <There are a lot of other people who made it possible to actually use SSH; I just did the exploitation bit>

Today I'm mostly going to try to emphasize why I think this work is important, and why I don't think vendors are taking exploitation seriously enough. I think perhaps we do a poor job of emphasizing why this stuff matters.

3 of 42

15 years ago...

4 of 42

http://cseweb.ucsd.edu/~savage/papers/IEEESP03.pdf

5 of 42

char db_name[16];

...

strcpy(db_name, &udp_packet[1])

6 of 42

poor software development practices used to lead to CLEARLY VISIBLE harm

7 of 42

"Our new design approaches need to dramatically reduce the number of such issues that come up in the software that Microsoft, its partners and its customers create"

https://www.wired.com/2002/01/bill-gates-trustworthy-computing/

8 of 42

"At the same time, we're in the process of training all our developers in the latest secure coding techniques."

https://www.wired.com/2002/01/bill-gates-trustworthy-computing/

9 of 42

10 of 42

"So now, when we face a choice between adding features and resolving security issues, we need to choose security."

https://www.wired.com/2002/01/bill-gates-trustworthy-computing/

11 of 42

15 years later

12 of 42

https://assets.documentcloud.org/documents/4599753/NSO-Pegasus.pdf

This is a rack diagram from the pegasus product description pamphlet.

Why am I showing you this? Because most of the discussion you read about NSO and Pegasus generally just talks about numbers and exploits; you've I'm sure all seen the Million Dollar Dissident story, and that's what people take away, I think they actually take that large number as a kind of comfort blanket. I know that people at Google do. I think the reasoning goes: well, that's a lot of money isn't it, to hack one person! ASLR works, and makes us 99.7% secure!

I want to try to paint a different picture, starting with this image. Pegasus is a product from NSO; which is majority owned by a san francisco private equity company. NSO are not selling exploits; they are selling a complete CNE-in-a-box (well, two boxes) solution. In addition to this you also purchase some operator terminals which run their data visualization and analysis front-end software.

There are two motivational points I want to emphasize here:

1) This is clearly targeted at customers with no CNE experience. The sales manual explicitly says the for the over-the-air installation method the operator only needs to put in a phone number, then the agent is installed. That's the level of sophistication which is required from the customer. My personal fear here is that exploitation is an extremely powerful and asymmetric tool. You, and indeed I, might feel comfortable that some government institutions, of some governments, are capable of handling such tools. But this isn't targeted at them, this is for organizations which haven't got decades of technical and policy experience in how to balance this extraordinary asymmetric power. In the wrong hands this tool is a very powerful weapon against dissent; and that *is* how it's used. But it's not only for suppressing political dissent. The slippery slope is real. A global problem, and one which especially affects the US is obesity. Citizenlab have collected evidence suggesting exploits served by one of these systems were sent to two employees of an NGO which campaigns in favour of the mexican sugar tax. Is that really a justified use of such power?

2) the prices quoted are widely misused to paint an inaccurate picture of code quality. The comfort blanket "okay, maybe the code isn't perfect, but it's still a $1M" isn't real; and this is not helpful. This system is not serving unique single-exploit-per-target, the true discovery and exploitation costs of the bugs involved I think are far lower than people believe, and this is the part which p0 are focused on. The quoted prices are taking you from literally nothing, to mid-level intelligence agency capability, that costs money, and it's mostly not the cost of the exploits.

13 of 42

15 years later:

now, poor software development practices lead to HIDDEN harm

in Android and iOS

quite widespread and damaging,

but easy to ignore

14 of 42

security systems design is making promises which poor software development practises cannot keep

15 of 42

https://www.apple.com/business/docs/iOS_Security_Guide.pdf

both iOS and Android's current security leads come from security systems design backgrounds.

Dave Kleidermacher has a background in small RTOSs for avionics and stuff like that (https://www.ghs.com/AerospaceDefense.html)

Ivan Krstic came to Apple from OLPC where he designed Bitfrost, the OLPC's security architecture.

Both these leaders have strong security engineering skillsets, but they don't have an exploitation background. I feel that this academic level understanding of security perhaps tends to discount implementation flaws. If a bug is found, you fix it and the system is perfect again. The focus is on the system design, not the implementation.

I do not come from this background; I come from an exploitation background, and I see things the opposite way. To me code to me is nothing but a collection of bugs in implementation details.

16 of 42

given sufficient bug density, security design is irrelevant

17 of 42

"feedback that we've heard pretty consistently, both from my red team at Apple and also from researchers directly, is that it's getting increasingly more difficult to find those most critical types of security vulnerabilities."

18 of 42

mach_voucher_extract_attr_recipe_trap(

struct mach_voucher_extract_attr_recipe_args *args) {� ipc_voucher_t voucher = IV_NULL;� kern_return_t kr = KERN_SUCCESS;� mach_msg_type_number_t sz = 0;�� if (copyin(args->recipe_size, (void *)&sz, sizeof(sz)))� return KERN_MEMORY_ERROR;

.....

uint8_t *krecipe = kalloc((vm_size_t)sz);

if (!krecipe) {

kr = KERN_RESOURCE_SHORTAGE;

goto done;

}

if (copyin(args->recipe, (void *)krecipe, args->recipe_size)) {

this code shipped in iOS 10, the first release after Ivan announced the bug bounty. Yes, this is a little dated but all of the lessons apply to more recent bugs which we'll get to later. This is a bug I found, using grep.

So if you're not familiar with the XNU kernel, this was a brand new syscall, reachable from any sandboxed context (like a safari renderer.) You control the values pointed to by args. copyin takes a userspace pointer, a kernel pointer and a size, then copies size number of bytes from the userspace pointer to the kernel pointer.

If you've not seen this code before, I'll wait a few seconds for you to play spot-the-bug. And I like this example because it's one of those cases where the code is so wrong that you have to question your analysis.

So, it's using a userspace pointer value as both a pointer and a length. But you say, what about trustworthy computing, and annotations? Surely this is exactly the type of thing which shouldn't be possible. This shipped for almost 6 months, until I got around to grepping the xnu diffs, which apple release sporadically, for iOS 10 for copyin/copyout. This is the type of issue which I'm claiming is on the same order of complexity as David Litchfield's SQL server bug from 15 years ago. There's no need to understand complex or esoteric stuff about the OS, just knowing C should let you see this code is wrong.

So, there are clearly no annotations, so automated tools won't flag this. (I mean, actually you should get compiler warnings, but good luck compiling XNU with warnings enabled :) )

What about code review? Writing C code is hard, and this is a new syscall reachable from everywhere on the system. It's clearly not been reviewed by someone with a vulnerability research background, I believe they would spot this. This kind of stuff is still happening today, in iOS 11, in fact in code so recent that I can't talk about it because of the 90 day deadline

What about testing? You might realize that it's actually kinda tricky to run that code at all without causing memory corruption? Yeah, there are no tests, and apple are clearly not fuzzing this.

19 of 42

if (dst->sa_family == AF_INET &&

dst->sa_len != sizeof(mpte->__mpte_dst_v4)) {

error = EINVAL;

goto out;

}

if (dst->sa_family == AF_INET6 &&

dst->sa_len != sizeof(mpte->__mpte_dst_v6)) {

error = EINVAL;

goto out;

}

if ((mp_so->so_state & (SS_ISCONNECTED|SS_ISCONNECTING)) == 0) {

memcpy(&mpte->mpte_dst, dst, dst->sa_len);

}

20 of 42

legacy & esoteric

those two bugs lie firmly in the class of legacy bugs. (even though they're quite new code.) Please bear in mind that I am not trying to criticise the individual devs, these legacy bugs are failures of process; it should not be possible to commit such code, it should be prevented by annotations (eg __user), code review, manual testing and perhaps also fuzzing. These are the kinds of issues which Bill Gates was discussing 15 years ago, they shouldn't be still being introduced in "secure" code bases now. This was only a small selection, please go to the p0 tracker to see all the similar issues. My point here is that these aren't one offs, these are systemic process failures, and that's what needs to be addressed.

Other issues fall into the more esoteric bucket; that is, they're not simple C coding issues like buffer overflows but require a bit more understanding of the underlying system and and its paradigms.

Let's look at two examples of esoteric bugs, which also say something about Apple's security culture

21 of 42

Mach is full of weird APIs, they are slowly being turned off or removed, which is a very good thing, and I think that Apple perhaps lack the institutional memory to know quite why they're still there.

iOS has a confusing and complicated privilege model, it's more complex than simply users and root; root is quite distinct from EL1, and each process has its own set of entitlements, with checks for entitlements dotted fairly randomly across userspace and the kernel. Entitlements are an example of security engineering design meeting a real-world codebase; the actual reality is very messy and complicated.

This is a an old feature, which, if you're root, gives you memory read/write to all userspace processes on the system, without you requiring the entitlement which is meant to prevent that.

I didn't find this bug, I read it in a book written in 2012 by Jonathan Levin :) I kinda assumed it had been fixed, because, you know, it's in this old book, but I tried the code on iOS and it worked, completely breaking the entitlements security checks. (<I found myself in the position where I could actually test this issue; you don't have anything like userdebug builds on iOS, you need to write a working priv-esc exploit yourself to test this on the latest iOS.>This wasn't fixed until some time in to iOS 11, and only because I used it in an exploit. I used this bug to turn off userspace code signing and build a userspace debugger, <Here's a writeup of my triple_fetch exploit: https://jaq.alibaba.com/community/art/show?articleid=1020>

Apple are not doing enough proactive vulnerability research, they're not even fixing bugs clearly documented in books. Jonathan Levin in fact even had this code on a special web page, I didn't even need to type it in, just copy/paste, but I did need to bring my own 0day.These bugs completely break the security systems design; you have to care about bugs. Attackers will use them.

22 of 42

we've discussed lack of code review, lack of testing, lack of auditing and lack of proactive vulnerability research.

This is an example of a failure of variant analysis. In 2016 I reported a bunch of issues I found in userspace services which were written using this ancient tool called MIG. MIG is the most horrendous codebase you will ever see; thousands of lines of c code fprintf'ing c code to generate RPC stubs. I and others have found bugs in this generated code, but this issue I'll talk about is simpler.

MIG has a simple rule for object lifetime management, for the objects which you pass across these RPC boundaries. If your handler returns success (0) then your handler is responsible for the lifetime of any objects which were passed to it. If your handler returns an error code, then the system will retain ownership of any objects passed to you.

This means that you cannot return an error code and take ownership of an object. The most common instance of this bug class is a handler dropping a reference on an object and then returning an error code.

Most MIG services are closed source; it's highly tedious to find all the variants of this without source, and often without even symbols for the binaries. Apple, I guess, do have the source code, and it should be *so* much easier to search for variants of this anti-pattern with source. But I don't see evidence of this, there are still more variants all the time; for example the recent crash reporter bugs.

This was just a small selection of bugs; it's supposed to be indicative of the much larger range of issues which I've found. Please don't discount these as "just a few more bugs", I am trying to tell you that this is systemic, these are avoidable, and you're not doing well enough.

23 of 42

24 of 42

mitigations

If you prefer to try to engineer your way out of vulnerabilities rather than investing in VR and developer process changes then, you write mitigations! This is a trend across the whole industry. Android and iOS especially are invested in this approach. You can see Dave Kleidermacher's talk from the google cloud conference a few weeks touting Android's mitigations as making it more secure. This is dangerously naive, but these leaders don't come from an exploitation background. I also get the feeling that the people designing and implementing these mitigations don't have exploitation backgrounds either. It seems to me to often be more: there was a public proof-of-concept exploit, let's make a small change to the heap allocator and now we're secure! Let's take a kernel heap allocator as an example to look at:

25 of 42

weak mitigations can be trivially defeated with more bugs; if you don't care about bugs there's no point shipping weak mitigations

26 of 42

randomization

27 of 42

zone_map

384 MB reserved kernel vm region (across all iOS 11 devices)

kalloc.64 zcram

X

small number of hardware pages

individual allocations

28 of 42

zone_map

384 MB reserved kernel vm region (across all iOS 11 devices)

kalloc.64 zcram

X

small number of hardware pages

individual allocations

29 of 42

zone_map

384 MB reserved kernel vm region (across all iOS 11 devices)

kalloc.64 zcram

X

small number of hardware pages

individual allocations

30 of 42

unsigned int random_bool_gen_bits(

struct bool_gen *bg, unsigned int *buffer, unsigned int count, unsigned int numbits)

{

unsigned int index = 0;

unsigned int rbits = 0;

for (unsigned int bitct = 0; bitct < numbits; bitct++) {

// Find a portion of the buffer that hasn't been emptied.

// We might have emptied our last index in the previous iteration.

while (index < count && buffer[index] == 0)

index++;

// If we've exhausted the pool, refill it.

if (index == count) {

random_bool_gen_entropy(bg, buffer, count);

index = 0;

}

// Collect-a-bit

unsigned int bit = buffer[index] & 1;

buffer[index] = buffer[index] >> 1;

rbits = bit | (rbits << 1);

}

return rbits;

}

Just as some random trivia with probably no security impact (yet), here's the random bit stream generator they use for this. I am certainly no cryptographer, but even I can spot that this random bit generator is biased.

So they are filling buffer with random 32-bit values. Index is an index into this buffer; and it's incremented such that it is the index of the first non-zero dword in buffer. They then take the least-significant bit of the dword at offset index in buffer and shift it into the result value, and shift if out of the dword at index in buffer.

This means that any leading zero bits in the random dwords will be ignored; subtly biasing you towards choosing 1's over 0's.

31 of 42

zone_map

384 MB reserved kernel vm region (across all iOS 11 devices)

kalloc.64 zcram

X

small number of hardware pages

individual allocations

32 of 42

1) there's still a pattern

33 of 42

2) larger objects are less randomized

34 of 42

3) can we just sort the freelist?

35 of 42

please stop just spot-fixing bugs;

learn from them, and act on that

the current fashion, that mitigations will save us, is wrong. Strong mitigations (actually making meaningful reductions in reachable attack surface) are relevant, but only in conjunction with caring about bugs. Each bug should be a lesson; you're a secure codebase! why is it there? how was it introduced? how could we have caught this earlier? what process problems do we need to address? who should have had access to this code to review it but couldn't for political reasons? how do we find every instance of this bug and fix it? How do we genuinely kill this bugclass?

Bugs need to be viewed through the lense of: someone already found this and it's being exploited. I am very certain that a large proportion of the issues which I find in iOS are being actively exploited; or, more worryingly, trivial variants of them which I haven't found are being exploited.

36 of 42

...one more thing

The reason I decided to give this talk was that I believe I'm failing in my goal to actually do my small part to move the world towards more trustworthy computing. It's too easy for vendors like Google, Samsung and yes, Apple, to ignore exploitation. They like to tout themselves as being data-driven; making decisions on evidence and big data. This doesn't work for this kind of security; by definition good attackers don't get caught; you don't collect big data. I hope that earlier I managed to convince you that targeted exploitation is widespread, it's too easily abused for causes which you probably don't believe in, and it has societal impact much wider than the single targeted user of each attack. I hope I've also managed to convince you that the bar for iOS exploitation is really very low; there is no comfort blanket to wrap yourself; if you're campaigning for human rights or against childhood obesity, you can still be a target.

I have had to leave out many anecdotes which would make my points more clearly because I am genuinely afraid of being targeted, not by governments but by private individuals involved in this stuff. I too rely on these devices.

But nothing changes; like Parisa said in her keynote this morning; it's all spot fixes and not genuinely raising the bar. Without organizational change from the top declaring that Apple has a security problem nothing is going to get better. I've reported over 150 bugs similar to those handful I've shown today, all with detailed technical writeups, but as an external party I don't see any momentum within Apple for change.

37 of 42

https://www.amnesty.org/en/latest/research/2018/08/amnesty-international-among-targets-of-nso-powered-campaign/

38 of 42

39 of 42

apple bug bounty

40 of 42

"it's not meant to be any kind of exclusive club. So, if someone who is not in the program, brings to us a vulnerability that would be covered under the program, we welcome that, we're going to take a look, and if the work merits it we'll invite them in to the program and we'll reward the vulnerability that they found."

41 of 42

"In addition to these exact amounts we will let researchers donate the reward to a charity of their choosing, we will at our option match that 1 to 1, doubling the donation."

42 of 42

CVE-2016-7612 $100'000

CVE-2016-7621 $100'000

CVE-2016-7644 $100'000

CVE-2017-2353 $100'000

CVE-2017-2370 $100'000

CVE-2017-2360 $100'000

CVE-2017-2473 $100'000

CVE-2017-2474 $100'000

CVE-2017-2478 $100'000

CVE-2017-2501 $100'000

CVE-2017-2482 $100'000

CVE-2017-2490 $100'000

CVE-2017-13867 $100'000

CVE-2017-13847 $100'000

CVE-2017-13861 $100'000

CVE-2018-4241 $100'000

CVE-2018-4243 $100'000

694799600 $100'000

696255847 $100'000

CVE-2016-7637 $50'000

CVE-2016-7661 $50'000

bug with charity match

CVE-2016-7660 $50'000

CVE-2017-2522 $50'000

CVE-2017-2523 $50'000

CVE-2017-2524 $50'000

CVE-2017-7047 $50'000

CVE-2018-4206 $50'000

695930632 $50'000

695992129 $50'000

696619631 $50'000

$2'450'000

here's 30 bugs I found and reported to Apple since the launchf of the bug bounty, each with detailed technical writeups and reproduction cases and each defeating critical parts of the iOS security model. Adding it up with the corporate donation matching I make that 2.45 million dollars.

Apple, today I'm asking you to actually follow through on that bug bounty you launched two years ago; I was never invited, despite having reported so many bugs. Today, I want to use that bounty as a tool to demonstrate that you do have a problem and need to do more to fix it, and also I figure I'd like to give a lot of money to a good cause.

Tim: I don't want people to get hacked using variants of the bugs I report and you do a poor job of fixing. But I worry that this is happening. Look up those highlighted issues in the apple bug tracker, and find out why they happened, why they weren't caught earlier, and what processes need to change to prevent them happening again. I am happy to come to Cupertino and sit down with you and my laptop and walk through them, and share my concerns because at the moment, together, we are not doing well enough.