Changes

4,714 bytes added ,  16:00, 20 November 2023
m
no edit summary
Line 24: Line 24:  
The ARM9 bootrom does the following at reset:  reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.
 
The ARM9 bootrom does the following at reset:  reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.
   −
This requires *very* *precise* timing for triggering the hardware fault.
+
The vulnerable timing range is about 100 CPU cycles after they start (which happens after the PLLs have stabilized after power-up). A glitch needs to be injected during one of these 100 cycles for the attack to succeed.
    
It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.
 
It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.
Line 460: Line 460:  
|  
 
|  
 
| [[User:Yellows8|Yellows8]]
 
| [[User:Yellows8|Yellows8]]
 +
|-
 +
| [[FS:EnumerateExtSaveData]] crashes process9 when trying to parse a file as an extdata directory in Data Management (MSET9)
 +
| In the implementation for FSPXI:EnumerateExtSaveData (called by [[System_Settings|MSET]] to parse 3DS extdata IDs for Data Management), the return value of the P9 internal function call to open a directory (when enumerating contents of the extdata directory) was not checked. Therefore, if the call fails, an uninitialised pointer on stack will be used for a vtable call.
 +
 +
As such, a file that starts with 8 hex digits can crash process9 if placed directly inside the extdata directory. It can crash in various ways based on subtle differences in the way the user triggers the crash event.
 +
 +
While mostly leading to null derefs, in one specific context, process9 jumps directly to an ID1 string being held in ARM9 memory. Surprisingly, the 3DS doesn't discern what characters are used for the ID1 directory name on the SD, only requiring exactly 32 chars. This allows the attacker to insert arm instructions into the unicode ID1 dirname and take control of the ARM9, and thus, full control of the 3DS.
 +
| ARM9 code execution (primary)
 +
| None
 +
| [[11.17.0-50|11.17.0-X]]
 +
| April 2022
 +
| August 7, 2023
 +
| zoogie
 
|-
 
|-
 
| RSA signature padding checks
 
| RSA signature padding checks
Line 1,013: Line 1,026:  
Combined with a other minor bugs in the sysmodule, it is possible to take over [[SM]] with this nevertheless difficult-to-exploit vulnerability.
 
Combined with a other minor bugs in the sysmodule, it is possible to take over [[SM]] with this nevertheless difficult-to-exploit vulnerability.
 
| Code execution under [[SM]], etc.
 
| Code execution under [[SM]], etc.
| None
+
| [[11.16.0-48]]
 
| [[11.14.0-46]]
 
| [[11.14.0-46]]
 
| July 2017
 
| July 2017
Line 1,141: Line 1,154:  
| October 25, 2016
 
| October 25, 2016
 
| [[User:Yellows8|Yellows8]]
 
| [[User:Yellows8|Yellows8]]
 +
|-
 +
| AM module APcert infoleak via 00000000.ctx files
 +
| Just after a download title is purchased from the eShop, the .ctx is in an initialized state of all FFs past the header. During download, the FF area is filled with the console APcert. Thus, it is possible to create a xorpad from the initial state and use it to decrypt the APcert filled state.
 +
| APcert contains the deviceID, which can beneficial in decrypting the movable.sed (since deviceID is mathmatically related to the LFCS).
 +
| None
 +
| [[11.16.0-49]]
 +
| August, 2022
 +
| March 17, 2023
 +
| zoogie
 
|-
 
|-
 
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].
 
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].
Line 1,368: Line 1,390:  
| November 14, 2016
 
| November 14, 2016
 
| [[User:Yellows8|Yellows8]]
 
| [[User:Yellows8|Yellows8]]
 +
|-
 +
| Pia vulns
 +
| [https://switchbrew.org/wiki/Switch_System_Flaws#Pia Originally discovered in Pia v5.x for Switch], these vulns are also present in earlier versions (v3.x/4.x/5.x, possibly earlier?) for 3DS (and Wii U too).
 +
Pia encryption generally wasn't used pre-Switch (sent packets are plaintext). 3DS is affected by all Pia vulns listed above except for LAN. The functionality for ParseLeaveMeshInvitation doesn't exist in 3DS Pia v3.9.2. Wii U is affected by all listed Pia vulns except for the LAN vulns.
 +
| See [https://switchbrew.org/wiki/Switch_System_Flaws#Pia here].
 +
| Unfixed on 3DS/Wii U
 +
| "[SDK+Nintendo:PIA_5_4_3]"
 +
| 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]]
 
|}
 
|}
39

edits