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.
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.
IOSU kernel exploits
IOS_CreateThread unchecked memset
Present in system versions: 1.0.0-5.5.1
Publicly exploited: No
Discovered by: 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.