4
edits
Changes
Jump to navigation
Jump to search
Line 47:
Line 47: + + + + + + + + + + + + + + + +
uhshax is real
This flaw technically is in the kernel, but it can be used to exploit a usermode module.
This flaw technically is in the kernel, but it can be used to exploit a usermode module.
It allows changing an ioctlv vector buffer address entry after it has been validated by the kernel. Any module not checking the number of ioctlv vectors is vulnerable. More information [https://nwert.wordpress.com/2016/05/03/ioctlvhax/ here].
It allows changing an ioctlv vector buffer address entry after it has been validated by the kernel. Any module not checking the number of ioctlv vectors is vulnerable. More information [https://nwert.wordpress.com/2016/05/03/ioctlvhax/ here].
===IOS-USB bad array index check (uhshax)===
'''Present in system versions''': 1.0.0-5.5.1
'''Publicly exploited''': No
'''Discovered by''': Hykem
IOS-USB manages UHS (USB host stack) and exposes it via the node /dev/uhs/0. This node can be "talked" to from PPC userspace by issuing ioctl commands.
The last two ioctl commands (0x12 and 0x13 in firmware versions 2.x.x, 0x13 and 0x14 in firmware versions 3.x.x and 4.x.x, 0x14 and 0x15 in firmware versions 5.x.x) are responsible for activating and deactivating (respectively) the root hubs which are managed in internal structures inside IOS-USB.
The single parameter that is passed to these ioctl commands is the root hub number which should only be 0 or 1. IOS-USB uses this number directly as an index for the internal root hub structures' array, but it doesn't check it properly (if index <= 2, proceed normally).
Passing the index value 2 results in an useless array index overflow, but passing a negative value allows to redirect the array into a userspace buffer we control.
The ioctl command responsible for activating a root hub (0x12, 0x13 or 0x14) registers two new IOS-BSP entities (CtrlProp and CtrlChicken) that become tied to the root hub. Attempting to exploit this particular ioctl command always results in a uncontrollable memory write (the written data comes from IOS-BSP and cannot be changed).
However, the ioctl command responsible for deactivating a root hub can be exploited by carefully crafting a buffer that mimicks a root hub structure. With it, we can eventually achieve a write-what-where primitive, overwrite the return address of the IOS-USB's thread responsible for handling the ioctl commands (__uhsBackgroundThread) and achieve ROP inside IOS-USB.
This exploit can be used to build a ROP chain that calls the IOS_CreateThread system call and exploit the IOSU kernel. However, in firmware 5.5.1 a new check was added to the system call handler that verifies if the calling thread's stack pointer is valid.
In order to sucessfully make use of this exploit chain in firmware 5.5.1 one must be sure to build a small enough ROP chain that allows calling a system call before the thread's stack pointer goes past the stack top address.
==IOSU kernel exploits==
==IOSU kernel exploits==