Wii U system flaws

PPC userspace exploits

RenderArena use-after-free

Present in system versions: 2.0.0-5.1.0

Publicly exploited: Yes (libwiiu)

Discovered by: libwiiu team (Marionumber1, TheKit, Hykem, Relys and Mathew_Wi)

An iframe is removed from its parent in a beforeload event and freed, but accessed for a vtable call later. Using Javascript, a vtable pointer is sprayed, occupying the frame's previous memory. A forged vtable referred to by the pointer is also sprayed. When WebKit attempts the virtual call, it goes to the forged vtable, which starts a ROP chain. More information here.

JSStringJoiner heap overflow

Present in system versions: 5.1.1-5.3.2 (possibly older versions, too)

Publicly exploited: Yes (libwiiu, 5.3.2 only)

Discovered by: libwiiu team (Marionumber1, Hykem and Mathew_Wi)

When joining an array of strings, the lengths of the strings are summed to calculate the needed storage space. This summation is vulnerable to an integer overflow, which enables a heap overflow. As a result, a sprayed value from Javascript ends up as a vtable pointer, which can be used with a forged vtable to start a ROP chain. More information here.

Stagefright ‘stsc’(?) MP4 atom integer overflow

Present in system versions: 5.4.0-5.5.0 (possibly older versions, too)

Publicly exploited: Yes

Discovered by: zhuowei, Marionumber1 and Mathew_Wi

Documented libstagefright MP4 integer overflow.

Stagefright ‘tx3g’ MP4 atom integer overflow

Present in system versions: 5.3.2-5.5.1 (possibly older versions, too)

Publicly exploited: Yes (wiiu_browserhax_fright)

Discovered by: yellows8

Documented libstagefright MP4 integer overflow.

PPC kernel exploits

OSDriver race attack

Present in system versions: 2.0.0-5.4.0

Publicly exploited: Yes (libwiiu)

Discovered by: libwiiu team (Marionumber1, TheKit, Hykem, comex, Relys and Mathew_Wi)

The Cafe OS kernel implements a structure called an OSDriver, which can hold a 0x1000-byte cross-process data area. Accessing this data area is done through the CopyToSaveArea() and CopyFromSaveArea() syscalls. However, no lock on the OSDriver is held during the copy, allowing the save area to be freed and reallocated while the copy is taking place. With all 3 PPC cores, it is possible to copy over an OSDriver structure, and create a save area that points at the syscall table, giving PPC user mode code access to it. More information here.

GX2 unchecked memory read/write

Present in system versions: 2.0.0-5.5.1

Publicly exploited: Yes (libwiiu)

Discovered by: libwiiu team (Marionumber1, Hykem and Mathew_Wi)

The Wii U GPU (the GX2) has direct access to RAM for various operations. Using raw GPU commands it is possible to read/write memory in the PPC kernel heap, which is not blocked from GPU access. By redirecting the "next pointer" in the kernel heap into userspace it becomes possible to create a new OSDriver structure in userpsace and set it's save area to the kernel syscall table. From that point on, the OSDriver race attack can be reused.

IOSU module exploits

ioctlv TOCTOU (ioctlvhax)

Present in system versions: 1.0.0-5.2.0

Publicly exploited: Yes

Discovered by: naehrwert and plutoo

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 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

IOS_CreateThread unchecked memset

Present in system versions: 1.0.0-5.5.1

Publicly exploited: Yes

Discovered by: plutoo and naehrwert, Hykem (independently)

The IOS_CreateThread system call fills the stack of a newly created thread without validating the passed stack address. In older firmware versions (pre 5.x.x) this memset was done using a null constant (0x00000000). Considering that every IOSU module can call this system call, compromising the IOSU userspace and calling IOS_CreateThread allowed to arbitrarily patch the IOSU kernel with NOP instructions (0x00000000 is interpreted as NOP in ARM) and, therefore, build a NOP sled in the IOSU kernel. In recent firmware versions (5.x.x) a constant was added to the unchecked memset (0xFA5A5A5A), sucessfully rendering it useless. However, if a new thread is created as "detached" (detached state set to true), the top 0x24 bytes of the thread's stack are memset back to null. By creating several new detached threads and aligning their stacks carefully, it becomes possible to build a NOP sled again.