New issue
Advanced search Search tips

Issue 1658 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 18
Cc:



Sign in to add a comment

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

Project Member Reported by ianbeer@google.com, Sep 6

Issue description

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)
 
Project Member

Comment 1 by ianbeer@google.com, Sep 6

Labels: Reported-2018-Sept-7 Id-698767157
Project Member

Comment 2 by ianbeer@google.com, Sep 6

Labels: -Reported-2018-Sept-7 Reported-2018-Sep-7
Project Member

Comment 3 by ianbeer@google.com, Oct 18

Labels: -Restrict-View-Commit Fixed-2018-Sept-17
Status: Fixed (was: New)
This issue has been fixed in iOS 12/MacOS 10.14 but Apple have not assigned a CVE or mentioned it in their security bulletins. I suspect this was a dup with another researcher or Apple internal security since the fix was very fast, but I have no confirmation of this from Apple, nor have they publicly acknowledged the issue.

For a PoC see the deja-xnu project attached to p0  issue 1624  (https://bugs.chromium.org/p/project-zero/issues/detail?id=1624)

Note that on iOS this issue also affected the kernel. That is, there are cases where the kernel is making MIG requests to userspace daemons which reply with OOL or OOL_PORTS descriptors.


Sign in to add a comment