Changes

Jump to navigation Jump to search

Wii U system flaws (view source)

Revision as of 22:32, 7 January 2017

1,825 bytes added ,  22:32, 7 January 2017
Making this page more readable
Line 1: Line 1: −
==PPC userspace exploits==
+
This page lists publicly known vulnerabilities on the Wii U system.
−
===RenderArena use-after-free===
  −
'''Present in system versions''': 2.0.0-5.1.0
     −
'''Publicly exploited''': Yes (libwiiu)
+
==boot0==
 +
{| class="wikitable" border="1"
 +
!  Summary
 +
!  Description
 +
!  Successful exploitation result
 +
!  Fixed in system version
 +
!  Discovered by
 +
|-
 +
| Unsafe boot1 image's size check
 +
| Before boot0 loads boot1, it reads boot1 image's ancast header into memory and determines boot1 image's size by looking at a field inside the ancast header (see [[Ancast_Image#Header]]). This header is not signed, so the boot1 image's size can be modified externally.
   −
'''Discovered by''': libwiiu team (Marionumber1, TheKit, Hykem, Relys and Mathew_Wi)
+
boot0 immediately checks if this size is larger than 0xF800, rendering any software based attacks useless. However, an attacker may still be able to glitch boot0 via hardware fault injection attacks and, with precise timing, jump over this size check and force boot0 to read a larger boot1 image.
 +
While the boot1 image is signed, boot0 first reads it to SRAM and only then validates it's signature.
   −
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].
+
Using a tampered boot1 image, an attacker can now overflow boot1's memory region (0x0D400000) into boot0's (0x0D410000), hijack the next code instruction and achieve code execution.
 +
By now, boot0 has already locked out the boot1 AES key in the OTP, but there is still a copy of it inside boot0's memory region and the attacker is now able to extract it.
 +
Additionally, the attacker can also read the rest of the OTP region and obtain the contents of the two blocks locked out by boot1 (which are currently unused).
   −
===JSStringJoiner heap overflow===
+
NOTE: A successful attack was implemented and demonstrated, to some extent, by derrek at the 34C3 convention.
−
'''Present in system versions''': 5.1.1-5.3.2 (possibly older versions, too)
+
| boot1 AES key extraction
 +
| None
 +
| derrek;
 +
[[User:Hexkyz|hexkyz]] (independently)
 +
|}
   −
'''Publicly exploited''': Yes (libwiiu, 5.3.2 only)
+
==boot1==
   −
'''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].
+
==ARM software (IOSU)==
 +
===ARM kernel===
 +
{| class="wikitable" border="1"
 +
!  Summary
 +
!  Description
 +
!  Successful exploitation result
 +
!  Fixed in system version
 +
!  Discovered by
 +
|-
 +
| Bad memset in IOS_CreateThread syscall
 +
| The IOS_CreateThread system call fills the stack of a newly created thread without validating the supplied stack address from the calling IOSU module.
   −
===Stagefright ‘stsc’(?) MP4 atom integer overflow===
+
In firmware versions before 5.x.x, this memset was done using zeros. Doing ROP inside any IOSU module and calling IOS_CreateThread allowed to arbitrarily patch the IOSU kernel with NOP instructions (since 0x00000000 is interpreted as NOP in ARM) and, therefore, build a NOP sled in the IOSU kernel.
−
'''Present in system versions''': 5.4.0-5.5.0 (possibly older versions, too)
     −
'''Publicly exploited''': Yes
+
In 5.x.x firmware versions, this was partially patched by using the random constant 0xFA5A5A5A in the unchecked memset.
 +
However, passing 0x02 as flags to the IOS_CreateThread system call results in an additional memset of the top 0x24 bytes (IPC buffer pool) to zeros again.
   −
'''Discovered by''': zhuowei, Marionumber1 and Mathew_Wi
+
Crafting a carefully placed NOP sled inside the IOSU's kernel is enough to achieve a kernel level write-what-where primitive and get code execution.
 +
| ARM kernel code execution
 +
| None
 +
| [[User:Plutoo|plutoo]] and [[User:Naehrwert|naehrwert]];
 +
[[User:Hykem|Hykem]] (independently)
 +
|-
 +
| get_process_name signed comparison fail
 +
| IOSU's syscall 0x06 (get_process_name) does a signed comparison for the pid parameter (r0) and does not check if the pid is negative, which allows an arbitrary 0x20 bytes kernel read to userland memory.
 +
| ARM kernel memory leak
 +
| None
 +
| [[User:Plutoo|plutoo]] (on September 11th, 2015);
 +
Mrrraou (independently, on October 31th, 2016)
 +
|}
   −
Documented libstagefright MP4 integer overflow.
+
===ARM userland===
 +
{| class="wikitable" border="1"
 +
!  Summary
 +
!  Description
 +
!  Successful exploitation result
 +
!  Fixed in system version
 +
!  Discovered by
 +
|-
 +
| ioctlvhax (ioctlv TOCTOU)
 +
| This flaw technically is in the kernel, but it can be used to exploit a userland 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].
 +
| ROP under several IOSU modules
 +
| 5.2.0
 +
| [[User:Naehrwert|naehrwert]] and [[User:Plutoo|plutoo]]
 +
|-
 +
| uhshax (/dev/uhs/0 bad array index check)
 +
| The IOS-USB module manages the UHS (USB host stack) and exposes it through the node /dev/uhs/0.
 +
IOCtl commands 0x12 and 0x13 (firmware versions 2.x.x), or 0x13 and 0x14 (firmware versions 3.x.x and 4.x.x), or 0x14 and 0x15 (firmware versions 5.x.x) are responsible for activating and deactivating (respectively) UHS root hubs (which are managed in internal structures inside the IOS-USB module's memory space).
   −
===Stagefright ‘tx3g’ MP4 atom integer overflow===
+
The single parameter that is passed to these IOCtl commands is the root hub number which can only be 0 or 1. IOS-USB module 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).
−
'''Present in system versions''': 5.3.2-5.5.1 (possibly older versions, too)
+
Passing the index value 2 results in an useless array index overflow, but passing a negative value allows to redirect the array into a controllable PPC userland buffer.
   −
'''Publicly exploited''': Yes (wiiu_browserhax_fright)
+
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 an uncontrollable memory write (the written data comes from IOS-BSP and cannot be changed).
   −
'''Discovered by''': yellows8
+
However, the IOCtl command responsible for deactivating a root hub can be exploited by carefully crafting a buffer that mimics a root hub structure. With it, we can eventually achieve a write-what-where primitive, overwrite the return address of the __uhsBackgroundThread thread (responsible for handling IPC requests to /dev/uhs/0) and achieve ROP inside IOS-USB.
   −
Documented libstagefright MP4 integer overflow.
+
NOTE: After firmware version 5.5.0 a new check was added to the system call handler that verifies if the calling thread's stack pointer is valid.
 +
If an attacker plans on targeting IOSU syscalls from inside this ROP chain, then the thread's stack pointer can't be increased past the stack's top address.
 +
| ROP under the IOS-USB module
 +
| None
 +
| [[User:Hykem|Hykem]]
 +
|}
   −
===contenthax===
+
==PPC software (CafeOS)==
−
'''Present in system versions''': All
+
===PPC kernel===
 +
{| class="wikitable" border="1"
 +
!  Summary
 +
!  Description
 +
!  Successful exploitation result
 +
!  Fixed in system version
 +
!  Discovered by
 +
|-
 +
| OSDriver race attack
 +
| 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].
 +
| PPC kernel code execution
 +
| 5.4.0
 +
| libwiiu team ([[User:Marionumber1|Marionumber1]], TheKit, [[User:Hykem|Hykem]], [[User:Comex|comex]], Relys and [[User:Mathew_Wi|Mathew_Wi]])
 +
|-
 +
| GX2 unchecked memory read/write
 +
| 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.
 +
| PPC kernel code execution
 +
| None
 +
| libwiiu team ([[User:Marionumber1|Marionumber1]], [[User:Hykem|Hykem]] and [[User:Mathew_Wi|Mathew_Wi]])
 +
|}
   −
'''Publicly exploited''': Yes
+
===PPC userland===
−
 
+
{| class="wikitable" border="1"
−
'''Discovered by''': yellows8, smea (Early 2016); WulfyStylez (Early 2016)
+
!  Summary
−
 
+
!  Description
−
The Wii U's data management system does not include provisions to validate the integrity of most title contents after installation. Any title contents using hash tables for verification (content type 0x0002 in tmd, using *.h3 files) are vulnerable. Generally, all contents are vulnerable apart from those in /code.
+
!  Successful exploitation result
 +
!  Fixed in system version
 +
!  Discovered by
 +
|-
 +
| RenderArena use-after-free
 +
| 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].
 +
| ROP under the Internet Browser application
 +
| 5.1.0
 +
| libwiiu team ([[User:Marionumber1|Marionumber1]], TheKit, [[User:Hykem|Hykem]], Relys and [[User:Mathew_Wi|Mathew_Wi]])
 +
|-
 +
| JSStringJoiner heap overflow
 +
| 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].
 +
| ROP under the Internet Browser application
 +
| 5.3.2
 +
| libwiiu team ([[User:Marionumber1|Marionumber1]], [[User:Hykem|Hykem]] and [[User:Mathew_Wi|Mathew_Wi]])
 +
|-
 +
| Stagefright ‘stsc’(?) MP4 atom integer overflow
 +
| Documented libstagefright MP4 integer overflow.
 +
| ROP under the Internet Browser application
 +
| 5.5.0
 +
| zhuowei, [[User:Marionumber1|Marionumber1]] and [[User:Mathew_Wi|Mathew_Wi]]
 +
|-
 +
| Stagefright ‘tx3g’ MP4 atom integer overflow
 +
| Documented libstagefright MP4 integer overflow. See [https://github.com/yellows8/wiiu_browserhax_fright].
 +
| ROP under the Internet Browser application
 +
| None
 +
| [[User:Yellows8|yellows8]]
 +
|-
 +
| contenthax
 +
| The Wii U's data management system does not include provisions to validate the integrity of most title contents after installation. Any title contents using hash tables for verification (content type 0x0002 in tmd, using *.h3 files) are vulnerable. Generally, all contents are vulnerable apart from those in /code.
    
As such, any game or app's contents may be altered by attackers. In particular, attackers with IOSU code execution may use FSA commands to alter the content files in USB or MLC filesystems. Alternatively, an attacker with control over certain PPC usermode processes (such as home menu or system settings) may use commands such as MCP:CopyTitle to copy title contents over from SD to MLC or USB.
 
As such, any game or app's contents may be altered by attackers. In particular, attackers with IOSU code execution may use FSA commands to alter the content files in USB or MLC filesystems. Alternatively, an attacker with control over certain PPC usermode processes (such as home menu or system settings) may use commands such as MCP:CopyTitle to copy title contents over from SD to MLC or USB.
 +
| Arbitrary title content modification
 +
| None
 +
| [[User:Yellows8|yellows8]], [[User:Smea|smea]] (Early 2016);
 +
[[User:WulfyStylez |WulfyStylez]] (Early 2016)
 +
|-
 +
| haxchi (variation of contenthax)
 +
| The Wii U Nintendo DS virtual console emulator is vulnerable to contenthax attacks. In particular, the ROM parsing code lets an attacker perform fully controlled arbitrary write operations, which very easily leads to ROP and code execution, because these titles are among the few that have JIT capabilities.
 +
| ROP under the Wii U Nintendo DS virtual console emulator title
 +
| None
 +
| [[User:Smea|smea]] (Early 2016)
 +
|-
 +
| N64 VC contenthax (variation of contenthax)
 +
| The Wii U N64 VC emulator title("VESSEL") has two known vulnerabilities which can be attacked via contenthax. These vulnerabilities were tested on hardware, but actual exploitation wasn't tested.
   −
====haxchi====
+
Note that this title can only write to codegen (JIT) via using OSCodegenCopy(), unlike other titles.
−
'''Present in system versions''': N/A
  −
 
  −
'''Publicly exploited''': Yes
  −
 
  −
'''Discovered by''': smea (Early 2016)
  −
 
  −
The Wii U Nintendo DS virtual console emulator is vulnerable to contenthax attacks. In particular, the rom parsing code lets an attacker perform fully controled arbitrary write operations, which very easily leads to ROP and code execution, because these titles are among the few that have JIT capabilities.
  −
 
  −
====N64 VC contenthax====
  −
'''Present in system versions''': N/A
  −
 
  −
'''Publicly exploited''': No
  −
 
  −
'''Discovered by''': yellows8 (Early 2016)
  −
 
  −
The Wii U N64 VC emulator title("VESSEL") has two known vulns which can be attacked via contenthax. These vulns were tested on hardware, but actual exploitation wasn't tested.
     −
Note that this title can only write to codegen(JIT) via using OSCodegenCopy(), unlike other titles.
+
Currently this is the only known VC platform (N64) which is affected by any of these VESSEL vulnerabilities (not all platforms were checked for this).
   −
Currently this is the only known VC platform(N64) which is affected by any of these VESSEL vulns(not all platforms were checked for this).
+
The .ini loading occurs much earlier during title boot than the font loading. These vulnerabilities (or at least the .ini one) trigger while the system is still displaying the application splash-screen(from the title's meta/ directory).
−
 
  −
The .ini loading occurs much earlier during title boot than the font loading. These vulns(or at least the .ini one) trigger while the system is still displaying the application spash-screen(from the title's meta/ directory).
      
* Stack buffer overflow when handling BMFont "pages". The entire block is copied to stack using just the size, without checking the size. The loaded data is not checked either, other than converting uppercase to lowercase('A'..'Z' to 'a'..'z'). This string is used with sprintf + PNG texture loading afterwards.
 
* Stack buffer overflow when handling BMFont "pages". The entire block is copied to stack using just the size, without checking the size. The loaded data is not checked either, other than converting uppercase to lowercase('A'..'Z' to 'a'..'z'). This string is used with sprintf + PNG texture loading afterwards.
 
* Heap buffer overflow during .ini parsing with field-data string starting with '"'. The allocated heap buffer is 0x100-bytes, but the size is not checked when copying the value string into this buffer. During copying/etc this string content is not checked/modified, besides checking for the end of the string with '"'. For example: HAX = "LONGSTRINGHERE"
 
* Heap buffer overflow during .ini parsing with field-data string starting with '"'. The allocated heap buffer is 0x100-bytes, but the size is not checked when copying the value string into this buffer. During copying/etc this string content is not checked/modified, besides checking for the end of the string with '"'. For example: HAX = "LONGSTRINGHERE"
−
 
+
| ROP under the Wii U N64 virtual console emulator title
−
==PPC kernel exploits==
+
| None
−
===OSDriver race attack===
+
| [[User:Yellows8|yellows8]] (Early 2016)
−
'''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() [[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==
  −
===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 [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''': Yes
  −
 
  −
'''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.
  −
 
  −
===get_process_name (syscall 0x6) signed comparison fail===
  −
'''Present in system versions''': 1.0.0-5.5.1
  −
 
  −
'''Publicly exploited''': No (but easy to exploit)
  −
 
  −
'''Discovered by''': plutoo (on September 11th, 2015), Mrrraou (independently, on October 31th, 2016)
  −
 
  −
get_process_name (syscall 0x6) does a signed comparison for the pid parameter (r0) and does not check if the pid is negative, which allows an arbitrary 0x20 bytes kernel read to userland memory.
 
Retrieved from "https://wiiubrew.org/wiki/Special:MobileDiff/2400"

Navigation menu