The mach voucher subsystem fails to correctly handle spoofed no-more-senders messages. ipc_kobject_server will be called for mach messages sent to kernel-owned mach ports. If the msgh_id of the message can't be found in the mig_buckets hash table then this function calls ipc_kobject_notify. This is the same code path which would be taken for a real no-more-senders notification message but there's nothing stopping user-space from also just sending one. ipc_kobject_notify calls the correct notification method for the type of the KOBJECT associated with the port, and at this point there are also no locks held. ipc_voucher_notify calls ipc_voucher_release, again not taking any locks, which calls through to iv_release.
Opening userclient type 12 of IOSCSIPeripheralDeviceType00 leads to an exploitable kernel NULL dereference. This vulnerability was tested on OS X 10.11 ElCapitan (15a284) on MacBookAir5,2.
Kernel UaF with IOAccelDisplayPipeUserClient2 with spoofed no more senders notifications can lead to NULL derefs and NX traps. The exploit can be reproduced by running the iospoof_ig_4 program.
This exploit is a kernel UaF vulnerability with IOAccelMemoryInfoUserClient with spoofed no more senders notifications. The exploit can be reproduced by running the iospoof_ig_7 program. It was tested on ElCapitan 10.11 (15a284) on MacBookAir 5,2.
This exploit is a Use-After-Free vulnerability in the audit session port of the kernel. It is triggered by sending a spoofed no-more-senders notification to the audit session port. This causes the kernel to incorrectly account for the notification, leading to a Use-After-Free vulnerability.
IOBluetoothHCIUserClient uses an IOCommandGate to dispatch external methods; it passes a pointer to the structInput of the external method as arg0 and ::SimpleDispatchWL as the Action. It neither passes nor checks the size of that structInput, and SimpleDispatchWL goes on to read the field at +0x70 of the structInput. This can lead to an out-of-bounds read, as the code assumes the value hasn't changed.
The OS* data types (OSArray etc) are explicity not thread safe; they rely on their callers to implement the required locking to serialize all accesses and manipulations of them. By sending two spoofed no-more-senders notifications on two threads at the same time we can cause parallel calls to OSArray::removeObject with no locks which is unsafe. In this particular case you might see two threads both passing the index >= count check in OSArray::removeObject (when count = 1 and index = 0) but then both decrementing count leading to an OSArray with a count of 0xffffffff leading to memory corruption when trying to shift the array contents.
The hv_space lock group gets an extra ref dropped when you kill a process with an AppleHV userclient; one via IOService::terminateWorker calling the AppleHVClient::free method (which calls lck_rw_free on the lock group using the pointer hanging off the global _hv variable) and secondly via the hypervisor machine_thread_destroy callback (hv_callback_thread_destroy) which also calls lck_rw_free with a lock group pointer taken from _hv.
The field at IntelAccelerator+0xe60 is a pointer to a GSTContextKernel allocated in the ::gstqCreateInfoMethod. In the ::start method this field is initialized to NULL. The IGAccelDevice external method gst_configure (0x206) calls gstqConfigure which doesn't check whether the GSTContextKernel pointer is NULL, therefore by calling this external method before calling any others which allocate the GSTContextKernel we can cause a kernel NULL pointer dereference. The GSTContextKernel structure contains pointers, one of which eventually leads to control of a kernel virtual method call. This PoC will kernel panic calling 0xffff800041414141.
It turns out that the spoofed no-more-senders notification bug when applied to iokit objects was actually just a more complicated way to hit ::clientClose in parallel. We can in fact do this very simply by calling IOServiceClose on two threads. Like the spoofed notifications this leads to many bugs in many userclients, the exact nature of which depends on the semantics of the clientClose implementation.
Services By CQR