Nintendo Switch Brew

Switch System Flaws: Difference between revisions

← Older editNewer edit →
Rei (talk | contribs)
9 edits
No edit summary
Fixed
Line 120: Line 120:
|  [[User:SciresM|SciresM]], [[User:motezazer|motezazer]]
|  [[User:SciresM|SciresM]], [[User:motezazer|motezazer]]
|-
|-
|  TSEC firmware compromises itself
|  maconstack (TSEC firmware leaves MAC on the stack)
|  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]]).
|  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.
As a way to mitigate attacks, the TSEC firmware blob is split into 3 stages: [[TSEC_Firmware#Boot|Boot]] which is unencrypted and unsigned, [[TSEC_Firmware#KeygenLdr|KeygenLdr]] which is unencrypted but signed and [[TSEC_Firmware#Keygen|Keygen]] 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.
Boot loads a static pre-generated signature into the Falcon's CPU crypto registers, loads KeygenLdr into the Falcon's CODE region and jumps to it. Execution will proceed into KeygenLdr in Heavy Secure Mode if, and only if, the loaded signature matches the one Falcon calculates internally for KeygenLdr.


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.
Among various things, KeygenLdr will attempt to do a "backwards" security check by calculating a CMAC over Boot and comparing it with a known hash stored in the TSEC firmware's key data (a small buffer stored after Boot'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.
KeygenLdr stores the calculated Boot'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.
This allows using KeygenLdr as an oracle to generate a valid CMAC for arbitrary Boot code. Replacing the CMAC in the TSEC firmware's key data region results in KeygenLdr accepting any Boot 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.
Additionally, since signed Falcon code can't be revoked without an hardware revision, an attacker can always reuse the flawed KeygenLdr 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.
|  Running TSEC firmware's KeygenLdr in a user controlled environment.
|  None
|  None
|  [[5.0.2]]
|  [[5.0.2]]
Line 139: Line 139:
|  [[User:Hexkyz|hexkyz]], probably others (independently).
|  [[User:Hexkyz|hexkyz]], probably others (independently).
|-
|-
|  Keygenldr compromise
|  Stack smash in TSEC firmware's KeygenLdr
|  Given that we can control keyarea data (since its not authenticated) and boot (as mentioned in another exploit), as well as the fact NS and HS code share the same stack, we can use this to attack keygenldr. In keygenldr, theres a function that uses memcpy to copy over a payload to DMEM to verify it. These can be abused to smash the stack (which is also in DMEM) and write over the return addr of said function.
|  Given that we can control the [[TSEC_Firmware#Key_data|key data]] (which is not authenticated) and the [[TSEC_Firmware#Boot|Boot]] blob (see "maconstack"), as well as the fact Non-secure and Heavy Secure code share the same stack, we can use this to attack KeygenLdr. KeygenLdr uses memcpy to copy over a payload to DMEM to verify it, which can be abused to smash the stack (in DMEM) and write over the return address of said function.
|  ROP under keygenldr during HS mode.
|  ROP under KeygenLdr in Heavy Secure mode.
|  None
|  None
|  [[8.0.1]]
|  [[8.0.1]]
|  Spring 2019 (Earlier for some)
|  Early 2018
|  Spring 2019
|  May 21, 2019
|  [[User:Rei|Reisyukaku]] and [[User:Govanify|Govanify]]/ [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]].
|  Everyone (independently).
|-
|-
|  pk1ldrhax
|  pk1ldrhax
Line 165: Line 165:
|  November 20, 2018
|  November 20, 2018
|  Everyone
|  Everyone
|-
|}
|}


Retrieved from "https://switchbrew.org/wiki/Switch_System_Flaws"