From 7006f208b65676d08c70ecb0608895e544b593a1 Mon Sep 17 00:00:00 2001 From: Zelalem Date: Wed, 24 Feb 2021 19:20:09 -0600 Subject: [PATCH] docs(threat model): add TF-A threat model This is the first release of the public Trusted Firmware A class threat model. This release provides the baseline for future updates to be applied as required by developments to the TF-A code base. Signed-off-by: Zelalem Aweke Change-Id: I3c9aadc46196837679f0b1377bec9ed4fc42ff11 --- docs/_static/css/custom.css | 15 + docs/conf.py | 10 +- docs/index.rst | 3 +- docs/resources/diagrams/plantuml/tfa_dfd.puml | 66 ++ docs/threat_model/index.rst | 13 + docs/threat_model/threat_model.rst | 784 ++++++++++++++++++ 6 files changed, 889 insertions(+), 2 deletions(-) create mode 100644 docs/_static/css/custom.css create mode 100644 docs/resources/diagrams/plantuml/tfa_dfd.puml create mode 100644 docs/threat_model/index.rst create mode 100644 docs/threat_model/threat_model.rst diff --git a/docs/_static/css/custom.css b/docs/_static/css/custom.css new file mode 100644 index 000000000..f6f5fa08d --- /dev/null +++ b/docs/_static/css/custom.css @@ -0,0 +1,15 @@ +/* + * Copyright (c) 2021, Arm Limited. All rights reserved. + * + * SPDX-License-Identifier: BSD-3-Clause + */ + +/* + * Set the white-space property of tables to normal. + * With this setting sequences of whitespace inside + * a table will collapse into a single whitespace, + * and text will wrap when necessary. + */ +.wy-table-responsive table td { +white-space: normal; +} diff --git a/docs/conf.py b/docs/conf.py index a100241c1..356be99d6 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -1,6 +1,6 @@ # -*- coding: utf-8 -*- # -# Copyright (c) 2019, Arm Limited. All rights reserved. +# Copyright (c) 2019-2021, Arm Limited. All rights reserved. # # SPDX-License-Identifier: BSD-3-Clause # @@ -76,6 +76,14 @@ html_theme_options = { 'style_external_links': True # Display an icon next to external links } +# Path to _static directory +html_static_path = ['_static'] + +# Path to css file relative to html_static_path +html_css_files = [ + 'css/custom.css', +] + # -- Options for autosectionlabel -------------------------------------------- # Only generate automatic section labels for document titles diff --git a/docs/index.rst b/docs/index.rst index cb5312753..376085589 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -15,6 +15,7 @@ Trusted Firmware-A Documentation perf/index security_advisories/index design_documents/index + threat_model/index change-log change-log-upcoming glossary @@ -83,7 +84,7 @@ have previously been raised against the software. -------------- -*Copyright (c) 2013-2020, Arm Limited and Contributors. All rights reserved.* +*Copyright (c) 2013-2021, Arm Limited and Contributors. All rights reserved.* .. _Armv7-A and Armv8-A: https://developer.arm.com/products/architecture/a-profile .. _Secure Monitor: http://www.arm.com/products/processors/technologies/trustzone/tee-smc.php diff --git a/docs/resources/diagrams/plantuml/tfa_dfd.puml b/docs/resources/diagrams/plantuml/tfa_dfd.puml new file mode 100644 index 000000000..000791105 --- /dev/null +++ b/docs/resources/diagrams/plantuml/tfa_dfd.puml @@ -0,0 +1,66 @@ +/' + ' Copyright (c) 2021, Arm Limited. All rights reserved. + ' + ' SPDX-License-Identifier: BSD-3-Clause + '/ + +/' +TF-A Data Flow Diagram +'/ + +@startuml +digraph tfa_dfd { + + # Arrange nodes from left to right + rankdir="LR" + + # Allow arrows to end on cluster boundaries + compound=true + + # Default settings for edges and nodes + edge [minlen=2 color="#8c1b07"] + node [fillcolor="#ffb866" style=filled shape=box fixedsize=true width=1.6 height=0.7] + + # Nodes outside of the trust boundary + nsec [label="Non-secure\nClients"] + sec [label="Secure\nClients"] + dbg [label="Debug & Trace"] + logs [label="Logs\n(UART)"] + nvm [label="Non-volatile\nMemory"] + + # Trust boundary cluster + subgraph cluster_trusted{ + graph [style=dashed color="#f22430"] + + # HW IPs cluster + subgraph cluster_ip{ + label ="Hardware IPs"; + graph [style=filled color="#000000" fillcolor="#ffd29e"] + + rank="same" + gic [label="GIC" width=1.2 height=0.5] + tzc [label="TZ\nController" width=1.2 height=0.5] + etc [label="..." shape=none style=none height=0.5] + } + + # TF-A cluster + subgraph cluster_tfa{ + label ="TF-A"; + graph [style=filled color="#000000" fillcolor="#faf9cd"] + + bl1 [label="Boot ROM\n(BL1)" fillcolor="#ddffb3"]; + bl2 [label="Trusted Boot\nFirmware\n(BL2)" fillcolor="#ddffb3" height=1] + bl31 [label="TF-A Runtime\n(BL31)" fillcolor="#ddffb3"] + } + } + + # Interactions between nodes + nvm -> bl31 [lhead=cluster_tfa label="DF1"] + logs -> bl31 [dir="back" lhead=cluster_tfa label="DF2"] + dbg -> bl2 [dir="both" lhead=cluster_tfa label="DF3"] + sec -> bl2 [dir="both" lhead=cluster_tfa label="DF4"] + nsec -> bl1 [dir="both" lhead=cluster_tfa, label="DF5"] + bl2 -> tzc [dir="both" ltail=cluster_tfa lhead=cluster_ip label="DF6" minlen=1] +} + +@enduml diff --git a/docs/threat_model/index.rst b/docs/threat_model/index.rst new file mode 100644 index 000000000..e8f09b928 --- /dev/null +++ b/docs/threat_model/index.rst @@ -0,0 +1,13 @@ +Threat Model +============= + +.. toctree:: + :maxdepth: 1 + :caption: Contents + :numbered: + + threat_model + +-------------- + +*Copyright (c) 2021, Arm Limited and Contributors. All rights reserved.* diff --git a/docs/threat_model/threat_model.rst b/docs/threat_model/threat_model.rst new file mode 100644 index 000000000..9cee10415 --- /dev/null +++ b/docs/threat_model/threat_model.rst @@ -0,0 +1,784 @@ +***************** +Introduction +***************** +Threat modeling is an important part of Secure Development Lifecycle (SDL) +that helps us identify potential threats and mitigations affecting a system. + +This document provides a generic threat model for TF-A firmware. In the +next sections, we first give a description of the target of evaluation +using a data flow diagram. Then we provide a list of threats we have +identified based on the data flow diagram and potential threat mitigations. + +************************ +Target of Evaluation +************************ +In this threat model, the target of evaluation is the Trusted +Firmware for A-class Processors (TF-A). This includes the boot ROM (BL1), +the trusted boot firmware (BL2) and the runtime EL3 firmware (BL31) as +shown on Figure 1. Everything else on Figure 1 is outside of the scope of +the evaluation. + +TF-A can be configured in various ways. In this threat model we consider +only the most basic configuration. To that end we make the following +assumptions: + +- All TF-A images are run from either ROM or on-chip trusted SRAM. This means + TF-A is not vulnerable to an attacker that can probe or tamper with off-chip + memory. +- Trusted boot is enabled. This means an attacker can't boot arbitrary images + that are not approved by platform providers. +- There is no Secure-EL2. We don't consider threats that may come with + Secure-EL2 software. + +Data Flow Diagram +====================== +Figure 1 shows a high-level data flow diagram for TF-A. The diagram +shows a model of the different components of a TF-A-based system and +their interactions with TF-A. A description of each diagram element +is given on Table 1. On the diagram, the red broken lines indicate +trust boundaries. Components outside of the broken lines +are considered untrusted by TF-A. + +.. uml:: ../resources/diagrams/plantuml/tfa_dfd.puml + :caption: Figure 1: TF-A Data Flow Diagram + +.. table:: Table 1: TF-A Data Flow Diagram Description + + +-----------------+--------------------------------------------------------+ + | Diagram Element | Description | + +=================+========================================================+ + | ``DF1`` | | At boot time, images are loaded from non-volatile | + | | memory and verified by TF-A boot firmware. These | + | | images include TF-A BL2 and BL31 images, as well as | + | | other secure and non-secure images. | + +-----------------+--------------------------------------------------------+ + | ``DF2`` | | TF-A log system framework outputs debug messages | + | | over a UART interface. | + +-----------------+--------------------------------------------------------+ + | ``DF3`` | | Debug and trace IP on a platform can allow access | + | | to registers and memory of TF-A. | + +-----------------+--------------------------------------------------------+ + | ``DF4`` | | Secure world software (e.g. trusted OS) interact | + | | with TF-A through SMC call interface and/or shared | + | | memory. | + +-----------------+--------------------------------------------------------+ + | ``DF5`` | | Non-secure world software (e.g. rich OS) interact | + | | with TF-A through SMC call interface and/or shared | + | | memory. | + +-----------------+--------------------------------------------------------+ + | ``DF6`` | | This path represents the interaction between TF-A and| + | | various hardware IPs such as TrustZone controller | + | | and GIC. At boot time TF-A configures/initializes the| + | | IPs and interacts with them at runtime through | + | | interrupts and registers. | + +-----------------+--------------------------------------------------------+ + + +********************* +Threat Analysis +********************* +In this section we identify and provide assessment of potential threats to TF-A +firmware. The threats are identified for each diagram element on the +data flow diagram above. + +For each threat, we identify the *asset* that is under threat, the +*threat agent* and the *threat type*. Each threat is given a *risk rating* +that represents the impact and likelihood of that threat. We also discuss +potential mitigations. + +Assets +================== +We have identified the following assets for TF-A: + +.. table:: Table 2: TF-A Assets + + +--------------------+---------------------------------------------------+ + | Asset | Description | + +====================+===================================================+ + | ``Sensitive Data`` | | These include sensitive data that an attacker | + | | must not be able to tamper with (e.g. the Root | + | | of Trust Public Key) or see (e.g. secure logs, | + | | debugging information such as crash reports). | + +--------------------+---------------------------------------------------+ + | ``Code Execution`` | | This represents the requirement that the | + | | platform should run only TF-A code approved by | + | | the platform provider. | + +--------------------+---------------------------------------------------+ + | ``Availability`` | | This represents the requirement that TF-A | + | | services should always be available for use. | + +--------------------+---------------------------------------------------+ + +Threat Agents +===================== +To understand the attack surface, it is important to identify potential +attackers, i.e. attack entry points. The following threat agents are +in scope of this threat model. + +.. table:: Table 3: Threat Agents + + +-------------------+-------------------------------------------------------+ + | Threat Agent | Description | + +===================+=======================================================+ + | ``NSCode`` | | Malicious or faulty code running in the Non-secure | + | | world, including NS-EL0 NS-EL1 and NS-EL2 levels | + +-------------------+-------------------------------------------------------+ + | ``SecCode`` | | Malicious or faulty code running in the secure | + | | world, including S-EL0 and S-EL1 levels | + +-------------------+-------------------------------------------------------+ + | ``AppDebug`` | | Physical attacker using debug signals to access | + | | TF-A resources | + +-------------------+-------------------------------------------------------+ + | ``PhysicalAccess``| | Physical attacker having access to external device | + | | communication bus and to external flash | + | | communication bus using common hardware | + +-------------------+-------------------------------------------------------+ + +.. note:: + + In this threat model an advanced physical attacker that has the capability + to tamper with a hardware (e.g. "rewiring" a chip using a focused + ion beam (FIB) workstation or decapsulate the chip using chemicals) is + considered out-of-scope. + +Threat Types +======================== +In this threat model we categorize threats using the `STRIDE threat +analysis technique`_. In this technique a threat is categorized as one +or more of these types: ``Spoofing``, ``Tampering``, ``Repudiation``, +``Information disclosure``, ``Denial of service`` or +``Elevation of privilege``. + +Threat Risk Ratings +======================== +For each threat identified, a risk rating that ranges +from *informational* to *critical* is given based on the likelihood of the +threat occuring if a mitigation is not in place, and the impact of the +threat (i.e. how severe the consequences could be). Table 4 explains each +rating in terms of score, impact and likelihood. + +.. table:: Table 4: Rating and score as applied to impact and likelihood + + +-----------------------+-------------------------+---------------------------+ + | **Rating (Score)** | **Impact** | **Likelihood** | + +=======================+=========================+===========================+ + | ``Critical (5)`` | | Extreme impact to | | Threat is almost | + | | entire organization | certain to be exploited.| + | | if exploited. | | + | | | | Knowledge of the threat | + | | | and how to exploit it | + | | | are in the public | + | | | domain. | + +-----------------------+-------------------------+---------------------------+ + | ``High (4)`` | | Major impact to entire| | Threat is relatively | + | | organization or single| easy to detect and | + | | line of business if | exploit by an attacker | + | | exploited | with little skill. | + +-----------------------+-------------------------+---------------------------+ + | ``Medium (3)`` | | Noticeable impact to | | A knowledgeable insider | + | | line of business if | or expert attacker could| + | | exploited. | exploit the threat | + | | | without much difficulty.| + +-----------------------+-------------------------+---------------------------+ + | ``Low (2)`` | | Minor damage if | | Exploiting the threat | + | | exploited or could | would require | + | | be used in conjunction| considerable expertise | + | | with other | and resources | + | | vulnerabilities to | | + | | perform a more serious| | + | | attack | | + +-----------------------+-------------------------+---------------------------+ + | ``Informational (1)`` | | Poor programming | | Threat is not likely | + | | practice or poor | to be exploited on its | + | | design decision that | own, but may be used to | + | | may not represent an | gain information for | + | | immediate risk on its | launching another | + | | own, but may have | attack | + | | security implications | | + | | if multiplied and/or | | + | | combined with other | | + | | threats. | | + +-----------------------+-------------------------+---------------------------+ + +Aggregate risk scores are assigned to identified threats; +specifically, the impact score multiplied by the likelihood score. +For example, a threat with high likelihood and low impact would have an +aggregate risk score of eight (8); that is, four (4) for high likelihood +multiplied by two (2) for low impact. The aggregate risk score determines +the finding's overall risk level, as shown in the following table. + +.. table:: Table 5: Overall risk levels and corresponding aggregate scores + + +---------------------+-----------------------------------+ + | Overall Risk Level | Aggregate Risk Score | + | | (Impact multiplied by Likelihood) | + +=====================+===================================+ + | Critical | 20–25 | + +---------------------+-----------------------------------+ + | High | 12–19 | + +---------------------+-----------------------------------+ + | Medium | 6–11 | + +---------------------+-----------------------------------+ + | Low | 2–5 | + +---------------------+-----------------------------------+ + | Informational | 1 | + +---------------------+-----------------------------------+ + +The likelihood and impact of a threat depends on the +target environment in which TF-A is running. For example, attacks +that require physical access are unlikely in server environments while +they are more common in Internet of Things(IoT) environments. +In this threat model we consider three target environments: +``Internet of Things(IoT)``, ``Mobile`` and ``Server``. + +Threat Assessment +============================ +The following threats were identified by applying STRIDE analysis on +each diagram element of the data flow diagram. + ++------------------------+----------------------------------------------------+ +| ID | 01 | ++========================+====================================================+ +| ``Threat`` | | **An attacker can mangle firmware images to | +| | execute arbitrary code** | +| | | +| | | Some TF-A images are loaded from external | +| | storage. It is possible for an attacker to access| +| | the external flash memory and change its contents| +| | physically, through the Rich OS, or using the | +| | updating mechanism to modify the non-volatile | +| | images to execute arbitrary code. | ++------------------------+----------------------------------------------------+ +| ``Diagram Elements`` | DF1, DF4, DF5 | ++------------------------+----------------------------------------------------+ +| ``Affected TF-A | BL2, BL31 | +| Components`` | | ++------------------------+----------------------------------------------------+ +| ``Assets`` | Code Execution | ++------------------------+----------------------------------------------------+ +| ``Threat Agent`` | PhysicalAccess, NSCode, SecCode | ++------------------------+----------------------------------------------------+ +| ``Threat Type`` | Tampering, Elevation of Privilege | ++------------------------+------------------+-----------------+---------------+ +| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` | ++------------------------+------------------+-----------------+---------------+ +| ``Impact`` | Critical (5) | Critical (5) | Critical (5) | ++------------------------+------------------+-----------------+---------------+ +| ``Likelihood`` | Critical (5) | Critical (5) | Critical (5) | ++------------------------+------------------+-----------------+---------------+ +| ``Total Risk Rating`` | Critical (25) | Critical (25) | Critical (25) | ++------------------------+------------------+-----------------+---------------+ +| ``Mitigations`` | | TF-A implements the `Trusted Board Boot (TBB)`_ | +| | feature which prevents malicious firmware from | +| | running on the platform by authenticating all | +| | firmware images. In addition to this, the TF-A | +| | boot firmware performs extra checks on | +| | unauthenticated data, such as FIP metadata, prior| +| | to use. | ++------------------------+----------------------------------------------------+ + ++------------------------+----------------------------------------------------+ +| ID | 02 | ++========================+====================================================+ +| ``Threat`` | | **An attacker may attempt to boot outdated, | +| | potentially vulnerable firmware image** | +| | | +| | | When updating firmware, an attacker may attempt | +| | to rollback to an older version that has unfixed | +| | vulnerabilities. | ++------------------------+----------------------------------------------------+ +| ``Diagram Elements`` | DF1, DF4, DF5 | ++------------------------+----------------------------------------------------+ +| ``Affected TF-A | BL2, BL31 | +| Components`` | | ++------------------------+----------------------------------------------------+ +| ``Assets`` | Code Execution | ++------------------------+----------------------------------------------------+ +| ``Threat Agent`` | PhysicalAccess, NSCode, SecCode | ++------------------------+----------------------------------------------------+ +| ``Threat Type`` | Tampering | ++------------------------+------------------+-----------------+---------------+ +| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` | ++------------------------+------------------+-----------------+---------------+ +| ``Impact`` | Critical (5) | Critical (5) | Critical (5) | ++------------------------+------------------+-----------------+---------------+ +| ``Likelihood`` | Critical (5) | Critical (5) | Critical (5) | ++------------------------+------------------+-----------------+---------------+ +| ``Total Risk Rating`` | Critical (25) | Critical (25) | Critical (25) | ++------------------------+------------------+-----------------+---------------+ +| ``Mitigations`` | | TF-A supports anti-rollback protection using | +| | non-volatile counters (NV counters) as required | +| | by `TBBR-Client specification`_. After a firmware| +| | image is validated, the image revision number | +| | taken from a certificate extension field is | +| | compared with the corresponding NV counter stored| +| | in hardware to make sure the new counter value is| +| | larger or equal to the current counter value. | +| | Platforms must implement this protection using | +| | platform specific hardware NV counters. | ++------------------------+----------------------------------------------------+ + ++------------------------+-------------------------------------------------------+ +| ID | 03 | ++========================+=======================================================+ +| ``Threat`` | | **An attacker can use Time-of-Check-Time-of-Use | +| | (TOCTOU) attack to bypass image authentication | +| | during the boot process** | +| | | +| | | Time-of-Check-Time-of-Use (TOCTOU) threats occur | +| | when the security check is produced before the time | +| | the resource is accessed. If an attacker is sitting | +| | in the middle of the off-chip images, they could | +| | change the binary containing executable code right | +| | after the integrity and authentication check has | +| | been performed. | ++------------------------+-------------------------------------------------------+ +| ``Diagram Elements`` | DF1 | ++------------------------+-------------------------------------------------------+ +| ``Affected TF-A | BL1, BL2 | +| Components`` | | ++------------------------+-------------------------------------------------------+ +| ``Assets`` | Code Execution, Sensitive Data | ++------------------------+-------------------------------------------------------+ +| ``Threat Agent`` | PhysicalAccess | ++------------------------+-------------------------------------------------------+ +| ``Threat Type`` | Elevation of Privilege | ++------------------------+---------------------+-----------------+---------------+ +| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` | ++------------------------+---------------------+-----------------+---------------+ +| ``Impact`` | N/A | Critical (5) | Critical (5) | ++------------------------+---------------------+-----------------+---------------+ +| ``Likelihood`` | N/A | Medium (3) | Medium (3) | ++------------------------+---------------------+-----------------+---------------+ +| ``Total Risk Rating`` | N/A | High (15) | High (15) | ++------------------------+---------------------+-----------------+---------------+ +| ``Mitigations`` | | TF-A boot firmware copies image to on-chip | +| | memory before authenticating an image. | ++------------------------+-------------------------------------------------------+ + ++------------------------+-------------------------------------------------------+ +| ID | 04 | ++========================+=======================================================+ +| ``Threat`` | | **An attacker with physical access can execute | +| | arbitrary image by bypassing the signature | +| | verification stage using glitching techniques** | +| | | +| | | Glitching (Fault injection) attacks attempt to put | +| | a hardware into a undefined state by manipulating an| +| | environmental variable such as power supply. | +| | | +| | | TF-A relies on a chain of trust that starts with the| +| | ROTPK, which is the key stored inside the chip and | +| | the root of all validation processes. If an attacker| +| | can break this chain of trust, they could execute | +| | arbitrary code on the device. This could be | +| | achieved with physical access to the device by | +| | attacking the normal execution flow of the | +| | process using glitching techniques that target | +| | points where the image is validated against the | +| | signature. | ++------------------------+-------------------------------------------------------+ +| ``Diagram Elements`` | DF1 | ++------------------------+-------------------------------------------------------+ +| ``Affected TF-A | BL1, BL2 | +| Components`` | | ++------------------------+-------------------------------------------------------+ +| ``Assets`` | Code Execution | ++------------------------+-------------------------------------------------------+ +| ``Threat Agent`` | PhysicalAccess | ++------------------------+-------------------------------------------------------+ +| ``Threat Type`` | Tampering, Elevation of Privilege | ++------------------------+---------------------+-----------------+---------------+ +| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` | ++------------------------+---------------------+-----------------+---------------+ +| ``Impact`` | N/A | Critical (5) | Critical (5) | ++------------------------+---------------------+-----------------+---------------+ +| ``Likelihood`` | N/A | Medium (3) | Medium (3) | ++------------------------+---------------------+-----------------+---------------+ +| ``Total Risk Rating`` | N/A | High (15) | High (15) | ++------------------------+---------------------+-----------------+---------------+ +| ``Mitigations`` | | The most effective mitigation is adding glitching | +| | detection and mitigation circuit at the hardware | +| | level. However, software techniques, | +| | such as adding redundant checks when performing | +| | conditional branches that are security sensitive, | +| | can be used to harden TF-A against such attacks. | +| | **At the moment TF-A doesn't implement such | +| | mitigations.** | ++------------------------+-------------------------------------------------------+ + ++------------------------+---------------------------------------------------+ +| ID | 05 | ++========================+===================================================+ +| ``Threat`` | | **Information leak via UART logs such as | +| | crashes** | +| | | +| | | During the development stages of software it is | +| | common to include crash reports with detailed | +| | information of the CPU state including current | +| | values of the registers, privilege level and | +| | stack dumps. This information is useful when | +| | debugging problems before releasing the | +| | production version, but it could be used by an | +| | attacker to develop a working exploit if left | +| | in the production version. | ++------------------------+---------------------------------------------------+ +| ``Diagram Elements`` | DF2 | ++------------------------+---------------------------------------------------+ +| ``Affected TF-A | BL1, BL2, BL31 | +| Components`` | | ++------------------------+---------------------------------------------------+ +| ``Assets`` | Sensitive Data | ++------------------------+---------------------------------------------------+ +| ``Threat Agent`` | AppDebug | ++------------------------+---------------------------------------------------+ +| ``Threat Type`` | Information Disclosure | ++------------------------+------------------+----------------+---------------+ +| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` | ++------------------------+------------------+----------------+---------------+ +| ``Impact`` | N/A | Low (2) | Low (2) | ++------------------------+------------------+----------------+---------------+ +| ``Likelihood`` | N/A | High (4) | High (4) | ++------------------------+------------------+----------------+---------------+ +| ``Total Risk Rating`` | N/A | Medium (8) | Medium (8) | ++------------------------+------------------+----------------+---------------+ +| ``Mitigations`` | | In TF-A, crash reporting is only enabled for | +| | debug builds by default. Alternatively, the log | +| | level can be tuned at build time (from verbose | +| | to no output at all), independently of the | +| | build type. | ++------------------------+---------------------------------------------------+ + ++------------------------+----------------------------------------------------+ +| ID | 06 | ++========================+====================================================+ +| ``Threat`` | | **An attacker can read sensitive data and | +| | execute arbitrary code through the external | +| | debug and trace interface** | +| | | +| | | Arm processors include hardware-assisted debug | +| | and trace features that can be controlled without| +| | the need for software operating on the platform. | +| | If left enabled without authentication, this | +| | feature can be used by an attacker to inspect and| +| | modify TF-A registers and memory allowing the | +| | attacker to read sensitive data and execute | +| | arbitrary code. | ++------------------------+----------------------------------------------------+ +| ``Diagram Elements`` | DF3 | ++------------------------+----------------------------------------------------+ +| ``Affected TF-A | BL1, BL2, BL31 | +| Components`` | | ++------------------------+----------------------------------------------------+ +| ``Assets`` | Code Execution, Sensitive Data | ++------------------------+----------------------------------------------------+ +| ``Threat Agent`` | AppDebug | ++------------------------+----------------------------------------------------+ +| ``Threat Type`` | Tampering, Information Disclosure, | +| | Elevation of privilege | ++------------------------+------------------+---------------+-----------------+ +| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` | ++------------------------+------------------+---------------+-----------------+ +| ``Impact`` | N/A | High (4) | High (4) | ++------------------------+------------------+---------------+-----------------+ +| ``Likelihood`` | N/A | Critical (5) | Critical (5) | ++------------------------+------------------+---------------+-----------------+ +| ``Total Risk Rating`` | N/A | Critical (20) | Critical (20) | ++------------------------+------------------+---------------+-----------------+ +| ``Mitigations`` | | Configuration of debug and trace capabilities is | +| | platform specific. Therefore, platforms must | +| | disable the debug and trace capability for | +| | production releases or enable proper debug | +| | authentication as recommended by [`DEN0034`_]. | ++------------------------+----------------------------------------------------+ + ++------------------------+------------------------------------------------------+ +| ID | 07 | ++========================+======================================================+ +| ``Threat`` | | **An attacker can perform a denial-of-service | +| | attack by using a broken SMC call that causes the | +| | system to reboot or enter into unknown state.** | +| | | +| | | Secure and non-secure clients access TF-A services | +| | through SMC calls. Malicious code can attempt to | +| | place the TF-A runtime into an inconsistent state | +| | by calling unimplemented SMC call or by passing | +| | invalid arguments. | ++------------------------+------------------------------------------------------+ +| ``Diagram Elements`` | DF4, DF5 | ++------------------------+------------------------------------------------------+ +| ``Affected TF-A | BL31 | +| Components`` | | ++------------------------+------------------------------------------------------+ +| ``Assets`` | Availability | ++------------------------+------------------------------------------------------+ +| ``Threat Agent`` | NSCode, SecCode | ++------------------------+------------------------------------------------------+ +| ``Threat Type`` | Denial of Service | ++------------------------+-------------------+----------------+-----------------+ +| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` | ++------------------------+-------------------+----------------+-----------------+ +| ``Impact`` | Medium (3) | Medium (3) | Medium (3) | ++------------------------+-------------------+----------------+-----------------+ +| ``Likelihood`` | High (4) | High (4) | High (4) | ++------------------------+-------------------+----------------+-----------------+ +| ``Total Risk Rating`` | High (12) | High (12) | High (12) | ++------------------------+-------------------+----------------+-----------------+ +| ``Mitigations`` | | The generic TF-A code validates SMC function ids | +| | and arguments before using them. | +| | Platforms that implement SiP services must also | +| | validate SMC call arguments. | ++------------------------+------------------------------------------------------+ + ++------------------------+------------------------------------------------------+ +| ID | 08 | ++========================+======================================================+ +| ``Threat`` | | **Memory corruption due to memory overflows and | +| | lack of boundary checking when accessing resources | +| | could allow an attacker to execute arbitrary code, | +| | modify some state variable to change the normal | +| | flow of the program, or leak sensitive | +| | information** | +| | | +| | | Like in other software, the Trusted Firmware has | +| | multiple points where memory corruption security | +| | errors can arise. Memory corruption is a dangerous | +| | security issue since it could allow an attacker | +| | to execute arbitrary code, modify some state | +| | variable to change the normal flow of the program, | +| | or leak sensitive information. | +| | | +| | | Some of the errors include integer overflow, | +| | buffer overflow, incorrect array boundary checks, | +| | and incorrect error management. | +| | Improper use of asserts instead of proper input | +| | validations might also result in these kinds of | +| | errors in release builds. | ++------------------------+------------------------------------------------------+ +| ``Diagram Elements`` | DF4, DF5 | ++------------------------+------------------------------------------------------+ +| ``Affected TF-A | BL1, BL2, BL31 | +| Components`` | | ++------------------------+------------------------------------------------------+ +| ``Assets`` | Code Execution, Sensitive Data | ++------------------------+------------------------------------------------------+ +| ``Threat Agent`` | NSCode, SecCode | ++------------------------+------------------------------------------------------+ +| ``Threat Type`` | Tampering, Information Disclosure, | +| | Elevation of Privilege | ++------------------------+-------------------+-----------------+----------------+ +| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` | ++------------------------+-------------------+-----------------+----------------+ +| ``Impact`` | Critical (5) | Critical (5) | Critical (5) | ++------------------------+-------------------+-----------------+----------------+ +| ``Likelihood`` | Medium (3 | Medium (3) | Medium (3) | ++------------------------+-------------------+-----------------+----------------+ +| ``Total Risk Rating`` | High (15) | High (15) | High (15) | ++------------------------+-------------------+-----------------+----------------+ +| ``Mitigations`` | | TF-A uses a combination of manual code reviews and | +| | automated program analysis and testing to detect | +| | and fix memory corruption bugs. All TF-A code | +| | including platform code go through manual code | +| | reviews. Additionally, static code analysis is | +| | performed using Coverity Scan on all TF-A code. | +| | The code is also tested with | +| | `Trusted Firmware-A Tests`_ on Juno and FVP | +| | platforms. | +| | | +| | | Data received from normal world, such as addresses | +| | and sizes identifying memory regions, are | +| | sanitized before being used. These security checks | +| | make sure that the normal world software does not | +| | access memory beyond its limit. | +| | | +| | | By default *asserts* are only used to check for | +| | programming errors in debug builds. Other types of | +| | errors are handled through condition checks that | +| | remain enabled in release builds. See | +| | `TF-A error handling policy`_. TF-A provides an | +| | option to use *asserts* in release builds, however | +| | we recommend using proper runtime checks instead | +| | of relying on asserts in release builds. | ++------------------------+------------------------------------------------------+ + ++------------------------+------------------------------------------------------+ +| ID | 09 | ++========================+======================================================+ +| ``Threat`` | | **Improperly handled SMC calls can leak register | +| | contents** | +| | | +| | | When switching between secure and non-secure | +| | states, register contents of Secure world or | +| | register contents of other normal world clients | +| | can be leaked. | ++------------------------+------------------------------------------------------+ +| ``Diagram Elements`` | DF5 | ++------------------------+------------------------------------------------------+ +| ``Affected TF-A | BL31 | +| Components`` | | ++------------------------+------------------------------------------------------+ +| ``Assets`` | Sensitive Data | ++------------------------+------------------------------------------------------+ +| ``Threat Agent`` | NSCode | ++------------------------+------------------------------------------------------+ +| ``Threat Type`` | Information Disclosure | ++------------------------+-------------------+----------------+-----------------+ +| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` | ++------------------------+-------------------+----------------+-----------------+ +| ``Impact`` | Medium (3) | Medium (3) | Medium (3) | ++------------------------+-------------------+----------------+-----------------+ +| ``Likelihood`` | High (4) | High (4) | High (4) | ++------------------------+-------------------+----------------+-----------------+ +| ``Total Risk Rating`` | High (12) | High (12) | High (12) | ++------------------------+-------------------+----------------+-----------------+ +| ``Mitigations`` | | TF-A saves and restores registers | +| | by default when switching contexts. Build options | +| | are also provided to save/restore additional | +| | registers such as floating-point registers. | ++------------------------+------------------------------------------------------+ + ++------------------------+-----------------------------------------------------+ +| ID | 10 | ++========================+=====================================================+ +| ``Threat`` | | **SMC calls can leak sensitive information from | +| | TF-A memory via microarchitectural side channels**| +| | | +| | | Microarchitectural side-channel attacks such as | +| | `Spectre`_ can be used to leak data across | +| | security boundaries. An attacker might attempt to | +| | use this kind of attack to leak sensitive | +| | data from TF-A memory. | ++------------------------+-----------------------------------------------------+ +| ``Diagram Elements`` | DF4, DF5 | ++------------------------+-----------------------------------------------------+ +| ``Affected TF-A | BL31 | +| Components`` | | ++------------------------+-----------------------------------------------------+ +| ``Assets`` | Sensitive Data | ++------------------------+-----------------------------------------------------+ +| ``Threat Agent`` | SecCode, NSCode | ++------------------------+-----------------------------------------------------+ +| ``Threat Type`` | Information Disclosure | ++------------------------+-------------------+----------------+----------------+ +| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` | ++------------------------+-------------------+----------------+----------------+ +| ``Impact`` | Medium (3) | Medium (3) | Medium (3) | ++------------------------+-------------------+----------------+----------------+ +| ``Likelihood`` | Medium (3) | Medium (3) | Medium (3) | ++------------------------+-------------------+----------------+----------------+ +| ``Total Risk Rating`` | Medium (9) | Medium (9) | Medium (9) | ++------------------------+-------------------+----------------+----------------+ +| ``Mitigations`` | | TF-A implements software mitigations for Spectre | +| | type attacks as recommended by `Cache Speculation | +| | Side-channels`_ for the generic code. SiPs should | +| | implement similar mitigations for code that is | +| | deemed to be vulnerable to such attacks. | ++------------------------+-----------------------------------------------------+ + ++------------------------+----------------------------------------------------+ +| ID | 11 | ++========================+====================================================+ +| ``Threat`` | | **Misconfiguration of the Memory Management Unit | +| | (MMU) may allow a normal world software to | +| | access sensitive data or execute arbitrary | +| | code** | +| | | +| | | A misconfiguration of the MMU could | +| | lead to an open door for software running in the | +| | normal world to access sensitive data or even | +| | execute code if the proper security mechanisms | +| | are not in place. | ++------------------------+----------------------------------------------------+ +| ``Diagram Elements`` | DF5, DF6 | ++------------------------+----------------------------------------------------+ +| ``Affected TF-A | BL1, BL2, BL31 | +| Components`` | | ++------------------------+----------------------------------------------------+ +| ``Assets`` | Sensitive Data, Code execution | ++------------------------+----------------------------------------------------+ +| ``Threat Agent`` | NSCode | ++------------------------+----------------------------------------------------+ +| ``Threat Type`` | Information Disclosure, Elevation of Privilege | ++------------------------+-----------------+-----------------+----------------+ +| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` | ++------------------------+-----------------+-----------------+----------------+ +| ``Impact`` | Critical (5) | Critical (5) | Critical (5) | ++------------------------+-----------------+-----------------+----------------+ +| ``Likelihood`` | High (4) | High (4) | High (4) | ++------------------------+-----------------+-----------------+----------------+ +| ``Total Risk Rating`` | Critical (20) | Critical (20) | Critical (20) | ++------------------------+-----------------+-----------------+----------------+ +| ``Mitigations`` | | In TF-A, configuration of the MMU is done | +| | through a translation tables library. The | +| | library provides APIs to define memory regions | +| | and assign attributes including memory types and | +| | access permissions. Memory configurations are | +| | platform specific, therefore platforms need make | +| | sure the correct attributes are assigned to | +| | memory regions. When assigning access | +| | permissions, principle of least privilege ought | +| | to be enforced, i.e. we should not grant more | +| | privileges than strictly needed, e.g. code | +| | should be read-only executable, RO data should | +| | be read-only XN, and so on. | ++------------------------+----------------------------------------------------+ + ++------------------------+-----------------------------------------------------+ +| ID | 12 | ++========================+=====================================================+ +| ``Threat`` | | **Incorrect configuration of Performance Monitor | +| | Unit (PMU) counters can allow an attacker to | +| | mount side-channel attacks using information | +| | exposed by the counters** | +| | | +| | | Non-secure software can configure PMU registers | +| | to count events at any exception level and in | +| | both Secure and Non-secure states. This allows | +| | a Non-secure software (or a lower-level Secure | +| | software) to potentially carry out | +| | side-channel timing attacks against TF-A. | ++------------------------+-----------------------------------------------------+ +| ``Diagram Elements`` | DF5, DF6 | ++------------------------+-----------------------------------------------------+ +| ``Affected TF-A | BL31 | +| Components`` | | ++------------------------+-----------------------------------------------------+ +| ``Assets`` | Sensitive Data | ++------------------------+-----------------------------------------------------+ +| ``Threat Agent`` | NSCode | ++------------------------+-----------------------------------------------------+ +| ``Threat Type`` | Information Disclosure | ++------------------------+-------------------+----------------+----------------+ +| ``Impact`` | Medium (3) | Medium (3) | Medium (3) | ++------------------------+-------------------+----------------+----------------+ +| ``Likelihood`` | Low (2) | Low (2) | Low (2) | ++------------------------+-------------------+----------------+----------------+ +| ``Total Risk Rating`` | Medium (6) | Medium (6) | Medium (6) | ++------------------------+-------------------+----------------+----------------+ +| ``Mitigations`` | | TF-A follows mitigation strategies as described | +| | in `Secure Development Guidelines`_. General | +| | events and cycle counting in the Secure world is | +| | prohibited by default when applicable. However, | +| | on some implementations (e.g. PMUv3) Secure world | +| | event counting depends on external debug interface| +| | signals, i.e. Secure world event counting is | +| | enabled if external debug is enabled. | +| | Configuration of debug signals is platform | +| | specific, therefore platforms need to make sure | +| | that external debug is disabled in production or | +| | proper debug authentication is in place. | ++------------------------+-----------------------------------------------------+ + +-------------- + +*Copyright (c) 2021, Arm Limited. All rights reserved.* + + +.. _STRIDE threat analysis technique: https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats#stride-model +.. _DEN0034: https://developer.arm.com/documentation/den0034/latest +.. _Cache Speculation Side-channels: https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability +.. _Spectre: https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability +.. _TBBR-Client specification: https://developer.arm.com/documentation/den0006/d/ +.. _Trusted Board Boot (TBB): https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boot.html +.. _TF-A error handling policy: https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-guidelines.html#error-handling-and-robustness +.. _Secure Development Guidelines: https://trustedfirmware-a.readthedocs.io/en/latest/process/security-hardening.html#secure-development-guidelines +.. _Trusted Firmware-A Tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/about/ \ No newline at end of file