exploit the possibilities

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:

February 2019

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

Top Authors In Last 30 Days

File Tags


packet storm

© 2019 Packet Storm. All rights reserved.

Security Services
Hosting By