4,563
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: − Exploits are used to execute unofficial code (homebrew) on the Nintendo Switch. This page is a list of publicly known Switch system flaws.+ Line 464:
Line 464: − + Line 972:
Line 972: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
→System Modules
This page is a list of publicly known Switch flaws.
= Hardware =
= Hardware =
|}
|}
== FIRM-package System Modules ==
== BootImagePackage 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]].
| January 2, 2023
| January 2, 2023
| October 17, 2023
| October 17, 2023
| [[User:Yellows8|yellows8]]
|-
| [[PSC_services|ovln:snd]] OpenSender unvalidated count
| ovln:snd OpenSender has a count param. This count is used to allocate the specified number of objects in a linked-list for storing the data from Send. If count is 0, the linked-list is left empty, with ptrs to itself within the ISender object.
ISender Send when the above linked-list is empty, runs a switch-statement with <code>(inval>>8)&0xFF</code>. This uses another linked-list where the ptrs are initially {within ISender obj}.
No space is allocated in the ISender obj for the linked-list object-data. Therefore using Send with val 1<<8 or 2<<8 (other values throw error) results in the specified input struct being copied into the ISender obj, which then overwrites heap data OOB.
If for example one used OpenSender again right after the first OpenSender usage, then used Send as described above, this would corrupt the second ISender which includes overwriting the vtable.
If one would use Send twice in a row like this, the second one would use a corrupted linked-list (written from the first Send). If the linked-list ptrs would be valid (no crash triggered) this would allow one to copy the input data to a controlled addr, though it's restricted with the linked-list usage.
Using GetUnreceivedMessageCount afterwards is of no interest.
Besides ovln, the only other allocs on this heap is from IPmModule Initialize. This heap is also used for psc:* services (object allocs).
In theory (untested) it may be possible to also use this to obtain infoleaks, however it would only return the high-u32 of ptrs not the low u32. Essentially, one would trigger object allocations so that ExpHeap has layout: {ISender} -> {RF chunk from freeing an object} -> {module object from IPmModule Initialize}. Then one would use the Send vuln to corrupt the RF chunk, changing the size to a larger value. Then one would trigger an object allocation (probably same object which was previously freed), then another object for overwriting the module object (ISender would work) with ptrs at the target offsets in the module object. Then once IPmModule GetRequest is used, the returned u32s would be the high-u32 from ptrs. Due to alignment requirements with each allocation, it isn't possible to shift the allocations in order to leak ptr low-u32.
[17.0.0+] Now throws an error if the input count for OpenSender is 0.
| [[PSC_services|psc]]-sysmodule heap memory corruption ([[NS_services|ns]]-sysmodule on pre-8.0.0).
| [[17.0.0]]
| [[17.0.0]]
| January 13, 2023
| October 20, 2023
| [[User:Yellows8|yellows8]]
|-
| [[NV_services|nv]] NVGPU_GPU_IOCTL_GET_CHARACTERISTICS Ioctl3 infoleak
| The handler code for NVGPU_GPU_IOCTL_GET_CHARACTERISTICS for Ioctl/Ioctl3 are essentially the same, except for the value used for the max-size clamp: Ioctl uses constant 0xA0, while Ioctl3 uses the outbuf1_size. So if one uses this with Ioctl3 and a large outbuf1, this will memcpy data OOB from the source buffer, hence infoleak.
With [17.0.0+] the second block of csel code which previouly essentially used the clamped size from above, was replaced with code which properly clamps to the max-size constant.
| nvservices-sysmodule infoleak, which allows defeating ASLR.
| [[17.0.0]]
| [[17.0.0]]
| February 25, 2022
| October 24, 2023
| [[User:Yellows8|yellows8]]
|-
| [[Audio_services|audctl]] GetTargetDeviceInfo infoleak
| audctl GetTargetDeviceInfo calls an impl func with a ptr to a stackbuf, then if successful memcpys the 0x100-bytes from that buffer to output. This stackbuf is not memset. This func (after doing various state checks) copies a string to output, other than always writing a NUL-terminator there's no clearing of the buffer.
This will leak audio-sysmodule stack into the output buffer as long as the state/input checks pass (for the remainder of the buffer following the string NUL-terminator).
With [18.0.0+] data is written directly to the outbuf instead of the stack tmpbuf.
| audio-sysmodule infoleak, which allows defeating ASLR.
| [[18.0.0]]
| [[18.0.0]]
| December 24, 2022
| March 26, 2024
| [[User:Yellows8|yellows8]]
|-
| [[Audio_services|audctl]] GetSystemInformationForDebug infoleak / buffer overflow
| audctl GetSystemInformationForDebug calls a func with a 0x1000-byte stack tmpbuf, then afterwards that buffer is memcpy'd into the cmd outbuf. This called func doesn't clear the buffer. This func eventually uses [[BTM_services|btm]] cmd75 with outarray={global ptr} and count=10. Then if the outcount is s32 >=1, it loops through the output using the outcount, without validating it besides the <1 check. Data from that outarray is copied into the array in the func output buffer (tmpbuf above).
With btm comprimised, one could return a large output count and trigger a stack buffer overflow with data following that global array, however exploiting this would be difficult since that data would be uncontrolled (can't directly control it from this cmd at least).
A stack infoleak can be obtained with this as well (assuming the above output array isn't full).
Even though the name has "ForDebug", there's no checks which would trigger an error / return early (this also always returns 0).
[18.0.0+] now clears the output buffer, and also now prints strings into the buffer instead of writing binary data (overflow no longer possible).
| audio-sysmodule infoleak, which allows defeating ASLR. Also audio-sysmodule memory corruption, likely not useful unless there's a way to control the data.
| [[18.0.0]]
| [[18.0.0]]
| December 7, 2022
| March 27, 2024
| [[User:Yellows8|yellows8]]
| [[User:Yellows8|yellows8]]
|}
|}