diff options
author | Soby Mathew <soby.mathew@arm.com> | 2020-07-28 13:06:55 +0100 |
---|---|---|
committer | Soby Mathew <soby.mathew@arm.com> | 2020-10-16 18:14:46 +0100 |
commit | 32e005877e656812a654b4e5cbc8abaa3df3064c (patch) | |
tree | 3be398e2b8f0421156ad457679bdd445b1e8bb22 | |
parent | 92e46a3abd0e328fac29ccd1cf161cd482397567 (diff) | |
download | trusted-firmware-m-32e005877e656812a654b4e5cbc8abaa3df3064c.tar.gz |
TFMV-1: Add Stack seal advisory
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
Change-Id: Ifbadc2d59cfb91e3ae09910a270d2358e378b3e6
-rw-r--r-- | docs/reference/security_advisories/index.rst | 12 | ||||
-rw-r--r-- | docs/reference/security_advisories/stack_seal_vulnerability.rst | 113 |
2 files changed, 125 insertions, 0 deletions
diff --git a/docs/reference/security_advisories/index.rst b/docs/reference/security_advisories/index.rst new file mode 100644 index 0000000000..85119084e2 --- /dev/null +++ b/docs/reference/security_advisories/index.rst @@ -0,0 +1,12 @@ +Security Advisories +=================== + +.. toctree:: + :maxdepth: 1 + :glob: + + * + +-------------- + +*Copyright (c) 2020, Arm Limited. All rights reserved.* diff --git a/docs/reference/security_advisories/stack_seal_vulnerability.rst b/docs/reference/security_advisories/stack_seal_vulnerability.rst new file mode 100644 index 0000000000..2bf9d1a254 --- /dev/null +++ b/docs/reference/security_advisories/stack_seal_vulnerability.rst @@ -0,0 +1,113 @@ +Advisory TFMV-1 +=============== + ++----------------+-------------------------------------------------------------+ +| Title | NS world may cause the CPU to perform an unexpected return | +| | operation due to unsealed stacks. | ++================+=============================================================+ +| CVE ID | CVE-2020-16273 | ++----------------+-------------------------------------------------------------+ +| Date | 16 October 2020 | ++----------------+-------------------------------------------------------------+ +| Versions | All versions up to and including TF-M v1.1 | +| Affected | | ++----------------+-------------------------------------------------------------+ +| Configurations | All | ++----------------+-------------------------------------------------------------+ +| Impact | Most likely a crash in secure world with a very low | +| | likelihood of hijacking secure world execution flow via a | +| | separate vulnerability. | ++----------------+-------------------------------------------------------------+ +| Fix Version | commit `92e46a3abd0e328fac29ccd1cf161cd482397567`_ | ++----------------+-------------------------------------------------------------+ +| Credit | Matvey Mukha | ++----------------+-------------------------------------------------------------+ + +Background +---------- + +When the Non-Secure world returns to Secure after a callback (FNC_RETURN) or +Non-Secure interrupt handling (EXC_RETURN), the hardware pops the secure return +address and RET_PSR from the respective secure stack. The hardware performs a +set of integrity checks at this point and will raise a fault if the checks +fail. There is a potential vulnerability if the NS attempts a wrong FNC_RETURN +or EXC_RETURN and causes the PE to pop from the unexpected stack. Please +refer to `ARMv8-M Secure stack sealing advisory notice`_ for more +details on the vulnerability. + +To prevent such an attack, the architecture expects the secure software to +`seal` the stacks. The `ARMv8-M ARM`_ states that the stack should be sealed +with the special value, 0xFEF5EDA5 (informative IGJGL). + +Both the MSP_S and the PSP_S stacks need to be sealed to mitigate stack +underflow attacks and this is not done currently in TF-M. + +Impact +------ + +This section analyses the impact of this vulnerability on the upstream +TF-M implementation. + +All requests coming in from the Non-Secure world uses ARM_LIB_STACK as the +PSP_S and then switches to MSP_S as part of SPM scheduling. The MSP_S is fully +unwound when the scheduled partition is executing. All partitions run using +the PSP_S and this stack can be separate for each partition or be a common +stack depending on whether TF-M is in library mode or IPC mode. When the +partition execution using PSP_S switches to non-secure world due to a +non-secure interrupt or a non-secure callback invocation, the non-secure +world on return back to secure can use a fake EXC_RETURN or FNC_RETURN +operation to trigger an MSP_S stack underflow, and the CPU could fetch +the return PC and PSR from the memory just above MSP_S stack (stack grows +from higher to lower address). + +The memory above MSP_S is the ARM_LIB_STACK (as described by +tfm_common_s.sct/ld), which because of overlaying or zero initialization +is most likely to be initialized memory for most platforms. This is the stack +used to run the initialization code of TF-M and usually there will some +unused free space in the stack. Any underflow of MSP_S will be into this stack +and hence is likely to be a deterministic crash given that this memory is +initialized. In theory, a separate vulnerability that allows an attacker to +control the memory above MSP_S in concert with this vulnerability could +enable an attacker to hijack the secure world execution flow but the +likelihood of that is very low. + +Through analysing TF-M specific initialization and execution flow, we have +not found any scenario in TF-M in which Non-secure world can fake a return +operation back to secure world and cause underflow of PSP_S. + +As described in the white paper, de-privileged interrupt handling is +also vulnerable to this problem. The Library mode of TF-M uses de-privileged +interrupt handling and does not allow non-secure interrupt to pre-empt the +secure interrupt handling. But if the de-privileged handler makes a +Non-Secure callback then there is a chance that Non-Secure world could +return back to Secure world via a fake FNC_RETURN. Under certain +conditions, this can force the CPU to use the 2 words on top of stack as +return PC and PSR. Sealing the top of MSP_S before switching to PSP_S as +part of de-privileged interrupt handling mitigates this vulnerability. + +The interrupt handling in IPC mode uses PSA signal to signal the partition +and does not use de-privileged interrupt handling mechanism. The PSA signal +gets handled by the partition when it is scheduled to run by the SPM. Hence +during interrupt handling in IPC mode, there is no additional threat caused +by this vulnerability, compared to regular partition execution. + +Conclusion +---------- + +Overall, from analysis of upstream TF-M implementation, the severity of this +vulnerability is low, given that the values popped out from secure stack +(either via underflow of MSP_S or from top of MSP_S stack in de-privileged +interrupt handling) cannot be influenced by the Non Secure world. To mitigate +the risk completely, the fix in TF-M is to follow the recommendation in +`ARMv8-M ARM`_ which is to seal the base of both handler mode stack (MSP_S) +and thread stacks (PSP_S) and, in case of library mode, also seal the top +of MSP_S before handing control over to de-privileged interrupt handler. + + +.. _ARMv8-M ARM: https://developer.arm.com/documentation/ddi0553/latest +.. _ARMv8-M Secure stack sealing advisory notice: https://developer.arm.com/support/arm-security-updates/armv8-m-stack-sealing +.. _92e46a3abd0e328fac29ccd1cf161cd482397567: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=92e46a3abd0e328fac29ccd1cf161cd482397567 + +-------------- + +*Copyright (c) 2020, Arm Limited. All rights reserved.* |