Difference between revisions of "Wii U system flaws"
| Line 1: | Line 1: | ||
==PPC userspace exploits== | ==PPC userspace exploits== | ||
===RenderArena use-after-free=== | ===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 [https://code.google.com/p/chromium/issues/detail?id=226696 here]. | 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 [https://code.google.com/p/chromium/issues/detail?id=226696 here]. | ||
===JSStringJoiner heap overflow=== | ===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 [http://googleprojectzero.blogspot.com/2014/07/pwn4fun-spring-2014-safari-part-i_24.html here]. | 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 [http://googleprojectzero.blogspot.com/2014/07/pwn4fun-spring-2014-safari-part-i_24.html here]. | ||
| Line 22: | Line 22: | ||
'''Present in system versions''': 2.0.0-5.4.0 | '''Present in system versions''': 2.0.0-5.4.0 | ||
| − | '''Publicly exploited | + | '''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() [[Cafe OS Syscalls|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 [http://gbatemp.net/threads/osdriver-kernel-exploit-a-technical-description.395444/ here]. | 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() [[Cafe OS Syscalls|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 [http://gbatemp.net/threads/osdriver-kernel-exploit-a-technical-description.395444/ 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== | ==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. | This flaw technically is in the kernel, but it can be used to exploit a usermode module. | ||
| Line 35: | Line 49: | ||
==IOSU kernel exploits== | ==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. | ||
Revision as of 15:29, 28 July 2016
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.