Switch Userland Flaws

Revision as of 23:15, 31 December 2020 by Yellows8 (talk | contribs) (→‎nnSdk)

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
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 yellows8
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