Monorail Project: project-zero Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 5 users
Status: Fixed
Owner:
Email to this user bounced
Closed: Oct 2014



Sign in to add a comment
OS X IOKit kernel code execution due to controlled kmem_free size in IOSharedDataQueue
Project Member Reported by ianbeer@google.com, Jun 18 2014 Back to list
IOSharedDataQueue is used by OS X kernel drivers to implement a user/kernel queue in shared memory.

The memory which is mapped into userspace is represented by the variable-sized struct IODataQueueMemory:

typedef struct _IODataQueueMemory {
      UInt32 queueSize;
      volatile UInt32 head;
      volatile UInt32 tail;
      IODataQueueEntry queue[1];
} IODataQueueMemory;

This is allocated on the kernel heap with IOMallocAligned (the size is rounded up to the nearest page_size multiple.) This size is stored in the queueSize field.

Kernel code can call IOSharedDataQueue::getMemoryDescriptor to wrap these pages in an IOMemoryDescriptor which can then be mapped into the userspace task (via IOConnectMapMemory.)

When the IOSharedDataQueue is destructed its ::free method passes the queueSize to kmem_free, which simply removes the corresponding number of pages from the kernel_map. If userspace increased the value of the queueSize field this will remove more pages than were allocated - potentially removing other live allocations from the map.

This could be leveraged for code execution by, for example, forcing these free pages to be reallocated with controlled data before they are accessed.

[[ Note that due to the nature of this bug this PoC will crash in weird ways - break at IODataQueue::free to see the bad size]]
 
hidlib_bad_kmem_free.c
3.6 KB Download
Project Member Comment 1 by ianbeer@google.com, Jun 18 2014
Labels: Reported-2014-June-18 Id-607219940
Project Member Comment 2 by ianbeer@google.com, Jun 27 2014
Apple requested more details. I replied with another explanation of the bug and more information about how the PoC will kernel panic, and that any kernel panic will look strange depending on what happened to be in memory contiguous with the IODataQueueMemory. I asked for clarification as to whether they cannot reproduce the kernel panic at all or are just having trouble diagnosing it.
Project Member Comment 3 by ianbeer@google.com, Aug 22 2014
Labels: Deadline-90
Project Member Comment 4 by ianbeer@google.com, Sep 16 2014
Labels: -Restrict-View-Commit Deadline-Exceeded PublicOn-2014-September-16
Deadline exceeded - automatically derestricting
Project Member Comment 6 by ianbeer@google.com, Oct 2 2014
Status: Fixed
yeah, you're right, I'll fix that. Cheers. Apple haven't actually replied to this bug report at all but the PoC no longer works so I assume it's fixed... when I get a chance I'll take a proper look.
Project Member Comment 7 by scvitti@google.com, Jan 13 2015
Labels: -Reported-2014-June-18 Reported-2014-Jun-18
Sign in to add a comment