Changes

Jump to navigation Jump to search
9,463 bytes added ,  22:53, 28 April 2023
→‎Hardware: be more precise about the fault timing requirements
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 311: Line 311:  
| May 19, 2017
 
| May 19, 2017
 
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]
 
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]
 +
|-
 +
| safecerthax
 +
| O3DS & O2DS SAFE_FIRM is still vulnerable to the PXIAM:ImportCertificates flaw fixed in [[5.0.0-11]] and to SSLoth fixed in [[11.14.0-46]]. It makes it possible to spoof the official NUS update server and remotely trigger the vulnerability in SAFE_FIRM.
 +
| Remote Arm9 code execution in O3DS/O2DS SAFE_FIRM
 +
| None
 +
| [[11.14.0-46|11.14.0-X]]
 +
| 2020
 +
| December 18, 2020
 +
| [[User:Nba_Yoh|MrNbaYoh]]
 
|-
 
|-
 
| twlhax: Corrupted SRL header leads to memory overwrite
 
| twlhax: Corrupted SRL header leads to memory overwrite
Line 326: Line 335:  
| August 11, 2018
 
| August 11, 2018
 
| smea
 
| smea
 +
|-
 +
| agbhax
 +
| This is the same issue as twlhax above. Legacy FIRMs share the same OS code (Arm9-side OS, Arm11 kernel), and therefore, the outdated AGB_FIRM can be tricked into executing the still vulnerable PrepareArm9ForTwl function.
 +
| ARM9 code execution (whilst still in 3DS mode)
 +
| None
 +
| [[11.14.0-46|11.14.0-X]]
 +
|
 +
| December 17, 2020
 +
| Everyone
 
|-
 
|-
 
| safefirmhax
 
| safefirmhax
Line 569: Line 587:  
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)
 
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)
 
|-
 
|-
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])
+
| [[Application_Manager_Services_PXI|PXIAM]]:ImportCertificates (See also [[Application_Manager_Services|this]])
 
| When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with [[5.0.0-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.
 
| When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with [[5.0.0-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.
 
| ARM9 code execution
 
| ARM9 code execution
Line 636: Line 654:  
!  Timeframe this was discovered
 
!  Timeframe this was discovered
 
!  Discovered by
 
!  Discovered by
 +
|-
 +
| [[SVC|svcUnbindInterrupt]] double free when irqId = 15
 +
| svcBindInterrupt and svcUnbindInterrupt give special treatment to irqId 15 (FIQ helper): the access control list is bypassed and the provided KInterruptEvent (event or semaphore, via handle) is stored inside a singleton static object after having its refcount increased by 1.
 +
 +
svcUnbindInterrupt assumes that the user-provided handle is what is stored in the singleton and will decref the user-provided KInterruptEvent twice, causing a use-after-free if the attacker didn't actually provide an handle to the same event or semaphore.
 +
 +
This was "fixed" on [[11.14.0-46|11.14.0-X]] by preventing irqId 15 to be bound on retail units altogether (in both functions).
 +
| Arm11 kernel code execution
 +
| [[11.14.0-46|11.14.0-X]] (only on retail units)
 +
| [[11.14.0-46|11.14.0-X]]
 +
| 2019
 +
| [[User:TuxSH|TuxSH]], maybe others
 +
|-
 +
| [[SVC|svcKernelSetState]] op=3 could map the NULL page
 +
| svcKernelSetState op=3 param1=1 maps the firmlaunch parameters page to the user-specified VA.
 +
 +
It had previously no check, allowing the attacker to map data at VA 0.
 +
 +
Starting from [[11.14.0-46|11.14.0-X]], the VA must be in the standard 0x10000000-0x14000000 address range.
 +
| Mapping the NULL page (as RW) to leverage other kernel vulnerabilities
 +
| [[11.14.0-46|11.14.0-X]]
 +
| [[11.14.0-46|11.14.0-X]]
 +
| 2019
 +
| [[User:TuxSH|TuxSH]]
 +
|-
 +
| [[SVC|svcMapProcessMemory]] can map the NULL page
 +
| svcMapProcessMemory's destination VA is unchecked.
 +
 +
By passing a big enough "size" parameter, an attacker can map chunks of data at VA 0 in the destination (caller) process.
 +
| Mapping the NULL page (as RW) to leverage other kernel vulnerabilities
 +
| None
 +
| [[11.14.0-46|11.14.0-X]]
 +
| 2020
 +
| [[User:TuxSH|TuxSH]]
 +
|-
 +
| Resource limit use-after-free
 +
| When assigning a KResourceLimit to a KProcess, the reslimit's refcounter doesn't get incremented. This essentially means all KResourceLimit get freed if pm gets somehow terminated.
 +
 +
It turns out it is possible to ask pm (via ns:s or pm:app) to terminate itself along all other KIPs simply by passing TID 0004000100001000.
 +
 +
Calling [[SVC|svcGetResourceLimit]] afterwards triggers a use-after-free. This is rather difficult to exploit, however: there is one slot left in the reslimit slabheap. An attacker either has to map the NULL page as R(W)X (svcControlProcessMemory vuln fixed on [[11.8.0-41|11.8.0-X]]), or use one of the map-null exploits above while having access to svcCreateResourceLimit (with the only one that is easy enough to use in that context having been fixed on [[11.14.0-46|11.14.0-X]], anyway).
 +
| Arm11 kernel code execution
 +
| None (although near impossible to exploit on [[11.14.0-46|11.14.0-X]])
 +
| [[11.14.0-46|11.14.0-X]]
 +
| 2020
 +
| [[User:TuxSH|TuxSH]]
 
|-
 
|-
 
| [[SVC|svcSetProcessIdealProcessor]] reference count overflow and therefore use-after-free.
 
| [[SVC|svcSetProcessIdealProcessor]] reference count overflow and therefore use-after-free.
Line 934: Line 998:  
| [[User:Yellows8|Yellows8]]
 
| [[User:Yellows8|Yellows8]]
 
|-
 
|-
| [[SM]] out-of-bounds BSS write (table 1 entry too small)
+
| Useless [[SM]] off-by-one write
 
| After accepting a new session, [[SM]] writes a (handler ID (0 for srv: sessions (max. 64), 1 for the srv:pm one), pointer to session context structure in BSS) pair in a global array. However that array is only 64-entry-big instead of 65 (as it ought to be), and no bound check is done in that regard.
 
| After accepting a new session, [[SM]] writes a (handler ID (0 for srv: sessions (max. 64), 1 for the srv:pm one), pointer to session context structure in BSS) pair in a global array. However that array is only 64-entry-big instead of 65 (as it ought to be), and no bound check is done in that regard.
   Line 943: Line 1,007:  
|
 
|
 
|
 
|
 +
|-
 +
| smpwn
 +
| When registering a new service (or "port"), no bound checks are done on the service table. One can simply call RegisterPort repeatedly to overflow that table: it will overflow into the command replay structure.
 +
 +
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.
 +
| [[11.16.0-48]]
 +
| [[11.14.0-46]]
 +
| July 2017
 +
| [[User:TuxSH|TuxSH]] (independently), presumably ichfly before
 +
|-
 +
| PXI cmdbuf buffer overrun
 +
| Like its Arm9 counterpart, before version [[5.0.0-11|5.0.0-X]], the PXI system module did not check the command sizes. This makes it possible to get ROP under the PXI sysmodule from a pwned Process9.
 +
safecerthax uses it to takeover the Arm11 processor after directly getting remote code execution on the Arm9 side. Though, is useless in classic Arm11 -> Arm9 chains.
 +
| ROP under [[PXI_Services|PXI]]
 +
| probably [[5.0.0-11|5.0.0-X]]
 +
| [[11.14.0-46]]
 +
|
 +
| Everyone
 
|}
 
|}
   Line 956: Line 1,039:  
!  Timeframe this was added to wiki
 
!  Timeframe this was added to wiki
 
!  Discovered by
 
!  Discovered by
 +
|-
 +
| [[CSND_Services|CSND]] sysmodule crash due to out of bounds parameters.
 +
| The CSND command [[CSND:PlaySoundDirectly|PlaySoundDirectly (0x00040080)]] takes a channel ID as the first parameter. Any value outside the range [0-3] makes the system module become unstable or crash due to an out of bounds memory read.
 +
| Out of bounds memory read, probably not exploitable. More research needed.
 +
| None
 +
| [[11.14.0-46]]
 +
| January 2021
 +
| January 22, 2021
 +
| [[User:PabloMK7|PabloMK7]]
 +
 +
|-
 +
| SSLoth: [[SSL_Services|SSL]] sysmodule improper certificate verification
 +
| Initially, the SSL sysmodule missed the R_VERIFY_RES_SIGNATURE entry in the "resource list" provided to the RSA BSAFE library. Consequently, it did not check signatures when validating certificate chains.
 +
| Forge fake certificates, spoof official servers and perform MitM attacks on SSL/TLS connections.
 +
| [[11.14.0-46]]
 +
| [[11.14.0-46]]
 +
| 2020
 +
| December 18, 2020
 +
| [[User:Nba_Yoh|MrNbaYoh]], shutterbug2000 (independently)
 +
 +
|-
 +
| [[CECD_Services|CECD:ndm]] SetNZoneMacFilter (cmd8) stack smashing
 +
| The length of the mac filter is not checked before being copied to a fixed-size buffer on stack.
 +
| ROP under [[CECD_Services|CECD]] sysmodule
 +
| None
 +
| [[11.13.0-45]]
 +
| 2020
 +
| July 20, 2020
 +
| [[User:Nba_Yoh|MrNbaYoh]]
 +
|-
 +
| [[CECD_Services|CECD]] message box access
 +
| CECD allows any process to write to any message box, thus allowing to write Streetpass data to the message box of any title.
 +
| Install exploit for any title having a vulnerability in Streetpass data parsers (see CTRSDK Streetpass parser vulnerability).
 +
| None
 +
| None
 +
| ?
 +
| June 1, 2020
 +
| Everyone?
 +
|-
 +
| [[CECD_Services|CECD]] packet type 0x32/0x34 stack-smashing
 +
| When parsing Streetpass packets of type 0x32 and 0x34, CECD copies a list without checking the number of entries. The packet length is limited to 0x400 bytes, which is not enough to reach the end of the stack frame and overwrite the return address. However, the buffer located just next to the packet buffer is actually filled with data sent just before, hence actually allowing to overwrite the whole stack frame with conrolled data.
 +
| RCE under [[CECD_Services|CECD]]
 +
| [[11.12.0-44]]
 +
| [[11.12.0-44]]
 +
| Summer 2019
 +
| June 1, 2020
 +
| [[User:Nba_Yoh|MrNbaYoh]]
 +
|-
 +
| [[CECD_Services|CECD]] TMP files parser multiple vulnerabilities
 +
| When parsing "TMP_XXX" files, CECD does not check the number of messages contained in the file. This allows to overflow the array of message pointers and message sizes on the stack. Pointers aren't controlled and sizes are limited (one cannot send gigabytes of data...), yet the last message size can be an arbitrary value (the current message pointer goes outside the file buffer and the parsing loop is broken). This allows to overwrite a pointer to a lock object on the stack and decrement an arbitrary value in memory. One can change the TMP file parsing mode to have CECD trying to free all the message buffers after parsing the next TMP file. The parsing mode is usually restored when parsing a new TMP file, but an invalid TMP file allows to make a function returns an error before the mode is restored , the return value is not checked and the parser consider the file valid. The message pointers and sizes arrays are not updated though, this is not a problem since the previous TMP file buffer is reused for the new TMP file in memory. Thus the message pointers actually points to controlled data. This allows to get a bunch of fake heap chunk freed, thus a bunch of unsafe unlink arbitrary writes.
 +
| RCE under [[CECD_Services|CECD]]
 +
| [[11.12.0-44]]
 +
| [[11.12.0-44]]
 +
| Summer 2019
 +
| June 1, 2020
 +
| [[User:Nba_Yoh|MrNbaYoh]]
 
|-
 
|-
 
| [[Config_Services|CFG]]:CreateConfigInfoBlk integer underflow
 
| [[Config_Services|CFG]]:CreateConfigInfoBlk integer underflow
Line 965: Line 1,104:  
| November 24, 2018
 
| November 24, 2018
 
| [[User:Nba_Yoh|MrNbaYoh]]
 
| [[User:Nba_Yoh|MrNbaYoh]]
|-
   
|-
 
|-
 
| [[MP:SendDataFrame]] missing input array index validation
 
| [[MP:SendDataFrame]] missing input array index validation
Line 1,003: Line 1,141:  
| 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,026: Line 1,173:  
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.
 
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.
 
| ROP under NWM-module.
 
| ROP under NWM-module.
| [[11.4.0-37|11.4.0-X]]
+
| None (need to check, but CTRSDK heap code is vulnerable)
 
| [[9.0.0-20|9.0.0-X]]
 
| [[9.0.0-20|9.0.0-X]]
 
| April 10, 2016
 
| April 10, 2016
Line 1,075: Line 1,222:  
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].
 
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].
 
| ROP under HTTP sysmdule.
 
| ROP under HTTP sysmdule.
| [[11.4.0-37|11.4.0-X]]
+
| None
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])
+
| [[11.13.0-45|11.13.0-X]]
 
| Late 2015
 
| Late 2015
 
| March 22, 2016
 
| March 22, 2016
Line 1,095: Line 1,242:  
| [[SPI_Services|SPI]] service out-of-bounds write
 
| [[SPI_Services|SPI]] service out-of-bounds write
 
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.
 
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.
|  
+
| Code execution under spi sysmodule; access to [[CONFIG11_Registers|CFG11_GPUPROT]] and ultimately kernel code execution.
 
| None
 
| None
| [[9.5.0-22]]
+
| [[11.14.0-46]]
 
| March 2015
 
| March 2015
 
|  
 
|  
Line 1,198: Line 1,345:  
!  Timeframe this was discovered
 
!  Timeframe this was discovered
 
!  Discovered by
 
!  Discovered by
 +
|-
 +
| [[CECD_Services|CECD]] Streetpass message exheader stack-smashing
 +
| When parsing streetpass messages, "nn::cec::CTR::Message::InputMessage" calls "nn::cec::CTR::Message::SetExHeaderWithoutCalc" for each exheader entry in the input message. The number of entries should not exceed 16 but remains unchecked, leading to a stack-buffer-overflow.
 +
| ROP under any application parsing Streetpass messages
 +
Remote code execution under [[CECD_Services|CECD]]
 +
| [[11.12.0-44]]
 +
|
 +
| 2019
 +
| [[User:Nba_Yoh|MrNbaYoh]]
 
|-
 
|-
 
| [[NWM_Services|UDS]] beacon additional-data buffer overflow
 
| [[NWM_Services|UDS]] beacon additional-data buffer overflow
1

edit

Navigation menu