|
|
Lack of error checking leads to reference count leak and OS X/iOS kernel UaF in _kernelrpc_mach_port_insert_right_trap | |||
| Project Member Reported by ianbeer@google.com, Sep 13 2016 | Back to list | |||
The previous ref count overflow bugs were all kinda slow because they were quite deep in kernel code,
a lot of mach message and MIG code had to run for each leak.
There are a handful of mach operations which have their own fast-path syscalls (mach traps.)
One of these is _kernelrpc_mach_port_insert_right_trap which lets us create a new mach
port name in our process from a port we already have. Here's the code:
int
_kernelrpc_mach_port_insert_right_trap(struct _kernelrpc_mach_port_insert_right_args *args)
{
task_t task = port_name_to_task(args->target);
ipc_port_t port;
mach_msg_type_name_t disp;
int rv = MACH_SEND_INVALID_DEST;
if (task != current_task())
goto done;
rv = ipc_object_copyin(task->itk_space, args->poly, args->polyPoly,
(ipc_object_t *)&port);
if (rv != KERN_SUCCESS)
goto done;
disp = (args->polyPoly);
rv = mach_port_insert_right(task->itk_space, args->name, port, disp);
done:
if (task)
task_deallocate(task);
return (rv);
}
ipc_object_copyin will look up the args->poly name (with the args->polyPoly rights)
in the current process's mach port namespace and return an ipc_port_t pointer in port.
If ipc_object_copyin is successful it takes a ref on the port and returns that ref to the caller.
mach_port_insert_right will consume that reference but *only* if it succeeds. If it fails then
no reference is consumed and we can leak one because _kernelrpc_mach_port_insert_right_trap
doesn't handle the failure case.
it's easy to force mach_port_insert_right to fail by specifying an invalid name for the new
right (eg MACH_PORT_NULL.)
This allows you to overflow the reference count of the port and cause a kernel UaF in about 20
minutes using a single thread.
Project Member
Comment 1
by
ianbeer@google.com,
Sep 13 2016
,
Sep 15 2016
,
Oct 8 2016
LPE exploit for the kernel ipc_port_t reference leak bug I wanted to explore some more interesting exploit primitives I could build with this bug. One idea I had was to turn a send right for a mach port into a receive right for that port. We can do this by using the reference count leak to cause a port for which we have a send right to be freed (leaving a dangling ipc_object pointer in our ports table and that of any other process which had a send right) and forcing the memory to be reallocated with a new port for which we hold a receive right. We could for example target a userspace IPC service and replace a send right we've looked up via launchd with a receive right allowing us to impersonate the service to other clients. Another approach is to target the send rights we can get hold of for kernel-owned ports. In this case whilst userspace does still communicate by sending messages the kernel doesn't actually enqueue those messages; if a port is owned by the kernel then the send path is short-circuited and the MIG endpoint is called directly. Those kernel-owned receive rights are however still ports and we can free them using the bug; if we can then get that memory reused as a port for which we hold a receive right we can end up impersonating the kernel to other processes! Lots of kernel MIG apis take a task port as an argument; if we can manage to impersonate one of these services we can get other processes to send us their task ports and thus gain complete control over them. io_service_open_extended is a MIG api on an IOService port. Interestingly we can get a send right to any IOService from any sandbox as there are no MAC checks to get an IOService, only to get one of its IOUserClients (or query/manipulate the registry entries.) The io_service_open_extended message will be sent to the IOService port and the message contains the sender's task port as the owningTask parameter :) For this PoC expoit I've chosen to target IOBluetoothHCIController because we can control when this will be opened by talking to the com.apple.bluetoothaudiod - more exactly when that daemon is started it will call IOServiceOpen. We can force the daemon to restart by triggering a NULL pointer deref due to insufficient error checking when it parses XPC messages. This doesn't require bluetooth to be enabled. Putting this all together the flow of the exploit looks like this: * get a send right to the IOBluetoothHCIController IOService * overflow the reference count of that ipc_port to 0 and free it * allocate many new receive rights to reuse the freed ipc_port * add the new receive rights to a port set to simplify receiving messages * crash bluetoothaudiod forcing it to restart * bluetoothaudiod will get a send right to what it thinks is the IOBluetoothHCIController IOService * bluetoothaudiod will send its task port to the IOService * the task port is actually sent to us as we have the receive right * we use the task port to inject a new thread into bluetoothsudiod which execs /bin/bash -c COMMAND Tested on MacOS 10.12 16a323 The technique should work exactly the same on iOS to get a task port for another process from the app sandbox.
,
Dec 22 2016
Fixed in MacOS 10.12.2: https://support.apple.com/en-us/HT207423 Fixed in iOS 10.2: https://support.apple.com/en-us/HT207422 |
||||
| ► Sign in to add a comment | ||||
