3DS System Flaws: Difference between revisions

(5 intermediate revisions by 2 users not shown)

Line 1,315:

|

| smea, [[User:Yellows8|Yellows8]]/others before then

|-

| [[GSP_Services|GSP]]: client management failures

| Shared memory of GSP clients is all on the same page, this allows any GSP client to craft custom GX commands for other clients. Additionally, [[GSPGPU:TriggerCmdReqQueue]] does not check if the calling client has rendering rights.

These two flaws can be used to craft DMA/Transfer Engine commands within a different GSP client to issue reads/writes to both physical (akin to gspwn) and virtual memory of said client.

| Arbitrary RW from and into a client process.

| None

| [[11.17.0-50|11.17.0-50]]

| May 2025

| [[User:kynex7510|kynex7510]], probably others

|-

| [[GSP_Services|GSP]]: unbound DMA

| GSP doesn't really care what process handle is passed to [[GSPGPU:AcquireRight]]. Hence, it's possible to craft DMA commands to read/write within that process virtual address space.

| Arbitrary RW within any process.

| None

| [[11.17.0-50|11.17.0-50]]

| June 2025

| [[User:kynex7510|kynex7510]]

|-

| rohax

Line 1,326:

Line 1,346:

|

| smea, [[User:Plutooo|plutoo]] joint effort

|-

| [[RO_Services|RO]]: custom CRO mapping into any process

| RO stores pointers to previously loaded CRRs in internal state, however it doesn't keep track to which process they belong to. Thus pointers can be reused among different processes, and since CRR verification only happens on load this bypasses it.

Granted a handle to the target process is available, the following strategy can be used to load a custom CRO into any process:

* Map valid CRS, CRR into the current application, and initialize RO normally;

* Write custom CRR, CRO into the target process at the same addresses (process handle can be used with GSP DMA capabilities for read/write operations, see above);

* Load CRO into the target process using its handle.

| Code execution in the target process.

| None

| [[11.17.0-50|11.17.0-50]]

| June 2025

| [[User:kynex7510|kynex7510]]

|-

| [[RO_Services|RO]]: target process patching

| A custom CRS file can be used to apply relocation patches anywhere in the target process, and since all pages are mapped as RW, this includes executable pages aswell.

A possible exploitation strategy takes advantage of relocation type 2 (R_ARM_ABS32), where the payload data is encoded as a series of import patches, each encoding 4 bytes of data in the "addend" field.

| Arbitrary write in the target process bypassing page protections, hence code execution.

| None

| [[11.17.0-50|11.17.0-50]]

| June 2025

| July 2025

| [[User:kynex7510|kynex7510]]

|-

| Region free

Line 1,399:

Line 1,446:

| See [https://switchbrew.org/wiki/Switch_System_Flaws#Pia here]; separately checked later (UpdateConnectionReport) by [[User:Riley|Riley]] on: June 14, 2023

| [[User:Yellows8|Yellows8]]; added to 3dbrew (UpdateConnectionReport) by [[User:Riley|Riley]] later

|-

| pialease nerf: stack overflow in Pia when parsing UDS packet cmd=5 "UpdateMigrationNodeInfoMessage"

| A UDS packet as received by Pia contains a command type, where cmd=1 is higher-layer game-data, and other cmds are parsed internally.

A function named "UdsNode::ParseUpdateMigrationNodeInfoMessage" is called to handle packets with cmd=5.

This checks the player nodeID (returns if not player 1, that is, UDS network host), then calls an additional function which does a loop of 64-bit copies to a fixed-size stack buffer using unchecked index and data from the received packet contents.

This therefore leads to trivial RCE (of every UDS network client) by just sending a single UDS packet; only 0xC u64s on stack can be overwritten easily, but just 2 is enough to start a ROP chain and pivot to the rest of the UDS packet contents elsewhere on the stack.

To exploit some games, an attacker would need to also reimplement the DLP server protocol (and any quirks that game has when parsing the UDS network passphrase obtained from the DLP server). One game that requires this is Mario Party: Island Tour (only the dlplay child connects to a UDS network).

Earliest version of Pia known to be vulnerable is v2.x. v1.x still parses this packet, but does not have the stack-copy loop (index is still unchecked there leading to heap overflow but due to overwrites not being contiguous in memory it may or may not be exploitable).

Fixed with Pia version 4.x, which refactored the UDS send/receive wrapper code and parses completely different commands.

| ROP under the vulnerable application. A server can exploit every client connected to it; a client can exploit every other client connected to that server.

| "[SDK+Nintendo:PIA_4_2_0]"

| "[SDK+Nintendo:PIA_3_10_2]", "[SDK+Nintendo:PIA_4_2_0]"

| Discovery: June 3, 2023.

Wiki: November 20, 2023.

| [[User:Riley|Riley]]

|}

@@ Line 1,315: / Line 1,315: @@
 |
 | smea, [[User:Yellows8|Yellows8]]/others before then
+|-
+| [[GSP_Services|GSP]]: client management failures
+| Shared memory of GSP clients is all on the same page, this allows any GSP client to craft custom GX commands for other clients. Additionally, [[GSPGPU:TriggerCmdReqQueue]] does not check if the calling client has rendering rights.
+These two flaws can be used to craft DMA/Transfer Engine commands within a different GSP client to issue reads/writes to both physical (akin to gspwn) and virtual memory of said client.
+| Arbitrary RW from and into a client process.
+| None
+| [[11.17.0-50|11.17.0-50]]
+| May 2025
+| May 2025
+| [[User:kynex7510|kynex7510]], probably others
+|-
+| [[GSP_Services|GSP]]: unbound DMA
+| GSP doesn't really care what process handle is passed to [[GSPGPU:AcquireRight]]. Hence, it's possible to craft DMA commands to read/write within that process virtual address space.
+| Arbitrary RW within any process.
+| None
+| [[11.17.0-50|11.17.0-50]]
+| June 2025
+| June 2025
+| [[User:kynex7510|kynex7510]]
 |-
 | rohax
@@ Line 1,326: / Line 1,346: @@
 |
 | smea, [[User:Plutooo|plutoo]] joint effort
+|-
+| [[RO_Services|RO]]: custom CRO mapping into any process
+| RO stores pointers to previously loaded CRRs in internal state, however it doesn't keep track to which process they belong to. Thus pointers can be reused among different processes, and since CRR verification only happens on load this bypasses it.
+Granted a handle to the target process is available, the following strategy can be used to load a custom CRO into any process:
+* Map valid CRS, CRR into the current application, and initialize RO normally;
+* Write custom CRR, CRO into the target process at the same addresses (process handle can be used with GSP DMA capabilities for read/write operations, see above);
+* Load CRO into the target process using its handle.
+| Code execution in the target process.
+| None
+| [[11.17.0-50|11.17.0-50]]
+| June 2025
+| June 2025
+| [[User:kynex7510|kynex7510]]
+|-
+| [[RO_Services|RO]]: target process patching
+| A custom CRS file can be used to apply relocation patches anywhere in the target process, and since all pages are mapped as RW, this includes executable pages aswell.
+A possible exploitation strategy takes advantage of relocation type 2 (R_ARM_ABS32), where the payload data is encoded as a series of import patches, each encoding 4 bytes of data in the "addend" field.
+| Arbitrary write in the target process bypassing page protections, hence code execution.
+| None
+| [[11.17.0-50|11.17.0-50]]
+| June 2025
+| July 2025
+| [[User:kynex7510|kynex7510]]
 |-
 | Region free
@@ Line 1,399: / Line 1,446: @@
 | See [https://switchbrew.org/wiki/Switch_System_Flaws#Pia here]; separately checked later (UpdateConnectionReport) by [[User:Riley|Riley]] on: June 14, 2023
 | [[User:Yellows8|Yellows8]]; added to 3dbrew (UpdateConnectionReport) by [[User:Riley|Riley]] later
+|-
+| pialease nerf: stack overflow in Pia when parsing UDS packet cmd=5 "UpdateMigrationNodeInfoMessage"
+| A UDS packet as received by Pia contains a command type, where cmd=1 is higher-layer game-data, and other cmds are parsed internally.
+A function named "UdsNode::ParseUpdateMigrationNodeInfoMessage" is called to handle packets with cmd=5.
+This checks the player nodeID (returns if not player 1, that is, UDS network host), then calls an additional function which does a loop of 64-bit copies to a fixed-size stack buffer using unchecked index and data from the received packet contents.
+This therefore leads to trivial RCE (of every UDS network client) by just sending a single UDS packet; only 0xC u64s on stack can be overwritten easily, but just 2 is enough to start a ROP chain and pivot to the rest of the UDS packet contents elsewhere on the stack.
+To exploit some games, an attacker would need to also reimplement the DLP server protocol (and any quirks that game has when parsing the UDS network passphrase obtained from the DLP server). One game that requires this is Mario Party: Island Tour (only the dlplay child connects to a UDS network).
+Earliest version of Pia known to be vulnerable is v2.x. v1.x still parses this packet, but does not have the stack-copy loop (index is still unchecked there leading to heap overflow but due to overwrites not being contiguous in memory it may or may not be exploitable).
+Fixed with Pia version 4.x, which refactored the UDS send/receive wrapper code and parses completely different commands.
+| ROP under the vulnerable application. A server can exploit every client connected to it; a client can exploit every other client connected to that server.
+| "[SDK+Nintendo:PIA_4_2_0]"
+| "[SDK+Nintendo:PIA_3_10_2]", "[SDK+Nintendo:PIA_4_2_0]"
+| Discovery: June 3, 2023.
+Wiki: November 20, 2023.
+| [[User:Riley|Riley]]
 |}