what you don't know can hurt you

iOS / macOS MIG Object Lifetime Semantics Sandbox Escape

iOS / macOS MIG Object Lifetime Semantics Sandbox Escape
Posted Oct 19, 2018
Authored by Google Security Research, ianbeer

iOS and macOS suffer from a sandbox escape vulnerability due to failure to comply with MIG object lifetime semantics in the iohideventsystem_client subsystem.

tags | advisory
systems | apple
MD5 | b9de50e80a2ea80f7f9468bd16b597e3

iOS / macOS MIG Object Lifetime Semantics Sandbox Escape

Change Mirror Download
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:


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
-> 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


RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

April 2020

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    60 Files
  • 2
    Apr 2nd
    20 Files
  • 3
    Apr 3rd
    15 Files
  • 4
    Apr 4th
    5 Files
  • 5
    Apr 5th
    5 Files
  • 6
    Apr 6th
    27 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    0 Files
  • 9
    Apr 9th
    0 Files
  • 10
    Apr 10th
    0 Files
  • 11
    Apr 11th
    0 Files
  • 12
    Apr 12th
    0 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    0 Files
  • 16
    Apr 16th
    0 Files
  • 17
    Apr 17th
    0 Files
  • 18
    Apr 18th
    0 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2016 Packet Storm. All rights reserved.

Security Services
Hosting By