516
edits
Changes
Jump to navigation
Jump to search
Line 85:
Line 85: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 120:
Line 169: − + Line 135:
Line 184: − + Line 162:
Line 211: − + Line 216:
Line 265: + + + + + + + + + Line 222:
Line 280: − + + + + + + + + + + + + Line 299:
Line 368: − + Line 309:
Line 378: − + Line 449:
Line 518: + + + + + + + + + + + + + + + + + + + + + + + + Line 458:
Line 551: − + Line 468:
Line 561: − + Line 478:
Line 571: − + Line 500:
Line 593: − + Line 516:
Line 609: − + Line 713:
Line 806: + + + + + + + + + + Line 726:
Line 829: + + + + + + + + + + + + + + + + + + + + + + + + + + Line 760:
Line 889: − + Line 809:
Line 938: − + Line 882:
Line 1,011: − +
→FIRM Sysmodules
|
|
| Everyone
| Everyone
|-
| RSA keyslots don't clear exponent when setting modulus
| The [[RSA_Registers|RSA keyslots]] are set by boot ROM to have four private RSA keys. The exponent value in the RSA registers is write-only and not readable.
However, when setting a keyslot's modulus, the RSA hardware leaves the exponent alone. This allows retrieving the exponent by doing a discrete logarithm of the output.
By setting the modulus to a prime number whose modular multiplicative order is "smooth" (that is, p-1 is divisible by only small prime numbers), discrete logarithms can be calculated quickly using the [[wikipedia:Pohlig-Hellman algorithm|Pohlig-Hellman algorithm]]. If the prime chosen is greater than the modulus, but the same bit size, the discrete logarithm is the private exponent.
This exploit's usefulness is limited: RSA keyslot 0 is only used in current firmware for deriving the 6.x save and 7.x NCCH keys, which were already known, and the other three keyslots are entirely unused. Additionally, with a boot ROM dump, this exploit is moot; these private keys are located in the protected ARM9 boot ROM.
| None
| New3DS
| March 2016
| [[User:Myria|Myria]]
|-
| Boot9 AES keyinit function issues
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].
| None
| BootROM issue.
| 2015
| [[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|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
| 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.
| [[11.3.0-36|11.3.0-X]]
| [[11.3.0-36|11.3.0-X]]
| May 2016
| nedwill
|-
|-
| ipctakeover
| ipctakeover
| 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