New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.
Issue 38
Starred by 5 users
Status: Fixed
Owner:
█ cevans@google.com
Email to this user bounced
Closed: Jan 2015



Sign in to add a comment
 OS X IOKit kernel code execution due to integer overflow in IOBluetoothDataQueue (root only)
Project Member Reported by ianbeer@google.com, Jun 23 2014 Back to list 
IOBluetoothFamily implements its own queuing primitive: IOBluetoothDataQueue

IOBluetoothHCIPacketLogUserClient is userclient type 1 of IOBluetoothHCIController. Its clientMemoryForType
method uses the type argument as a length and calls IOBluetoothDataQueue::withCapacity, which in turn calls
IOBluetoothDataQueue::initWithCapacity which uses the following code to calculate the buffer size to allocate:

(r14d is controlled size)

  lea     edi, [r14+100Bh] ; overflow
  and     edi, 0FFFFF000h
  mov     esi, 1000h
  call    _IOMallocAligned

Calling selector 0 will cause the kernel to enqueue data to the undersized queue. This selector is restricted to
root, so this doesn't actually get you an EoP on OS X hence Severity-None.
bluetooth_packet_log_integer_overflow.c
2.9 KB Download
Project Member Comment 1 by ianbeer@google.com, Jun 23 2014
Labels: Reported-2014-June-23 Id-607333405
Project Member Comment 2 by ianbeer@google.com, Aug 22 2014
Labels: Deadline-90
Comment 3 by cevans@google.com, Sep 30 2014
Labels: -Restrict-View-Commit -Reported-2014-June-23 Reported-2014-Jun-23 Deadline-Exceeded PublicOn-2014-Sep-30
Deadline exceeded - automatically derestricting

I wonder if this affects iOS / iPhone? An escalation of this nature might have some impact on iOS (even if it does not on OS X)
Comment 4 by jerem...@gmail.com, Dec 31 2014 
This doesn't really seem like a vulnerability to me.  More of a silly bug.  In any event, looks like it is fixed in Yosemite.
Project Member Comment 5 by ianbeer@google.com, Jan 1 2015
Status: Fixed
You are correct that this was fixed in Yosemite - I hadn't updated this bug as I didn't receive a direct reply to the report email but I'll update the labels now to reflect this.

The root requirement does make the severity of this issue more complex; remember though that OS X does have many services which are both within a sandbox *and* run as root. For example blued is one such service responsible for interaction with the bluetooth stack. Whilst there are known public workarounds to bypass kernel code signing as root (for example by using the AppleHWAccess user client) these may not work from a sandboxed root processes.

It was also possible that this particular IOKit class was used in iOS - at the time however I had no iOS setup to test that.
► Sign in to add a comment