2,787
edits
Changes
General fixes, sorting and merging userland flaws page
For userland applications/applets flaws see [[Switch_Userland_Flaws|here]].
For userland applications/applets flaws see [[Switch_Userland_Flaws|here]].
= Hardware =
Flaws in this category pertain to the underlying hardware that powers the Switch.
Flaws in this category pertain to the underlying hardware that powers the Switch.
! Public disclosure timeframe
! Public disclosure timeframe
! Discovered by
! Discovered by
|-
|-
| GMMU DMA attack
| GMMU DMA attack
| April 9, 2018
| April 9, 2018
| [[User:SciresM|SciresM]], almost surely others (independently).
| [[User:SciresM|SciresM]], almost surely others (independently).
|-
| CVE-2018-6242 (leveraged by the ShofEL2 and Fusée Gelée exploits)
| The USB software stack provided inside the boot instruction rom (IROM/bootROM) contains a copy operation whose length can be controlled by an attacker. By carefully constructing a USB control request, an attacker can leverage this vulnerability to copy the contents of an attacker-controlled buffer over the active execution stack, gaining control of the Boot and Power Management processor (BPMP) before any lock-outs or privilege reductions occur. This execution can then be used to exfiltrate secrets and to load arbitrary code onto the main CPU Complex (CCPLEX) "application processors" at the highest possible level of privilege (typically as the TrustZone Secure Monitor at PL3/EL3).
| HAC-001-01 (Mariko/Tegra214/Tegra210b01) (also fixed independently on Tegra186).
| HAC-001 (Tegra210)
| January 2018
| April 23, 2018
| [[User:Shuffle2|shuffle2]] and fail0verflow (originally),<br> [[User:Ktemkin|ktemkin]] and ReSwitched Team (independently),<br> [[User:Naehrwert|naehrwert]] (independently),<br> [[User:Hexkyz|hexkyz]] (independently),<br> st4rk with [[User:Shinyquagsire23|Shiny Quagsire]] and Dazzozo (independently),<br> and many others (independently).
|-
|-
| Poor validation of bootrom SDRAM configuration parameters leads to arbitrary writes in bootrom
| Poor validation of bootrom SDRAM configuration parameters leads to arbitrary writes in bootrom
| TSEC for all Tegra devices
| TSEC for all Tegra devices
| Late 2018
| Late 2018
| Jan 2021
| January 2021
| [[User:Hexkyz|hexkyz]]/[[User:SciresM|SciresM]], [[User:Vale|Vale]]/[[User:Thog|Thog]] (independently), [[User:Tatsuko|Tatsuko]] (independently), possibly others (independently).
| [[User:Hexkyz|hexkyz]]/[[User:SciresM|SciresM]], [[User:Vale|Vale]]/[[User:Thog|Thog]] (independently), [[User:Tatsuko|Tatsuko]] (independently), possibly others (independently).
|-
|-
|}
|}
= Firmware =
Flaws in this category pertain to the firmware running on hardware devices, such as wifi/bluetooth, etc. Firmware is generally uploaded by sysmodules.
Flaws in this category pertain to the firmware running on hardware devices, such as wifi/bluetooth, etc. Firmware is generally uploaded by sysmodules.
| Switch: July 30, 2022
| Switch: July 30, 2022
| Switch: [[User:Yellows8|yellows8]]
| Switch: [[User:Yellows8|yellows8]]
|}
|}
= Software =
== Bootloader ==
Flaws in this category pertain to any bootloader component such as the [[Package1#Package1ldr|package1ldr]], the [[Package1#Section_1|NX bootloader]] or the [[Package1#Section_0|warmboot binary]].
Flaws in this category pertain to any bootloader component such as the [[Package1#Package1ldr|package1ldr]], the [[Package1#Section_1|NX bootloader]] or the [[Package1#Section_0|warmboot binary]].
! Discovered by
! Discovered by
|-
|-
| Null-dereference in panic()
| Null-dereference in panic()
| The Switch's stage 1 bootloader, on panic(), clears the stack and then attempts to clear the Security Engine. However, it does so by dereferencing a pointer to the SE in .bss (initially NULL), and this pointer doesn't get initialized until partway into the bootloader's main() after several functions that might panic() are called. Thus, a panic() caused prior to SE initialization would result in the SE pointer still being NULL when dereferenced.
| The Switch's stage 1 bootloader, on panic(), clears the stack and then attempts to clear the Security Engine. However, it does so by dereferencing a pointer to the SE in .bss (initially NULL), and this pointer doesn't get initialized until partway into the bootloader's main() after several functions that might panic() are called. Thus, a panic() caused prior to SE initialization would result in the SE pointer still being NULL when dereferenced.
The BPMP doesn't have an active MPU and the bus won't data abort on an invalid address, so no exception will be entered: it'll end up overwriting some exception vectors with NULL before halting.
The BPMP doesn't have an active MPU and the bus won't data abort on an invalid address, so no exception will be entered: it'll end up overwriting some exception vectors with NULL before halting.
In 3.0.0, this was fixed by moving the security engine initialization earlier in main(), before the first function that could potentially panic().
In 3.0.0, this was fixed by moving the security engine initialization earlier in main(), before the first function that could potentially panic().
| Some exception vectors overwritten with NULL, before SBK/other keyslots are cleared. Probably useless for anything more interesting.
| Some exception vectors overwritten with NULL, before SBK/other keyslots are cleared. Probably useless for anything more interesting.
| [[3.0.0]]
| [[3.0.0]]
| [[3.0.0]]
| [[3.0.0]]
| Early July, 2017
| Early July, 2017
| July 30, 2017
| July 30, 2017
| Everyone who diff'd 2.3.0 and 3.0.0 Package1
| Everyone who diff'd 2.3.0 and 3.0.0 Package1
|-
|-
| FUSE_DIS_PGM not written by package1
| FUSE_DIS_PGM not written by package1
| The switch's hardware fuse driver contains a write-once bit in a register called "FUSE_DIS_PGM", which disables burning fuses until the next reboot. While Nintendo's bootloader code for waking up from sleep writes this on all firmware, the actual package1 initial bootloader forgets to write to it on cold reboot.
| The switch's hardware fuse driver contains a write-once bit in a register called "FUSE_DIS_PGM", which disables burning fuses until the next reboot. While Nintendo's bootloader code for waking up from sleep writes this on all firmware, the actual package1 initial bootloader forgets to write to it on cold reboot.
This isn't too big of a problem because another fuse is burnt on retail devices (production mode), which prevents burning *all* fuses other than ODM_RESERVED ones in hardware.
This isn't too big of a problem because another fuse is burnt on retail devices (production mode), which prevents burning *all* fuses other than ODM_RESERVED ones in hardware.
This was fixed in 3.0.0 by writing to the register on cold boot (although the write happens in TZ instead of package1 where it should take place, possibly to obfuscate the fact that they made this mistake).
This was fixed in 3.0.0 by writing to the register on cold boot (although the write happens in TZ instead of package1 where it should take place, possibly to obfuscate the fact that they made this mistake).
| Burning arbitrary ODM reserved fuses with TZ code execution, which should never be possible for non-bootloader code.
| Burning arbitrary ODM reserved fuses with TZ code execution, which should never be possible for non-bootloader code.
Warning: one could irreparably brick one's console by playing with this.
Warning: one could irreparably brick one's console by playing with this.
| [[3.0.0]]
| [[3.0.0]]
| [[3.0.0]]
| [[3.0.0]]
| Late summer/early fall 2017
| Late summer/early fall 2017
| December 31, 2017
| December 31, 2017
| [[User:SciresM|SciresM]], [[User:motezazer|motezazer]]
| [[User:SciresM|SciresM]], [[User:motezazer|motezazer]]
|-
|-
| maconstack (TSEC firmware leaves MAC on the stack)
| maconstack (TSEC firmware leaves MAC on the stack)
| Package1ldr loads a firmware blob into TSEC early on boot. This piece of code runs on the TSEC in Authenticated Mode and has the sole purpose of generating the per-console TSEC key (see [[Cryptosystem]]).
| Package1ldr loads a firmware blob into TSEC early on boot. This piece of code runs on the TSEC in Authenticated Mode and has the sole purpose of generating the per-console TSEC key (see [[Cryptosystem]]).
As a way to mitigate attacks, the TSEC firmware blob is split into 3 stages: [[TSEC_Firmware#Boot|Boot]] which is unencrypted and unsigned, [[TSEC_Firmware#KeygenLdr|KeygenLdr]] which is unencrypted but signed and [[TSEC_Firmware#Keygen|Keygen]] which is encrypted and signed.
As a way to mitigate attacks, the TSEC firmware blob is split into 3 stages: [[TSEC_Firmware#Boot|Boot]] which is unencrypted and unsigned, [[TSEC_Firmware#KeygenLdr|KeygenLdr]] which is unencrypted but signed and [[TSEC_Firmware#Keygen|Keygen]] which is encrypted and signed.
Additionally, since signed Falcon code can't be revoked without an hardware revision, an attacker can always reuse the flawed KeygenLdr code even if a fix is issued.
Additionally, since signed Falcon code can't be revoked without an hardware revision, an attacker can always reuse the flawed KeygenLdr code even if a fix is issued.
| Running TSEC firmware's KeygenLdr in a user controlled environment.
| Running TSEC firmware's KeygenLdr in a user controlled environment.
| None
| None
| [[5.0.2]]
| [[5.0.2]]
| January 2018
| January 2018
| April 29, 2018
| April 29, 2018
| [[User:Hexkyz|hexkyz]], [[User:Rei|Reisyukaku]] (independently), probably others (independently).
| [[User:Hexkyz|hexkyz]], [[User:Rei|Reisyukaku]] (independently), probably others (independently).
|-
|-
| Stack smash in TSEC firmware's KeygenLdr
| pk1ldrhax
| Package1ldr decrypts and verifies the keyblob inside of the current BCT in order to get the package1 key, and then uses the package1 key to decrypt package1. It then validates package1 before jumping to it by checking the PK11 magic number, and that the section sizes sum to the expected size (and are individually less than the expected size).
| Package1ldr decrypts and verifies the keyblob inside of the current BCT in order to get the package1 key, and then uses the package1 key to decrypt package1. It then validates package1 before jumping to it by checking the PK11 magic number, and that the section sizes sum to the expected size (and are individually less than the expected size).
However, package1ldr does not actually validate the package1 key against a fixed vector (much like kernel9loader forgot to do so on the 3ds). This would normally not matter, as keyblobs are validated -- however, with bootrom code execution one can dump SBK and forge keyblobs, and thus control the package1 key.
However, package1ldr does not actually validate the package1 key against a fixed vector (much like kernel9loader forgot to do so on the 3ds). This would normally not matter, as keyblobs are validated -- however, with bootrom code execution one can dump SBK and forge keyblobs, and thus control the package1 key.
This was fixed incidentally in [[6.2.0]], as pk1ldr does not use keyblob data to decrypt package1 any more.
This was fixed incidentally in [[6.2.0]], as pk1ldr does not use keyblob data to decrypt package1 any more.
| With a large enough brute force: arbitrary package1 code execution from coldboot.
| With a large enough brute force: arbitrary package1 code execution from coldboot.
However, a usable brute force is on the order of >= ~2^80, so '''this is almost certainly not actually usable in any meaningful context'''.
However, a usable brute force is on the order of >= ~2^80, so '''this is almost certainly not actually usable in any meaningful context'''.
| [[6.2.0]]
| [[6.2.0]]
| [[6.2.0]]
| [[6.2.0]]
| Early 2017 (as soon as plaintext package1ldr was first dumped)
| Early 2017 (as soon as plaintext package1ldr was first dumped)
| November 20, 2018
| November 20, 2018
| Everyone
| Everyone
|-
| Stack smash in TSEC firmware's KeygenLdr
| Given that we can control the [[TSEC_Firmware#Key_data|key data]] (which is not authenticated) and the [[TSEC_Firmware#Boot|Boot]] blob (see "maconstack"), as well as the fact Non-secure and Heavy Secure code share the same stack, we can use this to attack KeygenLdr. KeygenLdr uses memcpy to copy over a payload to DMEM to verify it, which can be abused to smash the stack (in DMEM) and write over the return address of said function.
| ROP under KeygenLdr in Heavy Secure mode.
| None
| [[8.0.1]]
| Early 2018
| May 21, 2019
| Everyone (independently).
|}
|}
== TrustZone ==
Flaws in this category pertain exclusively to the [[Package1#Section_2|Secure Monitor]].
Flaws in this category pertain exclusively to the [[Package1#Section_2|Secure Monitor]].
! Discovered by
! Discovered by
|-
|-
| Non-atomic mutexes
| Non-atomic mutexes
| When an [[SMC]] is called, TrustZone sets a global variable to mark that an SMC is in progress, so that two SMCs using shared resources (like the security engine) do not trample on one another. On 1.0.0, this global variable was written using non-atomic writes, and thus a race condition is possible.
| When an [[SMC]] is called, TrustZone sets a global variable to mark that an SMC is in progress, so that two SMCs using shared resources (like the security engine) do not trample on one another. On 1.0.0, this global variable was written using non-atomic writes, and thus a race condition is possible.
However, the SMC handler enforces that all SMCs must be called from core #3, unless the top-level handler ID is 1 (SMCs internal to the kernel). Thus, the only SMCs that can be run side-by-side are [any userland smc] and smcGetRandomBytesForKernel, and this turns out to not really be abusable.
However, the SMC handler enforces that all SMCs must be called from core #3, unless the top-level handler ID is 1 (SMCs internal to the kernel). Thus, the only SMCs that can be run side-by-side are [any userland smc] and smcGetRandomBytesForKernel, and this turns out to not really be abusable.
| [[User:SciresM|SciresM]], probably others (independently).
| [[User:SciresM|SciresM]], probably others (independently).
|-
|-
| jamais vu (non-secure world access to PMC MMIO and pre-deep sleep firmware)
| jamais vu (non-secure world access to PMC MMIO and pre-deep sleep firmware)
| On [[1.0.0]], one could map in the PMC registers in userland. In addition, [[AM_services|am]] ran a little-kernel based firmware on the BPMP at runtime. With code execution under am, one could modify the BPMP's little-kernel firmware to hook deep sleep entry, and modify TrustZone/Security engine state.
| On [[1.0.0]], one could map in the PMC registers in userland. In addition, [[AM_services|am]] ran a little-kernel based firmware on the BPMP at runtime. With code execution under am, one could modify the BPMP's little-kernel firmware to hook deep sleep entry, and modify TrustZone/Security engine state.
This was fixed in [[2.0.0]] by making the PMC secure-world only, blacklisting the BPMP's exception vectors from being mapped, and thoroughly checking for malicious behavior on deep sleep entry.
This was fixed in [[2.0.0]] by making the PMC secure-world only, blacklisting the BPMP's exception vectors from being mapped, and thoroughly checking for malicious behavior on deep sleep entry.
| Arbitrary TrustZone code execution.
| Arbitrary TrustZone code execution.
| [[2.0.0]]
| [[2.0.0]]
| [[2.0.0]]
| [[2.0.0]]
| December, 2017
| December, 2017
| January 20, 2018
| January 20, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]]
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]]
|-
|-
| Missed BPMP Exception Vector Writes
| Missed BPMP Exception Vector Writes
| Starting in [[2.0.0]], the BPMP is asleep at runtime, and is turned on by TrustZone during [[SMC|smcCpuSuspend]] in order to initiate the deep sleep process. When it does so, it is held in RESET, and TrustZone attempts to write to the BPMP exception vectors at 0x6000F200 to register EVP_RESET = lp0_entry_fw_crt0, and all other EVPs to a function that simply reboots. However, while they successfully write EVP_RESET, they miss all the other vectors, accidentally writing to the 0x6000F004-0x6000F020 region instead of the 0x6000F204-0x6000F220 region they want to write to. This results in all the exception vectors for the BPMP other than RESET being "undefined" (attacker controlled).
| Starting in [[2.0.0]], the BPMP is asleep at runtime, and is turned on by TrustZone during [[SMC|smcCpuSuspend]] in order to initiate the deep sleep process. When it does so, it is held in RESET, and TrustZone attempts to write to the BPMP exception vectors at 0x6000F200 to register EVP_RESET = lp0_entry_fw_crt0, and all other EVPs to a function that simply reboots. However, while they successfully write EVP_RESET, they miss all the other vectors, accidentally writing to the 0x6000F004-0x6000F020 region instead of the 0x6000F204-0x6000F220 region they want to write to. This results in all the exception vectors for the BPMP other than RESET being "undefined" (attacker controlled).
With some way of causing an exception vector to be taken at the right time, this would give pre-sleep code execution (and thus arbitrary TrustZone code execution, via the security engine flaw). However, none of the abort vectors are really triggerable, and interrupts are disabled for the BPMP when it is taken out of reset. Thus, this is useless in practice.
With some way of causing an exception vector to be taken at the right time, this would give pre-sleep code execution (and thus arbitrary TrustZone code execution, via the security engine flaw). However, none of the abort vectors are really triggerable, and interrupts are disabled for the BPMP when it is taken out of reset. Thus, this is useless in practice.
This was fixed in [[4.0.0]] by writing to the correct registers.
This was fixed in [[4.0.0]] by writing to the correct registers.
| Theoretically: Arbitrary TrustZone code execution. In practice: Useless.
| Theoretically: Arbitrary TrustZone code execution. In practice: Useless.
| [[4.0.0]]
| [[4.0.0]]
| [[4.0.0]]
| [[4.0.0]]
| January, 2018
| January, 2018
| February 23, 2018
| February 23, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]], [[User:Naehrwert|naehrwert]], [[User:Hexkyz|hexkyz]], probably others (independently).
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]], [[User:Naehrwert|naehrwert]], [[User:Hexkyz|hexkyz]], probably others (independently).
|-
|-
| TSEC has access to the secure kernel carveout
| TSEC has access to the secure kernel carveout
| TrustZone is responsible for managing security carveouts to prevent DMA controllers from accessing the carveout which contains the kernel, sysmodules, and other critical operating system data.
| TrustZone is responsible for managing security carveouts to prevent DMA controllers from accessing the carveout which contains the kernel, sysmodules, and other critical operating system data.
Until [[8.0.0]], the list of devices that could access the carveout included the TSEC. However, the TSEC can bypass the SMMU when in authenticated mode by writing to a certain register. Thus, pwning nvservices would allow one to take over the TSEC, and use it to write to normally protected mmio/memory.
Until [[8.0.0]], the list of devices that could access the carveout included the TSEC. However, the TSEC can bypass the SMMU when in authenticated mode by writing to a certain register. Thus, pwning nvservices would allow one to take over the TSEC, and use it to write to normally protected mmio/memory.
| Everyone
| Everyone
|-
|-
| deja vu (insufficient system state validation on suspend leads to pre-sleep BPMP code execution)
| deja vu (insufficient system state validation on suspend leads to pre-sleep BPMP code execution)
| Jamais Vu was fixed in [[2.0.0]] by making the PMC secure-world only, blacklisting the BPMP's exception vectors from being mapped, and thoroughly checking for malicious behavior on deep sleep entry, since gaining pre-sleep code execution on the BPMP compromises the system.
| Jamais Vu was fixed in [[2.0.0]] by making the PMC secure-world only, blacklisting the BPMP's exception vectors from being mapped, and thoroughly checking for malicious behavior on deep sleep entry, since gaining pre-sleep code execution on the BPMP compromises the system.
However, the state validation performed by Nintendo's Secure Monitor was insufficient to prevent pre-sleep execution from being obtained.
However, the state validation performed by Nintendo's Secure Monitor was insufficient to prevent pre-sleep execution from being obtained.
This was fixed in [[8.0.0]] by blocking AHB-DMA arbitration and verifying it is held in reset during suspend, and thus there are no more devices that can write to the relevant MMIO at the right time.
This was fixed in [[8.0.0]] by blocking AHB-DMA arbitration and verifying it is held in reset during suspend, and thus there are no more devices that can write to the relevant MMIO at the right time.
| Arbitrary TrustZone/BootROM code execution, by using either the original Jamais Vu flaw (prior to [[6.0.0]] or a warmboot bootrom exploit (any firmware where pre-sleep execution can be gained).
| Arbitrary TrustZone/BootROM code execution, by using either the original Jamais Vu flaw (prior to [[6.0.0]] or a warmboot bootrom exploit (any firmware where pre-sleep execution can be gained).
| [[8.0.0]]
| [[8.0.0]]
| [[8.0.0]]
| [[8.0.0]]
| December 2017
| December 2017
| April 15, 2019
| April 15, 2019
| [[User:SciresM|SciresM]], [[User:motezazer|motezazer]] and ktemkin, [[User:Naehrwert|naehrwert]] (independently), almost certainly others (independently)
| [[User:SciresM|SciresM]], [[User:motezazer|motezazer]] and ktemkin, [[User:Naehrwert|naehrwert]] (independently), almost certainly others (independently)
|-
|-
| TrustZone allows using imported RSA exponents with arbitrary modulus
| TrustZone allows using imported RSA exponents with arbitrary modulus
StorageExpMod also now validates that the exponentiation of "DDDDD..." about the provided modulus by the imported exponent and then the fixed public exponent returns "DDDDD...", and returns invalid argument if validation fails.
StorageExpMod also now validates that the exponentiation of "DDDDD..." about the provided modulus by the imported exponent and then the fixed public exponent returns "DDDDD...", and returns invalid argument if validation fails.
| With userland privileges sufficient to use an imported RSA key: obtaining that RSA key's private exponent.
| With userland privileges sufficient to use an imported RSA key: obtaining that RSA key's private exponent.
| [[10.0.0]]
| [[10.0.0]]
| [[10.0.0]]
| [[10.0.0]]
| August 14, 2019
| August 14, 2019
| August 14, 2019
| August 14, 2019
| [[User:SciresM|SciresM]]
| [[User:SciresM|SciresM]]
|}
|}
== Kernel ==
Flaws in this category pertain exclusively to the [[Package2#Section_0|HorizonOS Kernel]].
Flaws in this category pertain exclusively to the [[Package2#Section_0|HorizonOS Kernel]].
| [[2.0.0]]
| [[2.0.0]]
|
|
|
| 2017
| ?
| Everyone
|-
|-
| svcWaitSynchronization/svcReplyAndReceive bad cleanup on error
| svcWaitSynchronization/svcReplyAndReceive bad cleanup on error
| [[2.0.0]]
| [[2.0.0]]
|
|
| 24 April
| April 24, 2017
| [[User:qlutoo|qlutoo]]
| [[User:qlutoo|qlutoo]]
|-
|-
| [[2.0.0]]
| [[2.0.0]]
| [[2.0.0]]
| [[2.0.0]]
| ~October
| October 2017
| 17 October
| October 17, 2017
| [[User:qlutoo|qlutoo]]
| [[User:qlutoo|qlutoo]]
|-
|-
| [[3.0.2]]
| [[3.0.2]]
|
|
| 34c3 (December 28, 2017)
| December 28, 2017 (34c3)
| [[User:qlutoo|qlutoo]]
| [[User:qlutoo|qlutoo]]
|-
|-
| February 2019
| February 2019
| [[User:TuxSH|TuxSH]]
| [[User:TuxSH|TuxSH]]
|}
|}
== FIRM-package System Modules ==
Flaws in this category pertain to any of the [[Package2#Section_1|built-in system modules]].
Flaws in this category pertain to any of the [[Package2#Section_1|built-in system modules]].
| September 2, 2018
| September 2, 2018
| September 19, 2018
| September 19, 2018
| SciresM
| [[User:SciresM|SciresM]]
|-
|-
| System modules vulnerable to selective downgrade attacks
| System modules vulnerable to selective downgrade attacks
|}
|}
== System Modules ==
Flaws in this category pertain to any non-built-in system module.
Flaws in this category pertain to any non-built-in system module.
| November 9, 2022
| November 9, 2022
| [[User:Hexkyz|hexkyz]]
| [[User:Hexkyz|hexkyz]]
|}
== Internet Browser ==
{| class="wikitable" border="1"
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| CVE-2016-4657
| WebKit vuln discovered around August 2016. Most notably used in the iOS 9.3.X exploit. A simple PoC can be found [https://github.com/LiveOverflow/lo_nintendoswitch/blob/master/poc1.html here]. This was later exploited by [https://twitter.com/qwertyoruiopz Qwertyoruiop] using an adjusted version of his iOS 9.3 webkit exploit (others exploited this prior to then).
|
| [[2.1.0]]
| [[2.0.0]]
| Original: August 2016
Switch: March 3rd-4th 2017
|
| Everyone
|-
| CVE-2017-7005
| WebKit type confusion.
|
| [[3.0.1]]
| [[3.0.1]]
|
|
| Everyone
|-
| CVE-2016-4622
| WebKit memory corruption bug. This bug was incorrectly re-introduced in [[4.0.0]]. See [http://www.phrack.org/papers/attacking_javascript_engines.html here] for a detailed write-up from the author.
|
| [[6.1.0]]
| [[6.1.0]]
|
|
| Everyone
|-
| CVE-2018-4441
| WebKit memory corruption bug. See [https://bugs.chromium.org/p/project-zero/issues/detail?id=1685&desc=2 here].
|
| [[7.0.0]]
| [[7.0.0]]
|
|
| Everyone
|}
=== Whitelist ===
This section documents [[Internet_Browser|WebApplet]] whitelist issues in applications. These can be used to load your own browser content over plain HTTP, which then for example could be used for web-applet exploitation.
{| class="wikitable" border="1"
! Application
! Description
! Fixed with app version
! Newest app version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Sonic Mania
| Originally this game launched web-applet with a plain-http URL for displaying the manual, this was later changed to https. Originally the whitelist only had 1 entry for a http URL, this was later replaced with various https-only URLs.
| 1.04, unknown if fixed with an earlier update
| 1.04
| January (?) 2022
| February 23, 2022
| [[User:Yellows8|yellows8]]
|}
== NintendoSDK ==
This section documents vulnerabilities for NSOs in NintendoSDK.
=== nnSdk ===
This section documents vulnerabilities for nnSdk (sdknso).
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in SDK [[System_Versions|version]]
! Last SDK version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| [[HID_services|hidbus]] GetJoyPollingReceivedData buffer overflow
| hidbus GetJoyPollingReceivedData doesn't validate the u8 size used for memcpy, when copying the data to the output JoyPollingReceivedData. With 11.x, the size is now clamped to a maximum of 0x2C (regardless of polling-mode). Note that 0x2C is the data-size for JoyButtonOnlyPollingDataAccessor, the other polling-modes have a smaller size.
The hid-sysmodule code which writes data here does handle it properly: size is clamped to a max size, and the data-read uses a fixed-size anyway (hence there's no way to trigger this sdknso vuln with the hid-sysmodule tmem writing code).
This could only be exploited if one directly writes to the tmem when one has previously compromised hid-sysmodule, without using the normal tmem-writing func for this.
There are only a few [[HID_services#ExternalDevices|apps]] which use hidbus.
| Triggering a buffer overflow in an application which uses hidbus GetJoyPollingReceivedData, from a previously compromised hid-sysmodule.
| 11.x.0
| 11.4.0
| March 2020
| December 3, 2020
| [[User:Yellows8|yellows8]]
|-
| [[Profile_Selector|Profile Selector]] uninitialized input data
| Originally unused regions of [[Profile_Selector]] UiSettings/UserSelectionSettings were not cleared prior to being sent to the applet. With 1.x.x these are now properly memset().
| Stack infoleak from user-process, sent to the applet.
| 1.x.x
| 11.4.0
| November-December 2019
| December 31, 2020
| [[User:Yellows8|yellows8]]
|}
|}