1
edit
Changes
Jump to navigation
Jump to search
Line 105:
Line 105: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 140:
Line 169: − + Line 155:
Line 184: − + Line 182:
Line 211: − + Line 236:
Line 265: + + + + + + + + + Line 242:
Line 280: − + + + + + + + + + + + + Line 319:
Line 368: − + Line 329:
Line 378: − + Line 469:
Line 518: + + + + + + + + + + + + + + + + + + + + + + + + + − + − + Line 486:
Line 560: − + Line 496:
Line 570: − + Line 506:
Line 580: − + Line 528:
Line 602: − + Line 544:
Line 618: − + Line 741:
Line 815: + + + + + + + + + + Line 754:
Line 838: + + + + + + + + + + + + + + + + + + + + + + + + + + Line 788:
Line 898: − + Line 837:
Line 947: − + Line 910:
Line 1,020: − +
→Kernel11 just a lame bug I guess
| 2015
| 2015
| [[User:Yellows8|Yellows8]]
| [[User:Yellows8|Yellows8]]
|-
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] can be configured by anything with access to it to allow the GPU to access the entire AXIWRAM+FCRAM. For example, this is an issue for any sysmodule that gets exploited and has access to this register memory-page(include one that's listed below).
See also "kernelhax via gspwn" below.
| None
| New3DS
| February 7, 2017
| [[User:Yellows8|Yellows8]]
|-
| sighax: Boot9 improper PKCS #1 v1.5 signature validation
| The [[Flash_Filesystem|FIRM partitions]] are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding. Boot9, however, does improper validation of the padding in three ways:
# Boot9 permits block type 02, meant for encrypted messages, to be used for signatures. Only 01, for signatures, should have been permitted. As a result, a signature block is not required to have a long string of FF bytes as padding, but rather any random values suffice. While correct for encryption, this severely lessens security of signatures.
# Boot9 does not require that the length of the padding fill out the signature block completely. As a result, there is considerable freedom in the layout of a signature.
# Boot9 fails to do bounds checking in its parsing of the DER-encoded hash algorithm type and hash value; the length values given in DER are permitted to point outside the signature block.
Flaw 3 allows the DER encoding to be such that boot9 believes that the signature's hash value is outside the range of the block itself, somewhere on the stack. This can be pointed at the correct hash value it computes. Boot9 then memcmp's the calculated hash against itself, and thinks that the hash is valid.
When all three flaws are combined, a brute force in a reasonable amount of time can find a signature that passes all checks.
| None
| New3DS
| July 2015
| [[User:Derrek|derrek]]
|-
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O
| [[Bootloader|Boot9]]'s FIRM loading blacklists Boot9 data regions, but forgets to do other important regions, including Memory-mapped I/O. Combined with sighax, by loading a malicious FIRM section to MMIO, one can get Boot9/Boot11 code execution.
| None
| New3DS
| 2015(?)
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|SciresM]] independently (January 2017).
|}
|}
| arm9loaderhax given existing ARM9 code execution
| arm9loaderhax given existing ARM9 code execution
| None
| None
| [[11.2.0-35|11.2.0-X]]
| [[11.3.0-36|11.3.0-X]]
| Early 2016
| Early 2016
| 27 September 2016
| 27 September 2016
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)
| None
| None
| [[11.2.0-35|11.2.0-X]]
| [[11.3.0-36|11.3.0-X]]
| ~April 2015, implemented in May 2015
| ~April 2015, implemented in May 2015
| 13 January 2016
| 13 January 2016
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata
| None
| None
| [[11.2.0-35|11.2.0-X]]
| [[11.3.0-36|11.3.0-X]]
| March, 2015
| March, 2015
|
|
| January 20, 2016
| January 20, 2016
| [[User:Jakcron|jakcron]]
| [[User:Jakcron|jakcron]]
|-
| Factory firmware is vulnerable to sighax
| During the 3DS's development, presumably boot9 was written (including the sighax) vulnerability. This vulnerability is also present in factory firmware (and earlier, including 0.11). This was fixed in version 1.0.0-0.
| Deducing the mechanics of the sighax vulnerability in boot9 without having boot9 prot. Arm9 code execution on factory/earlier firmware.
| [[1.0.0-0|1.0.0-X]]
| [[1.0.0-0|1.0.0-X]]
| May 9, 2017
| May 19, 2017
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]
|-
|-
| safefirmhax
| safefirmhax
The fix for firmlaunch-hax was only applied to NATIVE_FIRM in [[9.5.0-22|9.5.0-X]], leaving SAFE_FIRM exploitable. With ARM11-kernel execution, one can trigger FIRM-launch in to SAFE_FIRM, do Kernel9 <=> Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead.
The fix for firmlaunch-hax was only applied to NATIVE_FIRM in [[9.5.0-22|9.5.0-X]], leaving SAFE_FIRM exploitable. With ARM11-kernel execution, one can trigger FIRM-launch in to SAFE_FIRM, do Kernel9 <=> Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead.
| ARM9 code execution
| ARM9 code execution
| None
| [[11.3.0-36|11.3.0-X]]
|
|
| 2012-2013?
| 2012-2013?
| Wiki: January 2, 2017
| Wiki: January 2, 2017
| Everyone
|-
| safefirmhax 1.1
| Nintendo's original safefirmhax fix was flawed -- they added a global boolean that got set to true whenever a non-sysmodule title got launched (except for a hardcoded repair title id), and panic()'d if that boolean was true to prevent launching safefirm after hax was active. However, because the boolean was initially false after firmlaunch -- With ARM11-kernel execution, one could FIRM-launch into NATIVE_FIRM, and then immediately FIRM-launch again into SAFE_FIRM early in NATIVE_FIRM boot before the boolean got set to true to repeat the safehax attack.
This was fixed by adding additional CFG9_BOOTENV checks to firmlaunch code in 11.4.
| ARM9 code execution
| [[11.4.0-37|11.4.0-X]]
|
| safefirmhax fix
| Wiki: April 10, 2017
| Everyone
| Everyone
|-
|-
| See description.
| See description.
| None
| None
| [[11.2.0-35|11.2.0-X]]
| [[11.3.0-36|11.3.0-X]]
| March 15, 2015
| March 15, 2015
| December 29, 2015
| December 29, 2015
| Reusing the previously used keyslot, for crypto with PS.
| Reusing the previously used keyslot, for crypto with PS.
| None
| None
| [[11.2.0-35|11.2.0-X]]
| [[11.3.0-36|11.3.0-X]]
| Roughly the same time(same day?) as firmlaunch-hax.
| Roughly the same time(same day?) as firmlaunch-hax.
| December 29, 2015
| December 29, 2015
! Timeframe this was discovered
! Timeframe this was discovered
! Discovered by
! Discovered by
|-
| [[SVC|svcSetProcessIdealProcessor]] reference count overflow and therefore use-after-free.
| The SVC receive two arguments: handle and idealprocessor. The handle is used to get the KProcess object and the KProcess->refCnt gets incremented,later the function check if the KProcess->mem_type != BASE and if yes, it checks for idealprocessor == 2 or idealprocessor != 3. The problem here is that if you pass the idealprocessor = 3 it won't meet any condition and return the error 0xD9001BEA without decrement the reference count.
It can be abused to overflow the KProcess reference count that will lead to an Use-after-free.
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free.
|
| [[11.6.0-39|11.6.0-X]]
| November 2, 2017
| [[User:st4rk|st4rk]]
|-
| [[SVC|svcGetThreadList]] process reference leak
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable
|
| [[11.3.0-36|11.3.0-X]]
| April 3, 2017
| [[User:TuxSH|TuxSH]]
|-
| kernelhax via gspwn
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]]. Since it's 0 at hard-boot, this allowed the GPU to access the entire FCRAM + AXIWRAM.
| Entire FCRAM+AXIWRAM R/W.
| [[3.0.0-5|3.0.0-X]]
|
| February 7, 2017
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] partly
|-
|-
| fasthax
| fasthax
| When a KTimer is created in pulse mode, the kernel calls a virtual function to reset the timer each time it pulses. The scheduler is locked for that core to avoid race conditions, but another core can call CloseHandle on the timer and free it, leading to a UAF vtable call.
| When a KTimer is created in pulse mode, the kernel calls a virtual function to reset the timer each time it pulses. The scheduler is locked for that core to avoid race conditions, but another core can call CloseHandle on the timer and free it, leading to a UAF vtable call.
| See description.
| See description.
| None
| [[11.3.0-36|11.3.0-X]]
| [[11.2.0-35|11.2.0-X]]
| [[11.3.0-36|11.3.0-X]]
| May 2016
| May 2016
| nedwill
| nedwill
| See description.
| See description.
| None
| None
| [[11.2.0-35|11.2.0-X]]
| [[11.3.0-36|11.3.0-X]]
| November 26, 2016
| November 26, 2016
| [[User:Yellows8|Yellows8]]
| [[User:Yellows8|Yellows8]]
| See description.
| See description.
| None
| None
| [[11.2.0-35|11.2.0-X]]
| [[11.3.0-36|11.3.0-X]]
| November 2016
| November 2016
| [[User:Yellows8|Yellows8]]
| [[User:Yellows8|Yellows8]]
|
|
| None
| None
| [[11.2.0-35|11.2.0-X]]
| [[11.3.0-36|11.3.0-X]]
| 2012
| 2012
| Everyone
| Everyone
| Access to all [[Services_API|services]], ControlMemory on any given mem-region.
| Access to all [[Services_API|services]], ControlMemory on any given mem-region.
| None
| None
| [[11.2.0-35|11.2.0-X]]
| [[11.3.0-36|11.3.0-X]]
| 2012 maybe?
| 2012 maybe?
|
|
|
|
| None
| None
| [[11.2.0-35|11.2.0-X]]
| [[11.3.0-36|11.3.0-X]]
|
|
|
|
| May 19(?)-20, 2015
| May 19(?)-20, 2015
| [[User:Yellows8|Yellows8]]
| [[User:Yellows8|Yellows8]]
|-
| [[SM]] out-of-bounds BSS write (table 1 entry too small)
| 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.
Unfortunately, as of [[11.4.0-37]], the overwritten fields are totally unused after their initialization by <code>__libc_init_array</code>.
| Not currently exploitable
| None
| [[11.4.0-37]]
|
|
|}
|}
! Timeframe this was added to wiki
! Timeframe this was added to wiki
! Discovered by
! Discovered by
|-
| [[MP:SendDataFrame]] missing input array index validation
| [[MP:SendDataFrame]] doesn't validate the input index at cmdreq[1], unless the function for flag=non-zero is executed. This is used to calculate the following, without validating the index at all: someptr = stateptr + (index*0x924) + somestateoffset.
After validating some flags from someptr, when input_flag=0 the input buffer data is copied to someptr+someotheroffset+0x14 with the u16 size loaded from someptr+someotheroffset.
With a large input index someptr could be setup to be at a <target address>, for overwriting memory.
This is probably difficult to exploit.
|
| None
| [[8.0.0-18]](MP-sysmodule v2048)
| January 22, 2017
| January 22, 2017
| [[User:Yellows8|Yellows8]]
|-
| [[MP_Services|MP]] cmd1 out-of-bounds handle read
| MP-sysmodule handles the input parameter for cmd1 as a s32. It checks for >=16, but not <0. With <16 it basically does the following(array of entries 4-bytes each): *outhandle = ((Handle*)(stateptr+offsetinstate))[inputindex].
Hence, this can be used to load any handle in MP-sysmodule memory. MP doesn't really have any service handles of interest however(can be obtained from elsewhere too).
| Reading any handle in MP-sysmodule memory.
| None
| [[8.0.0-18]](MP-sysmodule v2048)
| January 21, 2017
| January 22, 2017
| [[User:Yellows8|Yellows8]]
|-
|-
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|Ex]])
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|Ex]])
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.
| None
| [[11.4.0-37|11.4.0-X]]
| [[9.0.0-20|9.0.0-X]]
| [[9.0.0-20|9.0.0-X]]
| April 10, 2016
| April 10, 2016
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.
| None
| [[11.4.0-37|11.4.0-X]]
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])
| Late 2015
| Late 2015
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).
FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2DC00000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 with the default memory-layout on Old3DS/New3DS.
FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2D800000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 (0x800000 with New3DS) with the default memory-layout on Old3DS/New3DS. With [[11.3.0-36|11.3.0-X]] the cutoff now varies due to the new [[SVC]] 0x59. The New3DS "normal"(non-APPLICATION) cutoff was changed to 0x2D000000 due to the new [[SVC]] 0x59.
| User-mode code execution.
| User-mode code execution.
| None
| None