CVE-2016-4625 Detail

CVE-2016-4625

Score / Severity

7.8

High

CVE Descriptions

Use-after-free vulnerability in IOSurface in Apple OS X before 10.11.6 allows local users to gain privileges via unspecified vectors.

CVE Informations

Related Weaknesses

CWE-ID	Weakness Name	Source
CWE-416	Use After Free The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.

Metrics

Metrics	Score	Severity	CVSS Vector	Source
V3.0	7.8	HIGH	CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H More informations Base: Exploitabilty Metrics The Exploitability metrics reflect the characteristics of the thing that is vulnerable, which we refer to formally as the vulnerable component. Attack Vector This metric reflects the context by which vulnerability exploitation is possible. Local A vulnerability exploitable with Local access means that the vulnerable component is not bound to the network stack, and the attacker's path is via read/write/execute capabilities. In some cases, the attacker may be logged in locally in order to exploit the vulnerability, otherwise, she may rely on User Interaction to execute a malicious file. Attack Complexity This metric describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability. Low Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component. Privileges Required This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability. Low The attacker is authorized with (i.e. requires) privileges that provide basic user capabilities that could normally affect only settings and files owned by a user. Alternatively, an attacker with Low privileges may have the ability to cause an impact only to non-sensitive resources. User Interaction This metric captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component. None The vulnerable system can be exploited without interaction from any user. Base: Scope Metrics An important property captured by CVSS v3.0 is the ability for a vulnerability in one software component to impact resources beyond its means, or privileges. Scope Formally, Scope refers to the collection of privileges defined by a computing authority (e.g. an application, an operating system, or a sandbox environment) when granting access to computing resources (e.g. files, CPU, memory, etc). These privileges are assigned based on some method of identification and authorization. In some cases, the authorization may be simple or loosely controlled based upon predefined rules or standards. For example, in the case of Ethernet traffic sent to a network switch, the switch accepts traffic that arrives on its ports and is an authority that controls the traffic flow to other switch ports. Unchanged An exploited vulnerability can only affect resources managed by the same authority. In this case the vulnerable component and the impacted component are the same. Base: Impact Metrics The Impact metrics refer to the properties of the impacted component. Confidentiality Impact This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability. High There is total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server. Integrity Impact This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. High There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component. Availability Impact This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. High There is total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable). Temporal Metrics The Temporal metrics measure the current state of exploit techniques or code availability, the existence of any patches or workarounds, or the confidence that one has in the description of a vulnerability. Environmental Metrics	[email protected]
V2	7.2		AV:L/AC:L/Au:N/C:C/I:C/A:C	[email protected]

EPSS

EPSS is a scoring model that predicts the likelihood of a vulnerability being exploited.

EPSS Score

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.

EPSS Percentile

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.

EPSS First.org

Exploit information

Exploit Database EDB-ID : 40669

Publication date : 2016-10-30 23h00 +00:00
Author : Google Security Research
EDB Verified : Yes

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

Exploit Database EDB-ID : 40653

Publication date : 2016-10-30 23h00 +00:00
Author : Google Security Research
EDB Verified : Yes

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=831 IOSurfaceRootUserClient stores a task struct pointer (passed in via IOServiceOpen) in the field at +0xf0 without taking a reference. By killing the corrisponding task we can free this pointer leaving the user client with a dangling pointer. We can get this pointer used by calling the create_surface_fast_path external method which will try to read and use the memory map off of the free'd task struct. This bug could be leveraged for kernel memory corruption and is reachable from interesting sandboxes including safari and chrome. build: clang -o surfaceroot_uaf surfaceroot_uaf.c -framework IOKit You should set gzalloc_min=1024 gzalloc_max=2048 or similar to actually fault on the UaF - otherwise you might see some weird panics! tested on OS X 10.11.5 (15F34) on MacBookAir5,2 ##################################### another PoC for "task_t considered harmful" since 10.11.6 blocks us from creating userclients with other task's task ports this time we create an IOSurface in the child and send back a send right to that IOSurface to the parent (rather than sending the child's task port.) The child then execs a suid-root binary which blocks on stderr and the parent creates an IOSurface which maps any (writable?) page of the euid-0 process into theirs. Overwrite a function pointer and win. No race conditions because the task struct pointer is on the kernel heap, not the stack. Proofs of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40653.zip