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