what you don't know can hurt you

iOS / macOS MIG Sandbox Escape

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

iOS and macOS suffer from sandbox escape vulnerabilities due to MIG failing to use correct out-of-line descriptor lengths when parsing reply messages.

tags | advisory, vulnerability
systems | ios
MD5 | 4f22a8f810b85991d35e76ab7b9861b4

iOS / macOS MIG Sandbox Escape

Change Mirror Download
iOS/MacOS sandbox escapes due to MIG failing to use correct out-of-line descriptor lengths when parsing reply messages 

There are plenty of situations on iOS and MacOS where a MIG client is more privileged than the server it is talking to.

In that situation bugs in the MIG client code (parsing replies to MIG requests) become an attack surface. One example might be backboardd on iOS, which has clients with more powerful and dangerous entitlements than itself (eg to open particular userclients.)

The MIG code generator fails to check that the size fields in ool and ool_port descriptors in reply messages actually match the size in the message body, which is the one returned to the client code. This means that client code will see the wrong size for these regions, which is highly likely to lead to bugs, as the client will have to vm_deallocate that memory and will use an invalid size.

These issues can be seen by running the mig tool which ships with XCode and inspecting the code they generate for parsing replies.

These issues can also be dynamically observed by debugging a client of backboardd (hidd on MacOS) and modifying the payload (not headers or descriptors) of the messages. For example, setting a breakpoint in io_hideventsystem_copy_matching_services after it has received a reply we can see the following message:

0x7ffeefbff278: 0x80001200 0x0000004c 0x00000000 0x00000607
0x7ffeefbff288: 0x00000000 0x000111d5 0x00000002 0x000f7000
0x7ffeefbff298: 0x00000001 0x01000101 0x0000002c 0x000f6000
0x7ffeefbff2a8: 0x00000001 0x01000101 0x000000a3 0x00000000
0x7ffeefbff2b8: 0x00000001 0x0000002c 0x000000a3

This message contains two OOL descriptors, with lengths 0x2c and 0xa3. However mig doesn't use the trusted lengths (set by the kernel) in the descriptors, but instead only the untrusted (set by the sender) lengths in the payload, here at offsets +0x44 and +0x48.

By modifying those fields you can observe that the client code is using the invalid lengths.

Tested on MacOS 10.13.6 (17G65)

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