Source: https://code.google.com/p/google-security-research/issues/detail?id=542
The IOHIDLibUserClient allows us to create and manage IOHIDEventQueues corresponding to available HID devices.
Here is the ::start method, which can be reached via the IOHIDLibUserClient::_startQueue external method:
************ SNIP **************
void IOHIDEventQueue::start()
{
if ( _lock )
IOLockLock(_lock);
if ( _state & kHIDQueueStarted )
goto START_END;
if ( _currentEntrySize != _maxEntrySize ) <--- (a)
{
mach_port_t port = notifyMsg ? ((mach_msg_header_t *)notifyMsg)->msgh_remote_port : MACH_PORT_NULL;
// Free the existing queue data
if (dataQueue) { <-- (b)
IOFreeAligned(dataQueue, round_page_32(getQueueSize() + DATA_QUEUE_MEMORY_HEADER_SIZE));
}
if (_descriptor) {
_descriptor->release();
_descriptor = 0;
}
// init the queue again. This will allocate the appropriate data.
if ( !initWithEntries(_numEntries, _maxEntrySize) ) { (c) <----
goto START_END;
}
_currentEntrySize = _maxEntrySize;
// RY: since we are initing the queue, we should reset the port as well
if ( port )
setNotificationPort(port);
}
else if ( dataQueue )
{
dataQueue->head = 0;
dataQueue->tail = 0;
}
_state |= kHIDQueueStarted;
START_END:
if ( _lock )
IOLockUnlock(_lock);
}
************ SNIP **************
If _currentEntrySize is not equal to _maxEntrySize then the start method will attempt to reallocate a better-sized queue;
if dataQueue (a member of IODataQueue) is non-zero its free'd then initWithEntries is called with the new _maxEntrySize.
Note that the error path on failure here jumps straight to the end of the function, so it's up to initWithEntries to
clear dataQueue if it fails:
************ SNIP **************
Boolean IOHIDEventQueue::initWithEntries(UInt32 numEntries, UInt32 entrySize)
{
UInt32 size = numEntries*entrySize;
if ( size < MIN_HID_QUEUE_CAPACITY )
size = MIN_HID_QUEUE_CAPACITY;
return super::initWithCapacity(size);
}
************ SNIP **************
There's a possible overflow here; but there will be *many* possible overflows coming up and we need to overflow at the right one...
This calls through to IOSharedDataQueue::initWithCapacity
************ SNIP **************
Boolean IOSharedDataQueue::initWithCapacity(UInt32 size)
{
IODataQueueAppendix * appendix;
vm_size_t allocSize;
if (!super::init()) {
return false;
}
_reserved = (ExpansionData *)IOMalloc(sizeof(struct ExpansionData));
if (!_reserved) {
return false;
}
if (size > UINT32_MAX - DATA_QUEUE_MEMORY_HEADER_SIZE - DATA_QUEUE_MEMORY_APPENDIX_SIZE) {
return false;
}
allocSize = round_page(size + DATA_QUEUE_MEMORY_HEADER_SIZE + DATA_QUEUE_MEMORY_APPENDIX_SIZE);
if (allocSize < size) {
return false;
}
dataQueue = (IODataQueueMemory *)IOMallocAligned(allocSize, PAGE_SIZE);
************ SNIP **************
We need this function to fail on any of the first four conditions; if we reach the IOMallocAligned call
then dataQueue will either be set to a valid allocation (which is uninteresting) or set to NULL (also uninteresting.)
We probably can't fail the ::init() call nor the small IOMalloc. There are then two integer overflow checks;
the first will only fail if size (a UInt32 is greater than 0xfffffff4), and the second will be impossible to trigger on 64-bit since
round_pages will be checking for 64-bit overflow, and we want a cross-platform exploit!
Therefore, we have to reach the call to initWithCapacity with a size >= 0xfffffff4 (ie 12 possible values?)
Where do _maxEntrySize and _currentEntrySize come from?
When the queue is created they are both set to 0x20, and we can partially control _maxEntrySize by adding an new HIDElement to the queue.
_numEntries is a completely controlled dword.
So in order to reach the exploitable conditions we need to:
1) create a queue, specifying a value for _numEntries. This will allocate a queue (via initWithCapacity) of _numEntries*0x20; this allocation must succeed.
2) add an element to that queue with a *larger* size, such that _maxEntrySize is increased to NEW_MAX_SIZE.
3) stop the queue.
4) start the queue; at which point we will call IOHIDEventQueue::start. since _maxEntrySize is now larger this
will free dataQueue then call initWithEntries(_num_entries, NEW_MAX_SIZE). This has to fail in exactly the manner
described above such that dataQueue is a dangling pointer.
5) start the queue again, since _maxEntrySize is still != _currentEntrySize, this will call free dataQueue again!
The really tricky part here is coming up with the values for _numEntries and NEW_MAX_SIZE; the constraints are:
_numEntries is a dword
(_numEntries*0x20)%2^32 must be an allocatable size (ideally <0x10000000)
(_numEntries*NEW_MAX_SIZE)%2^32 must be >= 0xfffffff4
presumable NEW_MAX_SIZE is also reasonably limited by the HID descriptor parsing code, but I didn't look.
This really doesn't give you much leaway, but it is quite satisfiable :)
In this case I've chosen to create a "fake" hid device so that I can completely control NEW_MAX_SIZE, thus the PoC requires
root (as did the TAIG jailbreak which also messed with report descriptors.) However, this isn't actually a requirement to hit the bug; you'd just need to look through every single HID report descriptor on your system to find one with a suitable report size.
In this case, _numEntries of 0x3851eb85 leads to an initial queue size of (0x3851eb85*0x20)%2^32 = 0xa3d70a0
which is easily allocatable, and NEW_MAX_SIZE = 0x64 leads to: (0x3851eb85*0x64)%2^32 = 0xfffffff4
To run the PoC:
1) unzip and build the fake_hid code and run 'test -k' as root; this will create an IOHIDUserDevice whose
cookie=2 IOHIDElementPrivate report size is 0x64.
2) build and run this file as a regular user.
3) see double free crash.
There's actually nothing limiting this to a double free, you could go on indefinitely free'ing the same pointer.
As I said before, this bug doesn't actually require root but it's just *much* easier to repro with it!
Testing on: MacBookAir5,2 10.10.5 14F27
Guessing that this affects iOS too but haven't tested.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39379.zip
