EDB-ID: 44562 | Author: Google Security Research | Published: 2018-04-30 | CVE: CVE-2018-4206 | Type: Dos | Platform: Multiple | Aliases: N/A | Advisory/Source: Link | Tags: N/A | Vulnerable App: N/A | ReportCrash is the daemon responsible for making crash dumps of crashing userspace processes.
Most processes can talk to ReportCrash via their exception ports (either task or host level.)
You would normally never send a message yourself to ReportCrash but the kernel would do it
on your behalf when you crash. However using the task_get_exception_ports or host_get_exception_ports
MIG kernel methods you can get a send right to ReportCrash.
ReportCrash implements a mach_exc subsystem (2405) server and expects to receive
mach_exception_raise_state_identity messages. The handler for these messages is at +0x2b11 in 10.13.3.
The handler compares its euid with the sender's; if they are different it jumps straight to the error path:
__text:0000000100002BD5 cmp rbx, rax
__text:0000000100002BD8 mov r14d, 5
__text:0000000100002BDE jnz loc_100002DCF
__text:0000000100002DCF mov rbx, cs:_mach_task_self__ptr
__text:0000000100002DD6 mov edi, [rbx] ; task
__text:0000000100002DD8 mov rsi, qword ptr [rbp+name] ; name
__text:0000000100002DDC call _mach_port_deallocate
__text:0000000100002DE1 mov edi, [rbx] ; task
__text:0000000100002DE3 mov esi, r12d ; name
__text:0000000100002DE6 call _mach_port_deallocate
__text:0000000100002DEB mov rax, cs:___stack_chk_guard_ptr
__text:0000000100002DF2 mov rax, [rax]
__text:0000000100002DF5 cmp rax, [rbp+var_30]
__text:0000000100002DF9 jnz loc_10000314E
__text:0000000100002DFF mov eax, r14d
This error path drops a UREF on the task and thread port arguments then returns error code 5.
MIG will see this error and drop another UREF on the thread and port arguments. As detailed in
the mach_portal exploit [https://bugs.chromium.org/p/project-zero/issues/detail?id=959] such bugs can
be used to replace privileged port names leading to exploitable conditions.
Since this path will only be triggered if you can talk to a ReportCrash running with a different euid
a plausible exploitation scenario would be trying to pivot from code execution in a sandbox root process
to another one with more privileges (eg kextd on MacOS or amfid on iOS) going via ReportCrash (as ReportCrash
will get sent their task ports if you can crash them.)
This PoC demonstrates the bug by destroying ReportCrash's send right to logd; use a debugger or lsmp to see
what's happening.
Tested on MacOS 10.13.3 17D47
*/
// ianbeer
#if 0
MacOS/iOS ReportCrash mach port replacement due to failure to respect MIG ownership rules
ReportCrash is the daemon responsible for making crash dumps of crashing userspace processes.
Most processes can talk to ReportCrash via their exception ports (either task or host level.)
You would normally never send a message yourself to ReportCrash but the kernel would do it
on your behalf when you crash. However using the task_get_exception_ports or host_get_exception_ports
MIG kernel methods you can get a send right to ReportCrash.
ReportCrash implements a mach_exc subsystem (2405) server and expects to receive
mach_exception_raise_state_identity messages. The handler for these messages is at +0x2b11 in 10.13.3.
The handler compares its euid with the sender's; if they are different it jumps straight to the error path:
__text:0000000100002BD5 cmp rbx, rax
__text:0000000100002BD8 mov r14d, 5
__text:0000000100002BDE jnz loc_100002DCF
__text:0000000100002DCF mov rbx, cs:_mach_task_self__ptr
__text:0000000100002DD6 mov edi, [rbx] ; task
__text:0000000100002DD8 mov rsi, qword ptr [rbp+name] ; name
__text:0000000100002DDC call _mach_port_deallocate
__text:0000000100002DE1 mov edi, [rbx] ; task
__text:0000000100002DE3 mov esi, r12d ; name
__text:0000000100002DE6 call _mach_port_deallocate
__text:0000000100002DEB mov rax, cs:___stack_chk_guard_ptr
__text:0000000100002DF2 mov rax, [rax]
__text:0000000100002DF5 cmp rax, [rbp+var_30]
__text:0000000100002DF9 jnz loc_10000314E
__text:0000000100002DFF mov eax, r14d
This error path drops a UREF on the task and thread port arguments then returns error code 5.
MIG will see this error and drop another UREF on the thread and port arguments. As detailed in
the mach_portal exploit [https://bugs.chromium.org/p/project-zero/issues/detail?id=959] such bugs can
be used to replace privileged port names leading to exploitable conditions.
Since this path will only be triggered if you can talk to a ReportCrash running with a different euid
a plausible exploitation scenario would be trying to pivot from code execution in a sandbox root process
to another one with more privileges (eg kextd on MacOS or amfid on iOS) going via ReportCrash (as ReportCrash
will get sent their task ports if you can crash them.)
This PoC demonstrates the bug by destroying ReportCrash's send right to logd; use a debugger or lsmp to see
what's happening.
Tested on MacOS 10.13.3 17D47
build: cp /usr/include/mach/mach_exc.defs . && mig mach_exc.defs && clang -o rc rc.c mach_excUser.c
run: sudo ./rc
