112
edits
Changes
Jump to navigation
Jump to search
Add DNSpresso write-up link
Line 14:
Line 14:
|-
−| 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]]
| None
| None
| [[User:marcan|marcan]]
| [[User:marcan|marcan]]
+|-
+| eFuse readout counter is not reset with NRST (de_Fuse)
+| In order to accommodate eFuse-based JTAG lockout (and due to other considerations), eFuse bits must be buffered into a register file immediately following NRST, before the internal reset can be released. The eFuse sense state machine latches at a rate of 4 bits per cycle, directly off the 27MHz XTALCLK. Every other rising edge, a byte is written into the register file, starting from the least significant byte of the current u32.
+
+An internal counter is used to keep track of the remaining bytes to be read into the register file. While the eFuse register file is reset to zero with NRST, the internal counter is not: By asserting NRST after N bytes have been read, only 0x400-N bytes will be read on the subsequent boot.
+
+By asserting NRST just before the final byte has been read (1830 cycles), all eFuses will read entirely zero, including the JTAG lockout fuse. This allows trivial, unsigned and unencrypted boot1 execution, with no SEEPROM anti-rollback.
+
+Additionally, because SRAM is not cleared on reboot, and because boot1 verifies over the encrypted payload, the boot1 key can be extracted. By asserting NRST after 176 cycles and walking the delay width down cycle-by-cycle, code execution can be used to gather 16 failed decryptions of boot1: A zerokey-decrypted boot1, and 15 others with one more byte present in its boot1 key than the last. This allows a straightforward bruteforce of the boot1 key.
+| Trivial arbitrary code execution as boot1;
+boot1 AES key extraction;
+Recovery of SEEPROM-bricked Wii Us
+| None
+| [[User:shinyquagsire23|shinyquagsire23]]
|}
|}
Line 72:
Line 86:
! Fixed in system version
! Fixed in system version
! Discovered by
! 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]]
|-
|-
| Bad memset in IOS_CreateThread syscall
| Bad memset in IOS_CreateThread syscall
Line 93:
Line 114:
| [[User:Plutoo|plutoo]] (on September 11th, 2015);
| [[User:Plutoo|plutoo]] (on September 11th, 2015);
Mrrraou (independently, on October 31th, 2016)
Mrrraou (independently, on October 31th, 2016)
+|-
+| IOS_CreateMessageQueue poor address range validation
+| IOS_CreateMessageQueue() syscall does not check the number of entries, allowing for an integer overflow that will bypass the address range validation. Using IOS_SendMessage(), one can overwrite IOSU kernel and achieve code execution. see [https://www.youtube.com/watch?v=8C5cn_Qj0G8 here] and [https://github.com/Rambo6Glaz/iosu_mq_exploit/blob/master/source/main.c here] for impl.
+| ARM kernel code execution
+| None
+| [[User:derrek|derrek]], [[User:nedwill|nedwill]] and [[User:naehrwert|naehrwert]] ?
|}
|}
Line 102:
Line 129:
! Fixed in system version
! Fixed in system version
! Discovered by
! Discovered by
−|-
|-
| uhshax (/dev/uhs/0 bad array index check)
| uhshax (/dev/uhs/0 bad array index check)
Line 127:
Line 147:
| [[User:Hykem|Hykem]]
| [[User:Hykem|Hykem]]
|-
|-
−| BluuBomb
+| Stack buffer overflow for received HID reports (BluuBomb)
| The Wii U doesn't check the size of received HID reports in IOS-PAD. By emulating a Wii Remote an attacker can send reports larger than 58 bytes and overflow a buffer on the stack.
| The Wii U doesn't check the size of received HID reports in IOS-PAD. By emulating a Wii Remote an attacker can send reports larger than 58 bytes and overflow a buffer on the stack.
More information [https://github.com/GaryOderNichts/bluubomb/blob/master/WRITEUP.md here].
More information [https://github.com/GaryOderNichts/bluubomb/blob/master/WRITEUP.md here].
Line 133:
Line 153:
| None
| None
| [[User:GaryOderNichts|GaryOderNichts]], [[User:Yellows8|yellows8]] (independently: January 2021)
| [[User:GaryOderNichts|GaryOderNichts]], [[User:Yellows8|yellows8]] (independently: January 2021)
+|-
+| Double fetch during USB configuration parsing causing out of bounds byteswap
+| The Wii U doesn't verify that the total length of the USB configuration descriptor matches the total length used to determine the buffer size. This allows placing endpoint descriptors outside of the allocated buffer which will be swapped.
+| Out of bounds byteswap in IOS-USB heap. Can lead to ROP, see [https://garyodernichts.blogspot.com/2022/06/exploiting-wii-us-usb-descriptor-parsing.html this post].
+| None
+| [[User:GaryOderNichts|GaryOderNichts]]
+|-
+| Heap buffer overflow in DNS response processing
+| IOS-NET uses a modified version of NicheStack which is affected by [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25928 CVE-2020-25928]. Unlike described by the CVE, the IOS-NET implementation has an additional check for DNS PTR answers, which ensures the data isn't copied past the end of the buffer.
+For additional PTR records pointing at the first answer name <code>dnc_set_answer</code> is still called without checking the response data length field though.
+| Out-of-bounds heap write. Can lead to ROP, see [https://garyodernichts.blogspot.com/2023/10/exploiting-dns-response-parsing-on-wii-u.html this post].
+| None
+| [[User:GaryOderNichts|GaryOderNichts]]
|}
|}
Line 144:
Line 177:
|-
|-
| Binary is not reverified before launching
| Binary is not reverified before launching
−| The [[Espresso Boot ROM]] does not check for modifications to the binary in main memory before launching it. By changing the first instruction from the [[Hardware/Starbuck|Starbuck]], the [[Espresso]] can be sent anywhere.
+| The [[Espresso boot ROM]] does not check for modifications to the binary in main memory before launching it. By changing the first instruction from the [[Hardware/Starbuck|Starbuck]], the [[Espresso]] can be sent anywhere.
| Arbitrary Espresso code booting
| Arbitrary Espresso code booting
| Unknown
| Unknown
Line 152:
Line 185:
| The Espresso Boot ROM keeps an infinite loop at the reset vector to prevent unexpected code from executing. Most of the time, this is in the L2 cache, which prevents the Starbuck from overwriting it. Toward the end, it is no longer in the cache, so a custom jump can be done, before ROM access is disabled.
| The Espresso Boot ROM keeps an infinite loop at the reset vector to prevent unexpected code from executing. Most of the time, this is in the L2 cache, which prevents the Starbuck from overwriting it. Toward the end, it is no longer in the cache, so a custom jump can be done, before ROM access is disabled.
| Espresso Boot ROM can be dumped
| Espresso Boot ROM can be dumped
+| Unknown
+| marcan
+|-
+| [[WiiMode]] flag is not set here
+| In WiiMode, the [[ancast image|ancast images]] themselves are responsible for lowering the clock speed. If one of the above hacks is used to take control, it becomes possible to execute code in full [[Espresso]] mode.
+| WiiUMode privileges within the Espresso
| Unknown
| Unknown
| marcan
| marcan