plutoo and I found this bug back in september of last year. Effectively this will grant ROP in an IOS usermode process which may then be further used to target the kernel. The vulnerability itself is a TOCTTOU race condition.
Initially the ioctlv handling of the IOS kernel contained a major design flaw, namely that the buffer address verification of the vectors happens in-place provided that we supply more than 8 vectors. This enables the PPC side to change the buffer address after its verification. Due to the nature of the bug exploitation requires the number of vectors passed in to be relatively large.
The bug was fixed with version 5.2.0 by adding a new field to the device context that limits the number of vectors, which is set to 8 by default and may be changed using syscall 0x2E if required.
The goal was to gain ROP under an IOS usermode process. For this we had to look for a device that did not check the number of vectors itself. It turns out that “/dev/im” provides us with some very handy ioctlv handlers, namely:
Thus this allows us to write 8 bytes worth of data to an address we eventually control. With this arbitrary write we can now carefully setup a ROP stack inside the AUXIL process, overwrite the return address of one of the devices’ handler threads and get the handler thread to return by overwriting the corresponding message queue handle.
Note that this is by no means the only way to exploit this flaw – interested readers are encouraged to let us know about any alternative strategies they might come up with.