Posted by Ian Beer, Project Zero (2021-02-04)
Disclosure or Patch Date: 5 November 2020
Product: Apple iOS
Advisory: https://support.apple.com/en-us/HT211929
Affected Versions: iOS 14.1 and previous
First Patched Version: iOS 14.2
Issue/Bug Report: https://bugs.chromium.org/p/project-zero/issues/detail?id=2107
Patch CL: N/A
Bug-Introducing CL: N/A
Proof-of-Concept: N/A
Exploit Sample: N/A
Access to the exploit sample? Yes
Reporter(s): Ian Beer of Google Project Zero
Bug Class: Type Confusion
Vulnerability Details: A kernel type confusion between an ipc_port pointer and a host_notify_entry pointer due to failure to account for the semantics of IKOT_HOST_NOTIFY ports in turnstile code.
IKOT_HOST_NOTIFY ports have slightly unusual semantics: the host_request_notification method allows userspace to take a regular, userspace-owned mach port and set the kobject field to point to a host_notify_entry object. The kobject field is actually a member of a fairly large union (kdata) leading to plenty of opportunities for type confusions if kernel code doesn't account for the semantics of IKOT_HOST_NOTIFY ports (i.e., if the kernel code doesn't know that userspace-owned ports can suddenly become IKOT_HOST_NOTIFY ports.)
union {
ipc_kobject_t kobject;
ipc_kobject_label_t kolabel;
ipc_importance_task_t imp_task;
ipc_port_t sync_inheritor_port;
struct knote *sync_inheritor_knote;
struct turnstile *sync_inheritor_ts;
} kdata;
There have been type confusions here before; for example a type confusion between imp_task and kobject (via the IKOT_HOST_NOTIFY trick) was fixed in MacOS 10.10.
In this case the turnstiles code added around iOS 12 added the sync_inheritor_port field to the kdata union to indicate the destination port to which a new type of port called a special reply port had been sent. Through some mach port gymnastics it was possible to get the kernel to read a pointer to a host_notify_entry as a ipc_port pointer (via sync_inheritor_port) and then cause an out of bounds write.
Specifically: send a mach message to a destination port and attach the thread_special_reply_port as the msgh_local_port with a SEND_ONCE disposition.
The trick to make something bad happen is to set the MACH_SEND_SYNC_OVERRIDE flag when sending that message. This allows you to change the ip_sync_link_state value away from PORT_SYNC_LINK_ANY.
After sending that message, convert the thread's special_reply_port to a IKOT_HOST_NOTIFY via host_request_notification.
Then attempt to receive a message on that special_reply_port and you'll hit the type-confusion when ipc_port_adjust_special_reply_port_locked reads special_reply_port->ip_sync_inheritor_port expecting a valid port pointer, but actually finds a host_notify_entry pointer because the special_reply_port was converted to a host_notify port.
Is the exploit method known? Analysis is incomplete at this time.
Exploit method: There are some neat tricks to turn this into an arbitrary read/write; I haven't completed that analysis phase yet.
How do you think you would have found this bug? This bug could be seen as a variant of earlier issues involving this union; it could have been found via manual review if you were familiar with those earlier issues. Actually figuring out the conditions required to cause an exploitable type confusion are non-trivial, and I wouldn't expect a fuzzer to find them.
(Historical/present/future) context of bug:
Areas/approach for variant analysis: I would suggest auditing similar uses of complex unions.
Found variants: N/A
Structural improvements: The use of a union here seems unnecessary; the memory saving is negligible on modern systems. My suggestion would be to either add another memory to ipc_port which stores the current valid field of the kdata union, or break the union fields out into separate members.
Potential detection methods for similar 0-days:
Other references:
No comments:
Post a Comment