search

telnetgmike / google-security-research

Automatically exported from code.google.com/p/google-security-research
0 stars 0 forks source link

OS X coresymbolicationd multiple user to root privilege escalations due to XPC type confusion #80

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
coresymbolicationd is an on-demand xpc service running as root with the service 
name "com.apple.coresymbolicationd".

The coresymbolicationd commands match_mmap_archives, delete_mmap_archives, 
write_mmap_archive and read_mmap_archive all perform insufficient type 
validation of xpc_object_t's:

The top level type of an xpc message is a dictionary, the function at 
__text:0000000100001620 in coresymbolicationd is responsible for parsing this 
dictionary and sending any reply messages.

The value of the key "cmd" is a uint64 which determines the intended command. 
For messages with a cmd value of 2 or 3 (match_mmap_archives and 
delete_mmap_archives) coresymbolicationd will read a value from the top level 
dictionary with the key "filters". For messages with a cmd value of 4 or 5 
coresymbolicationd will read a value with the key "entry". In all these cases 
coresymbolicationd uses the xpc_dictionary_get_value API which enforces no type 
on the returned value (the value of these keys can be any xpc type.) The 
returned object in each case is then used as an xpc array without checking that 
it is in fact an xpc array. From this array another array is read at offset 0 
using xpc_array_get_value.

It just so happens that the layout of xpc strings and arrays overlap in such a 
way that the string length field will be interpreted as the array length field 
and the string character data pointer will be interpreted as the array data 
pointer - this means that we can craft a string such that the first 8 
characters will be interpreted as a pointer to an xpc_object_t. This type is 
just an objective-c object (right?) - at the very least the subsequent 
xpc_retain call allows an arbitrary increment,
and I'm pretty sure that you could get code execution by pointing to a fake 
objective-c object with a cached "_xref_dispose" method. All the phrack 
articles are pretty out-of-date on objective-c internals though so I haven't 
played with this more yet.

This PoC will crash trying to increment the reference count of an object at 
0x4141414141414141.

either attach to coresymbolicationd if it's running or get lldb to wait for it 
like this:

$ sudo lldb
(lldb) process attach --name coresymbolicationd --waitfor

then run the attached PoC

Original issue reported on code.google.com by ianb...@google.com on 30 Jul 2014 at 5:28

Attachments:

GoogleCodeExporter commented 9 years ago 
Issue 81 has been merged into this issue.

Original comment by ianb...@google.com on 30 Jul 2014 at 5:29

GoogleCodeExporter commented 9 years ago

Original comment by ianb...@google.com on 30 Jul 2014 at 5:36

GoogleCodeExporter commented 9 years ago

Original comment by ianb...@google.com on 30 Jul 2014 at 5:48

GoogleCodeExporter commented 9 years ago

Original comment by ianb...@google.com on 23 Sep 2014 at 7:16

GoogleCodeExporter commented 9 years ago

Original comment by ianb...@google.com on 8 Nov 2014 at 4:53

GoogleCodeExporter commented 9 years ago 
Deadline exceeded -- automatically derestricting.

Original comment by cev...@google.com on 8 Nov 2014 at 4:54

GoogleCodeExporter commented 9 years ago 
Apple advisory: http://support.apple.com/en-us/HT204244

Original comment by ianb...@google.com on 4 Feb 2015 at 11:55