Twenty Year Anniversary

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

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

November 2018

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2018 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close