Apple Mac OSX / iOS - Double-Delete IOHIDEventQueue::start Code Execution

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://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/39379.zip

#  0day.today [2018-02-17]  #