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]] |
| | January 2018 | | | January 2018 |
| | April 29, 2018 | | | April 29, 2018 |
− | | [[User:Hexkyz|hexkyz]], probably others (independently). | + | | [[User:Hexkyz|hexkyz]], [[User:Rei|Reisyukaku]] (independently), probably others (independently). |
| + | |- |
| + | | Stack smash in TSEC firmware's KeygenLdr |
| + | | 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 in Heavy Secure mode. |
| + | | None |
| + | | [[8.0.1]] |
| + | | Early 2018 |
| + | | May 21, 2019 |
| + | | Everyone (independently). |
| |- | | |- |
| | pk1ldrhax | | | pk1ldrhax |
Line 156: |
Line 165: |
| | November 20, 2018 | | | November 20, 2018 |
| | Everyone | | | Everyone |
− | |-
| |
| |} | | |} |
| | | |