Apple XNU Kernel – Memory Corruption due to Integer Overflow in __offsetof Usage in posix_spawn on 32-bit Platforms
posix_spawn is a complex syscall which takes a lot of arguments from userspace. The third argument is a pointer to a further arguments descriptor in userspace with the following structure (on 32-bit): struct user32__posix_spawn_args_desc { uint32_t attr_size; /* size of attributes block */ uint32_t attrp; /* pointer to block */ uint32_t file_actions_size; /* size of file actions block */ uint32_t file_actions; /* pointer to block */ uint32_t port_actions_size; /* size of port actions block */ uint32_t port_actions; /* pointer to block */ uint32_t mac_extensions_size; uint32_t mac_extensions; uint32_t coal_info_size; uint32_t coal_info; uint32_t persona_info_size; uint32_t persona_info; } port_actions then points to another structure in userspace of this type: struct _posix_spawn_port_actions { int pspa_alloc; int pspa_count; _ps_port_action_t pspa_actions[]; } and finally _ps_port_action_t looks like this: struct _ps_port_action { pspa_t port_type; exception_mask_t mask; mach_port_name_t new_port; exception_behavior_t behavior; thread_state_flavor_t flavor; int which; } Note that pspa_actions is a zero-sized array. pspa_count is supposed to be the number of entries in this array. The following constraints are checked in posix_spawn in kern_exec.c: if (px_args.port_actions_size != 0) { /* Limit port_actions to one page of data */ if (px_args.port_actions_size < PS_PORT_ACTIONS_SIZE(1) || px_args.port_actions_size > PAGE_SIZE) { error = EINVAL; goto bad; PS_PORT_ACTIONS_SIZE is defined like this: #define PS_PORT_ACTIONS_SIZE(x) \ __offsetof(struct _posix_spawn_port_actions, pspa_actions[(x)]) if port_actions_size passes this then we reach the following code: MALLOC(px_spap, _posix_spawn_port_actions_t, px_args.port_actions_size, M_TEMP, M_WAITOK); if (px_spap == NULL) { error = ENOMEM; goto bad; } imgp->ip_px_spa = px_spap; if ((error = copyin(px_args.port_actions, px_spap, px_args.port_actions_size)) != 0) goto bad; This allocates a kernel heap buffer to hold the port_actions buffer and copies from userspace into it. The code then attempts to check whether the pspa_count valid is correct: /* Verify that the action count matches the struct size */ if (PS_PORT_ACTIONS_SIZE(px_spap->pspa_count) != px_args.port_actions_size) { error = EINVAL; goto bad; } There is an integer overflow here because offsetof is just simple arithmetic. With a carefully chosen value for pspa_count we can make it very large but when it's passed to the PS_PORT_ACTIONS_SIZE macro the result is equal to port_actions_size. Nothing bad has happened yet but we can now get pspa_count to be much larger than it should be. Later on we reach the following code: if (px_spap->pspa_count != 0 && is_adaptive) { portwatch_count = px_spap->pspa_count; MALLOC(portwatch_ports, ipc_port_t *, (sizeof(ipc_port_t) * portwatch_count), M_TEMP, M_WAITOK | M_ZERO); } else { portwatch_ports = NULL; } if ((error = exec_handle_port_actions(imgp, &portwatch_present, portwatch_ports)) != 0) We can cause another integer overflow here, sizeof(ipc_port_t) is 4 (on 32-bit) so with a carefully chosen value of pspa_count we can cause the integer overflow here and earlier too whilst still passing the checks. exec_handle_port_actions then uses portwatch ports like this: for (i = 0; i < pacts->pspa_count; i++) { act = &pacts->pspa_actions[i]; if (MACH_PORT_VALID(act->new_port)) { kr = ipc_object_copyin(get_task_ipcspace(current_task()), act->new_port, MACH_MSG_TYPE_COPY_SEND, (ipc_object_t *) &port); ... switch (act->port_type) { ... case PSPA_IMP_WATCHPORTS: if (portwatch_ports != NULL && IPC_PORT_VALID(port)) { *portwatch_present = TRUE; /* hold on to this till end of spawn */ portwatch_ports[i] = port; note that pspa_actions was allocated earlier also based on the result of an integer overflow. This means we can cause an OOB write to portwatch_ports only if we can successfully read suitable valid values OOB of pspa_actions. That's why this PoC first fills a kalloc.1024 buffer with suitable values before freeing it and then hoping that it will get reallocated as pspa_actions (but less thatn 1024 bytes will be written) such that we control what's read OOB and the ipc_object_copyin will succeed. This seems to be pretty reliable. You can use this to build a nice primitive of a heap overflow with pointers to ipc_port structures. I don't believe there are any iOS 11 32-bit iPod/iPhone/iPad/AppleTV devices but the new Apple Watch Series 3 is running essentially the same kernel but has a 32-bit CPU. This PoC is provided as an Apple watch app and has been tested on Apple Watch Series 3 (Watch3,2) running WatchOS 4.0.1. I also tested on an older 32-bit iOS 9 device. Apple Watch Series 3 now has its own LTE modem and can be used without an iPhone making it a suitably interesting target for exploitation by itself. Note that all the uses of offsetof in those posix_spawn macros are quite wrong, I think you might be able to get a kernel memory disclosure with one of them also on 64-bit platforms. The fix is to add correct bounds checking. Please also note that this really shouldn't be attack surface reachable from an app sandbox. The MAC hook in posix_spawn is very late and there's a *lot* of code which you can hit before it. Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/43325.zip |