CVE-2016-1757 : Detail

The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.

The percentile is used to rank CVE according to their EPSS score. For example, a CVE in the 95th percentile according to its EPSS score is more likely to be exploited than 95% of other CVE. Thus, the percentile is used to compare the EPSS score of a CVE with that of other CVE.

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=837 TL;DR you cannot hold or use a task struct pointer and expect the euid of that task to stay the same. Many many places in the kernel do this and there are a great many very exploitable bugs as a result. ******** task_t is just a typedef for a task struct *. It's the abstraction level which represents a whole task comprised of threads and a virtual memory map. task_t's have a corrisponding mach port type (IKOT_TASK) known as a task port. The task port structure in the kernel has a pointer to the task struct which it represents. If you have send rights to a task port then you have control over its VM and, via task_threads, its threads. When a suid-root binary is executed the kernel invalidates the old task and thread port structures setting their object pointers to NULL and allocating new ports instead. CVE-2016-1757 was a race condition concerning the order in which those port structures were invalidated during the exec operation. Although the issues I will describe in this bug report may seem similar is is a completely different, and far worse, bug class. ~~~~~~~~~ When a suid binary is executed it's true that the task's old task and thread ports get invalidated, however, the task struct itself stays the same. There's no fork and no creation of a new task. This means that any pointers to that task struct now point to the task struct of an euid 0 process. There are lots of IOKit drivers which save task struct pointers as members; see my recent bug reports for some examples. In those cases I reported there was another bug, namely that they weren't taking a reference on the task struct meaning that if we killed the corrisponding task and then forked and exec'ed a suid root binary we could get the IOKit object to interact via the task struct pointer with the VM of a euid 0 process. (You could also break out of a sandbox by forcing launchd to spawn a new service binary which would reuse the free'd task struct.) However, looking more closely, even if those IOKit drivers *do* take a reference on the task struct it doesn't matter! (at least not when there are suid binaries around.) Just because the userspace client of the user client had send rights to a task port at time A when it passed that task port to IOKit doesn't mean that it still has send rights to it when the IOKit driver actually uses the task struct pointer... In the case of IOSurface this lets us trivially map any RW area of virtual memory in an euid 0 process into ours and write to it. (See the other exploit I sent for that IOSurface bug.) There are a large number of IOKit drivers which do this (storing task struct pointers) and then either use the to manipulate userspace VM (eg IOAcceleratorFamily2, IOThunderboltFamily, IOSurface) or rely on that task struct pointer to perform authorization checks like the code in IOHIDFamily. Another interesting case to consider are task struct pointers on the stack. in the MIG files for the user/kernel interface task ports are subject to the following intran: type task_t = mach_port_t #if KERNEL_SERVER intran: task_t convert_port_to_task(mach_port_t) where convert_port_to_task is: task_t convert_port_to_task( ipc_port_t port) { task_t task = TASK_NULL; if (IP_VALID(port)) { ip_lock(port); if ( ip_active(port) && ip_kotype(port) == IKOT_TASK ) { task = (task_t)port->ip_kobject; assert(task != TASK_NULL); task_reference_internal(task); } ip_unlock(port); } return (task); } This converts the task port into the corrisponding task struct pointer. It takes a reference on the task struct but that only makes sure that it doesn't get free'd, not that its euid doesn't change as the result of the exec of an suid root binary. As soon as that port lock is dropped the task could exec a suid-root binary and although this task port would no longer be valid that task struct pointer would remain valid. This leads to a huge number of interesting race conditions. Grep the source for all .defs files which take a task_t to find them all ;-) In this exploit PoC I'll target perhaps the most interesting one: task_threads. Let's look at how task_threads actually works, including the kernel code which is generated by MiG: In task_server.c (an autogenerated file, build XNU first if you can't find this file) : target_task = convert_port_to_task(In0P->Head.msgh_request_port); RetCode = task_threads(target_task, (thread_act_array_t *)&(OutP->act_list.address), &OutP->act_listCnt); task_deallocate(target_task); This gives us back the task struct from the task port then calls task_threads: (unimportant bits removed) task_threads( task_t task, thread_act_array_t *threads_out, mach_msg_type_number_t *count) { ... for (thread = (thread_t)queue_first(&task->threads); i < actual; ++i, thread = (thread_t)queue_next(&thread->task_threads)) { thread_reference_internal(thread); thread_list[j++] = thread; } ... for (i = 0; i < actual; ++i) ((ipc_port_t *) thread_list)[i] = convert_thread_to_port(thread_list[i]); } ... } task_threads uses the task struct pointer to iterate through the list of threads, then creates send rights to them which get sent back to user space. There are a few locks taken and dropped in here but they're irrelevant. What happens if that task is exec-ing a suid root binary at the same time? The relevant parts of the exec code are these two points in ipc_task_reset and ipc_thread_reset: void ipc_task_reset( task_t task) { ipc_port_t old_kport, new_kport; ipc_port_t old_sself; ipc_port_t old_exc_actions[EXC_TYPES_COUNT]; int i; new_kport = ipc_port_alloc_kernel(); if (new_kport == IP_NULL) panic("ipc_task_reset"); itk_lock(task); old_kport = task->itk_self; if (old_kport == IP_NULL) { itk_unlock(task); ipc_port_dealloc_kernel(new_kport); return; } task->itk_self = new_kport; old_sself = task->itk_sself; task->itk_sself = ipc_port_make_send(new_kport); ipc_kobject_set(old_kport, IKO_NULL, IKOT_NONE); <-- point (1) ... then calls: ipc_thread_reset( thread_t thread) { ipc_port_t old_kport, new_kport; ipc_port_t old_sself; ipc_port_t old_exc_actions[EXC_TYPES_COUNT]; boolean_t has_old_exc_actions = FALSE; int i; new_kport = ipc_port_alloc_kernel(); if (new_kport == IP_NULL) panic("ipc_task_reset"); thread_mtx_lock(thread); old_kport = thread->ith_self; if (old_kport == IP_NULL) { thread_mtx_unlock(thread); ipc_port_dealloc_kernel(new_kport); return; } thread->ith_self = new_kport; <-- point (2) Point (1) clears out the task struct pointer from the old task port and allocates a new port for the task. Point (2) does the same for the thread port. Let's call the process which is doing the exec process B and the process doing task_threads() process A and imagine the following interleaving of execution: Process A: target_task = convert_port_to_task(In0P->Head.msgh_request_port); // gets pointer to process B's task struct Process B: ipc_kobject_set(old_kport, IKO_NULL, IKOT_NONE); // process B invalidates the old task port so that it no longer has a task struct pointer Process B: thread->ith_self = new_kport // process B allocates new thread ports and sets them up Process A: ((ipc_port_t *) thread_list)[i] = convert_thread_to_port(thread_list[i]); // process A reads and converts the *new* thread port objects! Note that the fundamental issue here isn't this particular race condition but the fact that a task struct pointer can just never ever be relied on to have the same euid as when you first got hold of it. ~~~~~~~~~~~~~~~ Exploit: This PoC exploits exactly this race condition to get a thread port for an euid 0 process. Since we've execd it I just stick a ret-slide followed by a small ROP payload on the actual stack at exec time then use the thread port to set RIP to a gadget which does a large add rsp, X and pop's a shell :) just run it for a while, it's quite a tight race window but it will work! (try a few in parallel) tested on OS X 10.11.5 (15F34) on MacBookAir5,2 ###################################### A faster exploit which also defeats the mitigations shipped in MacOS 10.12. Should work for all kernel versions <= 10.12 ###################################### Fixed: https://support.apple.com/en-us/HT207275 Disclosure timeline: 2016-06-02 - Ian Beer reports "task_t considered harmful issue" to Apple 2016-06-30 - Apple requests 60 day disclosure extension. 2016-07-12 - Project Zero declines disclosure extension request. 2016-07-19 - Meeting with Apple to discuss disclosure timeline. 2016-07-21 - Followup meeting with Apple to discuss disclosure timeline. 2016-08-10 - Meeting with Apple to discuss proposed fix and disclosure timeline. 2016-08-15 - Project Zero confirms publication date will be September 21, Apple acknowledges. 2016-08-29 - Meeting with Apple to discuss technical details of (1) "short-term mitigation" that will be shipped within disclosure deadline, and (2) "long-term fix" that will be shipped after the disclosure deadline. 2016-09-13 - Apple release the "short-term mitigation" for iOS 10 2016-09-13 - Apple requests a restriction on disclosed technical details to only those parts of the issue covered by the short-term mitigation. 2016-09-14 - Project Zero confirms that it will disclose full details without restriction. 2016-09-16 - Apple repeats request to withhold details from the disclosure, Project Zero confirms it will disclose full details. 2016-09-17 - Apple requests that Project Zero delay disclosure until a security update in October. 2016-09-18 - Apple's senior leadership contacts Google's senior leadership to request that Project Zero delay disclosure of the task_t issue 2016-09-19 - Google grants a 5 week flexible disclosure extension. 2016-09-20 - Apple release a "short-term mitigation" for the task_t issue for MacOS 10.12 2016-09-21 - Planned publication date passes. 2016-10-03 - Apple publicly release long-term fix for the task_t issue in MacOS beta release version 10.12.1 beta 3. 2016-10-24 - Apple release MacOS version 10.12.1 2016-10-25 - Disclosure date of "task_t considered harmful" Project Zero remains committed to a 90-day disclosure window, and will continue to apply disclosure deadlines on all of our vulnerability research findings. A 14 day grace extension is available for cases where a patch is expected shortly after the 90-day time window. Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40669.zip

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=676 tl;dr The code responsible for loading a suid-binary following a call to the execve syscall invalidates the task port after first swapping the new vm_map into the old task object leaving a short race window where we can manipulate the memory of the euid(0) process before the old task port is destroyed. ****************** __mac_execve calls exec_activate_image which calls exec_mach_imgact via the image activator table execsw. If we were called from a regular execve (not after a vfork or via posix_spawn) then this calls load_machfile with a NULL map argument indicating to load_machfile that it should create a new vm_map for this process: if (new_map == VM_MAP_NULL) { create_map = TRUE; old_task = current_task(); } it then creates a new pmap and wraps that in a vm_map, but doesn't yet assign it to the task: pmap = pmap_create(get_task_ledger(ledger_task), (vm_map_size_t) 0, ((imgp->ip_flags & IMGPF_IS_64BIT) != 0)); pal_switch_pmap(thread, pmap, imgp->ip_flags & IMGPF_IS_64BIT); map = vm_map_create(pmap, 0, vm_compute_max_offset(((imgp->ip_flags & IMGPF_IS_64BIT) == IMGPF_IS_64BIT)), TRUE) the code then goes ahead and does the actual load of the binary into that vm_map: lret = parse_machfile(vp, map, thread, header, file_offset, macho_size, 0, (int64_t)aslr_offset, (int64_t)dyld_aslr_offset, result); if the load was successful then that new map will we swapped with the task's current map so that the task now has the vm for the new binary: old_map = swap_task_map(old_task, thread, map, !spawn); vm_map_t swap_task_map(task_t task, thread_t thread, vm_map_t map, boolean_t doswitch) { vm_map_t old_map; if (task != thread->task) panic("swap_task_map"); task_lock(task); mp_disable_preemption(); old_map = task->map; thread->map = task->map = map; we then return from load_machfile back to exec_mach_imgact: lret = load_machfile(imgp, mach_header, thread, map, &load_result); if (lret != LOAD_SUCCESS) { error = load_return_to_errno(lret); goto badtoolate; } ... error = exec_handle_sugid(imgp); after dealing with stuff like CLOEXEC fds we call exec_handle_sugid. If this is indeed an exec of a suid binary then we reach here before actually setting the euid: * Have mach reset the task and thread ports. * We don't want anyone who had the ports before * a setuid exec to be able to access/control the * task/thread after. ipc_task_reset(p->task); ipc_thread_reset((imgp->ip_new_thread != NULL) ? imgp->ip_new_thread : current_thread()); As this comment points out, it probably is quite a good idea to reset the thread, task and exception ports, and that's exactly what they do: ... ipc_port_dealloc_kernel(old_kport); etc for the ports ... The problem is that between the call to swap_task_map and ipc_port_dealloc_kernel the old task port is still valid, even though the task isn't running. This means that we can use the mach_vm_* API's to manipulate the task's new vm_map in the interval between those two calls. This window is long enough for us to easily find the load address of the suid-root binary, change its page protections and overwrite its code with shellcode. This PoC demonstrates this issue by targetting the /usr/sbin/traceroute6 binary which is suid-root. Everything is tested on OS X El Capitan 10.11.2. In our parent process we register a port with launchd and fork a child. This child sends us back its task port, and once we ack that we've got its task port it execve's the suid-root binary. In the parent process we use mach_vm_region to work out when the task's map gets switched, which also convieniently tells us the target binary's load address. We then mach_vm_protect the page containing the binary entrypoint to be rwx and use mach_vm_write to overwrite it with some shellcode which execve's /bin/zsh (because bash drops privs) try running id in the shell and note your euid. Everything is quite hardcoded for the exact version of traceroute6 on 10.11.2 but it would be easy to make this into a very universal priv-esc :) Note that the race window is still quite tight so you may have to try a few times. Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39595.zip

Source: https://github.com/gdbinit/mach_race Mach Race OS X Local Privilege Escalation Exploit (c) fG! 2015, 2016, [email protected] - https://reverse.put.as A SUID, SIP, and binary entitlements universal OS X exploit (CVE-2016-1757). Usage against a SUID binary: ./mach_race_server /bin/ps _compat_mode for i in seq 0 1000000; do ./mach_race_client /bin/ps; done Against an entitled binary to bypass SIP: ./mach_race_server /System/Library/PrivateFrameworks/PackageKit.framework/Versions/A/Resources/system_shove _geteuid for i in seq 0 1000000; do ./mach_race_client /System/Library/PrivateFrameworks/PackageKit.framework/Versions/A/Resources/system_shove; done Note: because the service name is not modified you can't chain this exploit from user to root and then use it to bypass SIP since bootstrap_register2 will fail the second time (service is already registered with launchd from the first run). The solution is to add a parameter to use a different service name for example. Note2: there's no need to make this into two separate apps, a single binary works, you just need to fork a server and client. References: https://reverse.put.as/wp-content/uploads/2016/04/SyScan360_SG_2016_-_Memory_Corruption_is_for_wussies.pdf http://googleprojectzero.blogspot.pt/2016/03/race-you-to-kernel.html Tested against Mavericks 10.10.5, Yosemite 10.10.5, El Capitan 10.11.2 and 10.11.3. Fixed in El Capitan 10.11.4. Should work with all OS X versions (depends if bootstrap_register2 exists on older versions). Alternative implementation with bootstrap_create_server possible for older versions. Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39741.zip