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.*
