iOS/MacOS sandbox escape due to failure to comply with MIG object lifetime semantics in iohideventsystem_client subsystem 




iohideventsystem_client is a MIG subsystem used by hidd or backboardd to send notifications to their clients. That is, you first have to pop backboardd, *then* use this to get in to a different, more privileged client. Both on iOS and MacOS there are more privileged clients.

This code is yet another very trivial variant, not only of these MIG bugs which I've been going on about for years, but it's literally using the same functions as a bug which KEEN team just got nominated for a pwnie for. But it as usual seems that I'm the only person who ever looks at these things (apart from the offensive community who don't report them.)

Perhaps the person at Apple who looked at KEEN's report didn't understand the complexities of the iOS and MacOS security model and realize that getting from backboardd to a different client is a privilege escalation. You really should look in to why these variants didn't get fixed; with source the bugs should look *exactly* the same...

anyway, what is the bug?

these MIG methods:

iohideventsystem_client_dispatch_virtual_service_copy_property
iohideventsystem_client_dispatch_virtual_service_set_property
iohideventsystem_client_dispatch_virtual_service_notification
iohideventsystem_output_event_to_virtual_service
iohideventsystem_copy_event_from_virtual_service


all don't respect MIG semantics; they deallocate ool memory passed to them and can also return an error, meaning MIG will deallocate that same address again.

I'm not gonna write a PoC, you can trivially repro it in the debugger:

on MacOS attach to hidd (you'll need to do this on another machine using lldb-server, or via ssh)

(lldb) break set -r ".*iohideventsystem_client.*"
Breakpoint 1: 29 locations.

Process 144 resuming
Process 144 stopped
* thread #5, queue = 'IOHIDService(0x7fc2b5d0ef90): 0x10000203d , IOHIDEventDriver', stop reason = breakpoint 1.22
    frame #0: 0x00007fff34a4fee7 IOKit`iohideventsystem_client_dispatch_properties_changed
IOKit`iohideventsystem_client_dispatch_properties_changed:
->  0x7fff34a4fee7 <+0>: push   rbp
    0x7fff34a4fee8 <+1>: mov    rbp, rsp
    0x7fff34a4feeb <+4>: push   r15
Target 0: (hidd) stopped.
(lldb) reg r rdi
     rdi = 0x0000000000005c03

go look up that port with lsmp; in this case it was powerd, which runs as root

attach a debugger to it, set a breakpoint on _iohideventsystem_copy_event_from_virtual_service in the target, then back in hidd:

(lldb) expr (void*) malloc(0x1000)
(void *) $0 = 0x00007fc2b8005000
(lldb) expr (void*) malloc(0x1000)
(void *) $1 = 0x00007fc2b7011a00
(lldb) expr (void*) malloc(0x1000)
(void *) $2 = 0x00007fc2b9801200
(lldb) expr (int) iohideventsystem_copy_event_from_virtual_service(0x5c03, 12345, 0, 0x00007fc2b8005000, 0x1000, 0, 0x00007fc2b7011a00, 0x00007fc2b9801200, 0x20)

that's manually calling the mig client code; we can trigger an error path by passing an invalid client id (12345)

in the target debugger (in this case it was connected to powerd) you should see you've hit _iohideventsystem_copy_event_from_virtual_service, now set breakpoints on vm_deallocate/mach_vm_deallocate

you'll see the error path get taken and the same address deallocated twice, first by _IOHIDUnserializeAndVMDeallocateWithTypeID and then by mach_msg_destroy because the MIG routine returned an error code.

You know how I keep going on about trivial variants; the last three bugs I report over the last week should be enough to make a full chain, from sandbox to backboardd (which can open hid clients) and to something like iap2d which has the entitlement to create hiduserdevices which you need to trigger the kernel queue integer overflow. All those bugs are basically trivial variants of issues I've reported over the last four years :-(




Found by: ianbeer