1Advisory TFMV-1
2===============
3
4+----------------+-------------------------------------------------------------+
5| Title          | NS world may cause the CPU to perform an unexpected return  |
6|                | operation due to unsealed stacks.                           |
7+================+=============================================================+
8| CVE ID         | CVE-2020-16273                                              |
9+----------------+-------------------------------------------------------------+
10| Date           | 16 October 2020                                             |
11+----------------+-------------------------------------------------------------+
12| Versions       | All versions up to and including TF-M v1.1                  |
13| Affected       |                                                             |
14+----------------+-------------------------------------------------------------+
15| Configurations | All                                                         |
16+----------------+-------------------------------------------------------------+
17| Impact         | Most likely a crash in secure world with a very low         |
18|                | likelihood of hijacking secure world execution flow via a   |
19|                | separate vulnerability.                                     |
20+----------------+-------------------------------------------------------------+
21| Fix Version    | commit `92e46a3abd0e328fac29ccd1cf161cd482397567`_          |
22+----------------+-------------------------------------------------------------+
23| Credit         | Matvey Mukha                                                |
24+----------------+-------------------------------------------------------------+
25
26Background
27----------
28
29When the Non-Secure world returns to Secure after a callback (FNC_RETURN) or
30Non-Secure interrupt handling (EXC_RETURN), the hardware pops the secure return
31address and RET_PSR from the respective secure stack. The hardware performs a
32set of integrity checks at this point and will raise a fault if the checks
33fail. There is a potential vulnerability if the NS attempts a wrong FNC_RETURN
34or EXC_RETURN and causes the PE to pop from the unexpected stack. Please
35refer to `ARMv8-M Secure stack sealing advisory notice`_ for more
36details on the vulnerability.
37
38To prevent such an attack, the architecture expects the secure software to
39`seal` the stacks. The `ARMv8-M ARM`_ states that the stack should be sealed
40with the special value, 0xFEF5EDA5 (informative IGJGL).
41
42Both the MSP_S and the PSP_S stacks need to be sealed to mitigate stack
43underflow attacks and this is not done currently in TF-M.
44
45Impact
46------
47
48This section analyses the impact of this vulnerability on the upstream
49TF-M implementation.
50
51All requests coming in from the Non-Secure world uses ARM_LIB_STACK as the
52PSP_S and then switches to MSP_S as part of SPM scheduling. The MSP_S is fully
53unwound when the scheduled partition is executing. All partitions run using
54the PSP_S and this stack can be separate for each partition or be a common
55stack depending on whether TF-M is in library mode or IPC model. When the
56partition execution using PSP_S switches to non-secure world due to a
57non-secure interrupt or a non-secure callback invocation, the non-secure
58world on return back to secure can use a fake EXC_RETURN or FNC_RETURN
59operation to trigger an MSP_S stack underflow, and the CPU could fetch
60the return PC and PSR from the memory just above MSP_S stack (stack grows
61from higher to lower address).
62
63The memory above MSP_S is the ARM_LIB_STACK (as described by
64tfm_common_s.sct/ld), which because of overlaying or zero initialization
65is most likely to be initialized memory for most platforms. This is the stack
66used to run the initialization code of TF-M and usually there will some
67unused free space in the stack. Any underflow of MSP_S will be into this stack
68and hence is likely to be a deterministic crash given that this memory is
69initialized. In theory, a separate vulnerability that allows an attacker to
70control the memory above MSP_S in concert with this vulnerability could
71enable an attacker to hijack the secure world execution flow but the
72likelihood of that is very low.
73
74Through analysing TF-M specific initialization and execution flow, we have
75not found any scenario in TF-M in which Non-secure world can fake a return
76operation back to secure world and cause underflow of PSP_S.
77
78As described in the white paper, de-privileged interrupt handling is
79also vulnerable to this problem. The Library mode of TF-M uses de-privileged
80interrupt handling and does not allow non-secure interrupt to pre-empt the
81secure interrupt handling. But if the de-privileged handler makes a
82Non-Secure callback then there is a chance that Non-Secure world could
83return back to Secure world via a fake FNC_RETURN. Under certain
84conditions, this can force the CPU to use the 2 words on top of stack as
85return PC and PSR. Sealing the top of MSP_S before switching to PSP_S as
86part of de-privileged interrupt handling mitigates this vulnerability.
87
88The interrupt handling in IPC model uses PSA signal to signal the partition
89and does not use de-privileged interrupt handling mechanism. The PSA signal
90gets handled by the partition when it is scheduled to run by the SPM. Hence
91during interrupt handling in IPC model, there is no additional threat caused
92by this vulnerability, compared to regular partition execution.
93
94Conclusion
95----------
96
97Overall, from analysis of upstream TF-M implementation, the severity of this
98vulnerability is low, given that the values popped out from secure stack
99(either via underflow of MSP_S or from top of MSP_S stack in de-privileged
100interrupt handling) cannot be influenced by the Non Secure world. To mitigate
101the risk completely, the fix in TF-M is to follow the recommendation in
102`ARMv8-M ARM`_ which is to seal the base of both handler mode stack (MSP_S)
103and thread stacks (PSP_S) and, in case of library mode, also seal the top
104of MSP_S before handing control over to de-privileged interrupt handler.
105
106
107.. _ARMv8-M ARM: https://developer.arm.com/documentation/ddi0553/latest
108.. _ARMv8-M Secure stack sealing advisory notice: https://developer.arm.com/support/arm-security-updates/armv8-m-stack-sealing
109.. _92e46a3abd0e328fac29ccd1cf161cd482397567: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=92e46a3abd0e328fac29ccd1cf161cd482397567
110
111--------------
112
113*Copyright (c) 2020, Arm Limited. All rights reserved.*
114