19.11.2016 Views

Technical Analysis of the Pegasus Exploits on iOS

eNQc3Ry

eNQc3Ry

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

p = (unsigned int)&stackAnchor & 0xFFFFF000;<br />

// kauth_filesec.fsec_magic<br />

(p + 0xEC0) = 0x12CC16D;<br />

// kauth_filesec.fsec_acl.entrycount = KAUTH_FILESEC_NOACL<br />

(p + 0xEE4) = -1;<br />

// kauth_filesec.fsec_acl.acl_ace[...]<br />

memcpy(&stackAnchor & 0xFFFFF000 | 0xEEC, pExploit, 128);<br />

The stack has <str<strong>on</strong>g>the</str<strong>on</strong>g> following layout at <str<strong>on</strong>g>the</str<strong>on</strong>g> start <str<strong>on</strong>g>of</str<strong>on</strong>g> <str<strong>on</strong>g>the</str<strong>on</strong>g> new thread’s executi<strong>on</strong>:<br />

char stackAnchor; // [sp+101Fh] [bp-2031h]@1<br />

unsigned int size; // [sp+2020h] [bp-1030h]@12<br />

char buffer[4096]; // [sp+2024h] [bp-102Ch]@12<br />

int v26; // [sp+3024h] [bp-2Ch]@7<br />

mach_port_t c<strong>on</strong>necti<strong>on</strong>; // [sp+3028h] [bp-28h]@4<br />

kern_return_t result; // [sp+302Ch] [bp-24h]@4<br />

mach_port_t masterPort; // [sp+3030h] [bp-20h]@3 MAPDST<br />

Using <str<strong>on</strong>g>the</str<strong>on</strong>g> variable dubbed stackAnchor, <str<strong>on</strong>g>the</str<strong>on</strong>g> new thread finds a page boundary address for<br />

<str<strong>on</strong>g>the</str<strong>on</strong>g> stack. Then, by allocating a large array to ensure that at least <strong>on</strong>e page <str<strong>on</strong>g>of</str<strong>on</strong>g> <str<strong>on</strong>g>the</str<strong>on</strong>g> stack is<br />

unused by functi<strong>on</strong> critical variables, <str<strong>on</strong>g>the</str<strong>on</strong>g> new thread can c<strong>on</strong>struct a kauth_filesec structure<br />

that c<strong>on</strong>tains significantly more informati<strong>on</strong> than is necessary. By setting <str<strong>on</strong>g>the</str<strong>on</strong>g><br />

acl_entrycount to indicate that <str<strong>on</strong>g>the</str<strong>on</strong>g>re are no ACE records, when open_extended<br />

processes <str<strong>on</strong>g>the</str<strong>on</strong>g> kauth_filesec structure, it will not attempt to parse any data bey<strong>on</strong>d <str<strong>on</strong>g>the</str<strong>on</strong>g><br />

acl_flags variable, thus preserving <str<strong>on</strong>g>the</str<strong>on</strong>g> integrity <str<strong>on</strong>g>of</str<strong>on</strong>g> <str<strong>on</strong>g>the</str<strong>on</strong>g> exploit buffer and preventing <str<strong>on</strong>g>the</str<strong>on</strong>g> kernel<br />

from possibly having issue with how <str<strong>on</strong>g>the</str<strong>on</strong>g> exploit buffer would be interpreted as an actual ACE<br />

record. The end result <str<strong>on</strong>g>of</str<strong>on</strong>g> calling open_extended is to copy <str<strong>on</strong>g>the</str<strong>on</strong>g> exploit buffer (al<strong>on</strong>g with <str<strong>on</strong>g>the</str<strong>on</strong>g><br />

clock_ops_overwrite buffer) into kernel memory.<br />

The new thread takes advantage <str<strong>on</strong>g>of</str<strong>on</strong>g> this behavioral oddity within <str<strong>on</strong>g>the</str<strong>on</strong>g> open_extended syscall in<br />

order to place <str<strong>on</strong>g>the</str<strong>on</strong>g> (unmodified) payload into <str<strong>on</strong>g>the</str<strong>on</strong>g> kernel memory. The address for that payload is<br />

<str<strong>on</strong>g>the</str<strong>on</strong>g>n recovered using <str<strong>on</strong>g>the</str<strong>on</strong>g> previously discussed vulnerability that allows kernel memory to be<br />

leaked back to user mode. When <str<strong>on</strong>g>the</str<strong>on</strong>g> AppleKeyStore vulnerability is exploited, <str<strong>on</strong>g>the</str<strong>on</strong>g> variable<br />

dubbed buffer is passed to io_service_open_extended (<str<strong>on</strong>g>the</str<strong>on</strong>g> same variable that resides<br />

adjacent to <str<strong>on</strong>g>the</str<strong>on</strong>g> stackAnchor). This behavior means AppleKeyStore returned a pointer for<br />

kernel memory that was ultimately next to <str<strong>on</strong>g>the</str<strong>on</strong>g> exploit code copied in by <str<strong>on</strong>g>the</str<strong>on</strong>g> syscall to<br />

open_extended. Therefore, <str<strong>on</strong>g>the</str<strong>on</strong>g> purpose <str<strong>on</strong>g>of</str<strong>on</strong>g> <str<strong>on</strong>g>the</str<strong>on</strong>g> new thread is not to overwrite <str<strong>on</strong>g>the</str<strong>on</strong>g> clock handler<br />

pointers, but ra<str<strong>on</strong>g>the</str<strong>on</strong>g>r to set <str<strong>on</strong>g>the</str<strong>on</strong>g> stage for such an attack.<br />

Once <str<strong>on</strong>g>the</str<strong>on</strong>g> new thread completes, <str<strong>on</strong>g>the</str<strong>on</strong>g> variable c<strong>on</strong>taining <str<strong>on</strong>g>the</str<strong>on</strong>g> memory address <str<strong>on</strong>g>of</str<strong>on</strong>g> <str<strong>on</strong>g>the</str<strong>on</strong>g> exploit<br />

buffer obtained by <str<strong>on</strong>g>the</str<strong>on</strong>g> new thread as part <str<strong>on</strong>g>of</str<strong>on</strong>g> <str<strong>on</strong>g>the</str<strong>on</strong>g> AppleKeyStore informati<strong>on</strong> leak is tested to<br />

determine if it was indeed set by <str<strong>on</strong>g>the</str<strong>on</strong>g> new thread (prior to calling <str<strong>on</strong>g>the</str<strong>on</strong>g> new thread, <str<strong>on</strong>g>the</str<strong>on</strong>g> variable<br />

that holds <str<strong>on</strong>g>the</str<strong>on</strong>g> kernel address is initialized to 0x12345678). If <str<strong>on</strong>g>the</str<strong>on</strong>g> new thread did not successfully<br />

obtain <str<strong>on</strong>g>the</str<strong>on</strong>g> kernel memory locati<strong>on</strong>, 32Stage2 will call <str<strong>on</strong>g>the</str<strong>on</strong>g> assert callback and exit.<br />

After <str<strong>on</strong>g>the</str<strong>on</strong>g> completi<strong>on</strong> <str<strong>on</strong>g>of</str<strong>on</strong>g> <str<strong>on</strong>g>the</str<strong>on</strong>g> new thread’s activities, and if <str<strong>on</strong>g>the</str<strong>on</strong>g> ph<strong>on</strong>e reports itself as “iPh<strong>on</strong>e4,1”<br />

(<str<strong>on</strong>g>the</str<strong>on</strong>g> iPh<strong>on</strong>e 4 series), <str<strong>on</strong>g>the</str<strong>on</strong>g> main thread will generate up to 1000 threads. Each <str<strong>on</strong>g>of</str<strong>on</strong>g> <str<strong>on</strong>g>the</str<strong>on</strong>g> threads will<br />

Page 24

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!