Difference between revisions of "Switch Userland Flaws"
Jump to navigation
Jump to search
Line 1: | Line 1: | ||
− | This page lists vulnerabilities / exploits for Nintendo Switch applications and | + | This page lists vulnerabilities / exploits for Nintendo Switch applications/applets and SDK. |
== Browser userspace == | == Browser userspace == | ||
Line 38: | Line 38: | ||
| | | | ||
| Everyone | | Everyone | ||
+ | |} | ||
+ | |||
+ | == 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]] | ||
|} | |} |
Revision as of 21:56, 3 December 2020
This page lists vulnerabilities / exploits for Nintendo Switch applications/applets and SDK.
Browser userspace
Summary | Description | Fixed with software update | Newest software update this flaw was checked for | Timeframe this was discovered | 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 here. This was later exploited by 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 here for a detailed write-up from the author. | 6.1.0 | 6.1.0 | Everyone | |
CVE-2018-4441 | WebKit memory corruption bug. See here. | 7.0.0 | 7.0.0 | Everyone |
NintendoSDK
This section documents vulnerabilities for NSOs in NintendoSDK.
nnSdk
This section documents vulnerabilities for nnSdk (sdknso).
Summary | Description | Successful exploitation result | Fixed in SDK version | Last SDK version this flaw was checked for | Timeframe this was discovered | Public disclosure timeframe | Discovered by |
---|---|---|---|---|---|---|---|
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 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 | yellows8 |