You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
781 lines
55 KiB
781 lines
55 KiB
Generic threat model
|
|
********************
|
|
|
|
************************
|
|
Introduction
|
|
************************
|
|
This document provides a generic threat model for TF-A firmware.
|
|
|
|
************************
|
|
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/
|
|
|