Switch System Flaws: Difference between revisions
| (4 intermediate revisions by the same user not shown) | |||
| Line 1,059: | Line 1,059: | ||
| December 14, 2021 | | December 14, 2021 | ||
| October 8, 2024 | | October 8, 2024 | ||
| [[User:Yellows8|yellows8]] | |||
|- | |||
| [[Audio_services|audren]] uncleared TransferMemory | |||
| audren OpenAudioRenderer uses the input tmem as workmem. The IAudioRenderer dtor doesn't clear the workmem properly. Depending on input params, certain objects stored here have vtables - hence infoleak. | |||
The exact location in the workmem will vary depending on the input params - these objects are dynamically allocated in the workmem. | |||
The following will leak vtables: Sink, Effect. | |||
If the initialization func fails, the tmem is unmapped without clearing it first. It's unknown whether there's a way to actually trigger an infoleak with this however. With [19.0.0+] it's now cleared on failure. | |||
With [19.0.0+] the dtor now clears the workmem when needed. | |||
| Reading leaked data/ptrs from TransferMemory -> defeating ASLR in [[Audio_services|audio]]-sysmodule. | |||
| [[19.0.0]] | |||
| [[19.0.0]] | |||
| December 17, 2022 | |||
| October 13, 2024 | |||
| [[User:Yellows8|yellows8]] | |||
|- | |||
| [[Audio_services|audren]] UpdateMixes OOB mem-copy | |||
| With nn::audio::server::InfoUpdater::UpdateMixes when nn::audio::server::BehaviorInfo::IsMixInParameterDirtyOnlyUpdateSupported() returns true (requires REV7, which is [7.0.0+]), the mix_id from user input is used without validation as input to <code><nn::audio::server::MixContext::GetInfo(int) const></code>, instead of the counter from the for-loop. This allows one to control the destination MixInfo index which the user-input data is written into. If too large, this will trigger OOB data-copy. Note that the u8 at dest_MixInfo+12 must be non-zero. | |||
Also note that a field is loaded from dest_MixInfo which is used as a splitter_id, so splitters need to be initialized where count is large enough for that id. | |||
With [19.0.0+] after getting the mix_id (loop-index/input) it now does: <code>if (mix_id < 0 || mix_id >= nn::audio::server::MixContext::GetCount()) continue;</code> | |||
| OOB mem-copy in [[Audio_services|audio]]-sysmodule, which for example can be used to overwrite a vtable used immediately after UpdateMixes. | |||
| [[19.0.0]] | |||
| [[19.0.0]] | |||
| December 19, 2022 | |||
| October 13, 2024 | |||
| [[User:Yellows8|yellows8]] | |||
|- | |||
| [[Bus_services|sasbus]] StartPeriodicReceiveMode infoleak | |||
| StartPeriodicReceiveMode writes a vtable ptr into the mapped tmem at +0. The tmem is mapped RW in the user-process. There is no clearing of tmem during tmem cleanup. Hence, the user-process can read the tmem to obtain a Bus-sysmodule codebin-region infoleak. This vtable-ptr seems to be unused - it's also empty after the first two entries (stubbed incref/decref). | |||
[20.0.0+] Removed the vtable ptr, with data intended for the user-process being moved from tmem+0x8 to +0x0. Also, instead of calling memset, funcs are called for manually clearing tmem. | |||
| Bus-sysmodule infoleak, which allows defeating ASLR. | |||
| [[20.0.0]] | |||
| [[20.0.0]] | |||
| February 22, 2022 | |||
| May 3, 2025 | |||
| [[User:Yellows8|yellows8]] | |||
|- | |||
| [[NFC_services|nfc]] SendCommandByPassThrough buffer overflow | |||
| SendCommandByPassThrough eventually copies the input buffer into a fixed-size heap buffer, without size validation. | |||
This was fixed with [20.0.0+] by clamping the size. | |||
| nfc-sysmodule heap buffer overflow. | |||
| [[20.0.0]] | |||
| [[20.0.0]] | |||
| Late November 2021 | |||
| May 3, 2025 | |||
| [[User:Yellows8|yellows8]] (maybe others?) | |||
|- | |||
| [[HID_services|hidbus]] EnableJoyPollingReceiveMode infoleak | |||
| The tmem initialized by hidbus EnableJoyPollingReceiveMode contains a vtable ptr (tmem+0x10), hence infoleak. With [20.0.0+] the vtable ptr write was removed, and tmem is now memset starting at tmem+0x10 instead of +0x20. | |||
| hid-sysmodule infoleak, which allows defeating ASLR. | |||
| [[20.0.0]] | |||
| [[20.0.0]] | |||
| March 2020 | |||
| May 4, 2025 | |||
| [[User:Yellows8|yellows8]] | | [[User:Yellows8|yellows8]] | ||
|} | |} | ||
| Line 1,109: | Line 1,165: | ||
| | | | ||
| Everyone | | Everyone | ||
|- | |||
| Web-applets OpenSSL broken RNG | |||
| [[SPL_services|csrng]] access was added to web-applets with [12.1.0+]. Prior to that, csrng and nn::os::GenerateRandomBytes were not used (besides sdk heap code). | |||
nn::os::GetSystemTick is used to seed the OpenSSL RNG, among other data. Hence, it's probably (?) possible to bruteforce the RNG initial state, allowing predicting RNG output. | |||
The RNG code is wkcRandomNumbersPeer (peer_wkc nro), with the initialization code using GetSystemTick located in the func immediately before wkcGetTickCountPeer. The former is called from wkcOsslRandFilefReadPeer. wkcOsslRandFilefReadPeer is called for seeding the OpenSSL RNG. | |||
With [12.1.0+], wkcRandomNumberPeer/wkcRandomNumbersPeer wrap nn::os::GenerateRandomBytes. wkcCryptographicallyRandomValuesPeer was added which wraps nn::crypto::GenerateCryptographicallyRandomBytes. wkcOsslRandFilefReadPeer now calls nn::crypto::GenerateCryptographicallyRandomBytes instead of wkcRandomNumbersPeer. | |||
| Breaking web-applets OpenSSL RNG -> potentially predict RNG data (keys(?)) during TLS comms. | |||
| [[12.1.0]] | |||
| [[12.1.0]] | |||
| January 28, 2022 | |||
| October 8, 2024 | |||
| [[User:Yellows8|yellows8]], likely (?) others | |||
|} | |} | ||