Line 1: |
Line 1: |
| + | Exploits are used to execute unofficial code (homebrew) on the Nintendo Switch. This page is a list of publicly known Switch system flaws. |
| | | |
− | System Flaws are used to execute unofficial code (homebrew) on the Nintendo Switch. This page is a list of known and public Switch System Flaws.
| + | For userland applications/applets flaws see [[Switch_Userland_Flaws|here]]. |
| | | |
− | =List of Switch System Flaws= | + | = System flaws = |
| + | == Hardware == |
| + | Flaws in this category pertain to the underlying hardware that powers the Switch. |
| + | |
| + | This includes components shared across Tegra based devices such as the [[TSEC]], the [[Security_Engine|Security Engine]], the [[GPU]] and so on. |
| | | |
− | == Hardware ==
| |
| {| class="wikitable" border="1" | | {| class="wikitable" border="1" |
| ! Summary | | ! Summary |
Line 13: |
Line 17: |
| ! Public disclosure timeframe | | ! Public disclosure timeframe |
| ! Discovered by | | ! Discovered by |
| + | |- |
| + | | CVE-2018-6242 (leveraged by the ShofEL2 and Fusée Gelée exploits) |
| + | | The USB software stack provided inside the boot instruction rom (IROM/bootROM) contains a copy operation whose length can be controlled by an attacker. By carefully constructing a USB control request, an attacker can leverage this vulnerability to copy the contents of an attacker-controlled buffer over the active execution stack, gaining control of the Boot and Power Management processor (BPMP) before any lock-outs or privilege reductions occur. This execution can then be used to exfiltrate secrets and to load arbitrary code onto the main CPU Complex (CCPLEX) "application processors" at the highest possible level of privilege (typically as the TrustZone Secure Monitor at PL3/EL3). |
| + | | Unknown (Tegra186 and Tegra214) |
| + | | HAC-001 (Tegra210) |
| + | | January 2018 |
| + | | April 23, 2018 |
| + | | [[User:Shuffle2|shuffle2]] and fail0verflow (originally),<br> [[User:Ktemkin|ktemkin]] and ReSwitched Team (independently),<br> [[User:Naehrwert|naehrwert]] (independently),<br> [[User:Hexkyz|hexkyz]] (independently),<br> st4rk with [[User:Shinyquagsire23|Shiny Quagsire]] and Dazzozo (independently),<br> and many others (independently). |
| |- | | |- |
| | GMMU DMA attack | | | GMMU DMA attack |
Line 19: |
Line 31: |
| [5.0.0+] Works around this hardware flaw by using memory pool partitioning. You can no longer escalate into sysmodules with GPU DMA because all their memory is allocated using heap that's carved out. | | [5.0.0+] Works around this hardware flaw by using memory pool partitioning. You can no longer escalate into sysmodules with GPU DMA because all their memory is allocated using heap that's carved out. |
| | None | | | None |
− | | HAC-001 | + | | HAC-001 (Tegra210) |
| | Summer 2017 | | | Summer 2017 |
| | December 28, 2017 | | | December 28, 2017 |
Line 31: |
Line 43: |
| This also bypasses the SBK protection of the bootROM: indeed, at warmboot, bootROM will always clear keyslot 0xE to prevent malicious code from saving the SBK. Moving the SBK to another keyslot in the saved context renders this protection moot. | | This also bypasses the SBK protection of the bootROM: indeed, at warmboot, bootROM will always clear keyslot 0xE to prevent malicious code from saving the SBK. Moving the SBK to another keyslot in the saved context renders this protection moot. |
| | None | | | None |
− | | HAC-001 | + | | HAC-001 (Tegra210) |
| | December 2017 | | | December 2017 |
| | January 20, 2018 | | | January 20, 2018 |
Line 46: |
Line 58: |
| However, the Security Engine flushes writes to the internal key tables immediately when AES_KEYTABLE_DATA is written -- this allows one to overwrite a single dword of a key at a time, and thus brute force the contents of keyslots in time (2^32 * 8) = 2^35 instead of 2^256. | | However, the Security Engine flushes writes to the internal key tables immediately when AES_KEYTABLE_DATA is written -- this allows one to overwrite a single dword of a key at a time, and thus brute force the contents of keyslots in time (2^32 * 8) = 2^35 instead of 2^256. |
| | None | | | None |
− | | HAC-001 | + | | HAC-001 (Tegra210) |
| | Theorized Summer 2017 due to suggestive syntax, confirmed April 9, 2018 | | | Theorized Summer 2017 due to suggestive syntax, confirmed April 9, 2018 |
| | April 9, 2018 | | | April 9, 2018 |
Line 52: |
Line 64: |
| |} | | |} |
| | | |
− | == System software == | + | == Software == |
− | | + | === Bootloader === |
| + | Flaws in this category pertain to any bootloader component such as the [[Package1#Package1ldr|package1ldr]], the [[Package1#Section_1|NX bootloader]] or the [[Package1#Section_0|warmboot binary]]. |
| | | |
− | === Stage 1 Bootloader ===
| |
| {| class="wikitable" border="1" | | {| class="wikitable" border="1" |
| |- | | |- |
Line 93: |
Line 105: |
| | December 31, 2017 | | | December 31, 2017 |
| | [[User:SciresM|SciresM]], [[User:motezazer|motezazer]] | | | [[User:SciresM|SciresM]], [[User:motezazer|motezazer]] |
| + | |- |
| + | | TSEC firmware compromises itself |
| + | | Package1ldr loads a firmware blob into TSEC early on boot. This piece of code runs on the TSEC in Authenticated Mode and has the sole purpose of generating the per-console TSEC key (see [[Cryptosystem]]). |
| + | |
| + | As a way to mitigate attacks, the TSEC firmware blob is split into 3 stages: [[TSEC#Stage_0|Stage 0]] which is unencrypted and unsigned, [[TSEC#Stage_1|Stage 1]] which is unencrypted but signed and [[TSEC#Stage_2|Stage 2]] which is encrypted and signed. |
| + | Stage 0 loads a static pre-generated signature into the Falcon's CPU crypto registers, loads Stage 1 into the Falcon's CODE region and jumps to it. Execution will proceed into Stage 1 in Authenticated Mode if, and only if, the loaded signature matches the one Falcon calculates internally for Stage 1. |
| + | |
| + | Among various things, Stage 1 will attempt to do a "backwards" security check by calculating a CMAC over Stage 0 and comparing it with a known hash stored in the TSEC firmware's key data (a small buffer stored after Stage 0's code). If the hashes don't match, execution aborts. |
| + | |
| + | Stage 1 stores the calculated Stage 0's CMAC in the stack, but forgets to clear it. Since the stack is located in Falcon's DATA region, loading the TSEC firmware blob and dumping the DATA region afterwards (via MMIO) will reveal the calculated hash. |
| + | This allows using Stage 1 as an oracle to generate a valid CMAC for arbitrary Stage 0 code. Replacing the CMAC in the TSEC firmware's key data region results in Stage 1 accepting any Stage 0 code, thus rendering this security measure useless. |
| + | |
| + | Additionally, since signed Falcon code can't be revoked without an hardware revision, an attacker can always reuse the flawed Stage 1 code even if a fix is issued. |
| + | | Running TSEC firmware's Stage 1 in a user controlled environment. Mostly useless, but may aid in side-channel attacks. |
| + | | None |
| + | | [[5.0.2]] |
| + | | January 2018 |
| + | | April 29, 2018 |
| + | | [[User:Hexkyz|hexkyz]] |
| |- | | |- |
| |} | | |} |
| | | |
| === TrustZone === | | === TrustZone === |
| + | Flaws in this category pertain exclusively to the [[Package1#Section_2|Secure Monitor]]. |
| + | |
| {| class="wikitable" border="1" | | {| class="wikitable" border="1" |
| |- | | |- |
Line 146: |
Line 179: |
| | | |
| === Kernel === | | === Kernel === |
| + | Flaws in this category pertain exclusively to the [[Package2#Section_0|HorizonOS Kernel]]. |
| + | |
| {| class="wikitable" border="1" | | {| class="wikitable" border="1" |
| |- | | |- |
Line 217: |
Line 252: |
| | | |
| === FIRM-package System Modules === | | === FIRM-package System Modules === |
| + | Flaws in this category pertain to any of the [[Package2#Section_1|built-in system modules]]. |
| + | |
| {| class="wikitable" border="1" | | {| class="wikitable" border="1" |
| |- | | |- |
Line 259: |
Line 296: |
| | December 30, 2017 | | | December 30, 2017 |
| | Everyone | | | Everyone |
− | |-
| |
| |- | | |- |
| | nspwn | | | nspwn |
Line 279: |
Line 315: |
| | | |
| === System Modules === | | === System Modules === |
| + | Flaws in this category pertain to any non-built-in system module. |
| + | |
| {| class="wikitable" border="1" | | {| class="wikitable" border="1" |
| |- | | |- |
Line 307: |
Line 345: |
| | April 2017 | | | April 2017 |
| | On exploit's fix in [[3.0.0]] | | | On exploit's fix in [[3.0.0]] |
− | | [[User:qlutoo|qlutoo]], Reswitched team (independently) | + | | [[User:qlutoo|qlutoo]], ReSwitched Team (independently) |
| |- | | |- |
| | Unchecked domain ID in common IPC code | | | Unchecked domain ID in common IPC code |