11.2. TF-A Supply Chain Threat Model

11.2.1. Introduction

Software supply chain attacks aim to inject malicious code into a software product. There are several ways a malicious code can be injected into a software product (open-source project). These include:

Malicious code commits: This attack directly injects code into a project repository. This can happen for example through developer/maintainer credential hijacks, or malicious external contributors.
Malicious dependencies: In this case malicious code is introduced into a project through other piece of code or packages the project depends on. This can happen through for example typosquatting attack where an attacker creates a malicious package with a very similar name to a popular package and hosts it on popular package repositories.
Malicious toolchains: This involves malicious code introduced by compromised resources used throughout the development and/or build process such as compilers and IDEs.

This document provides analysis of software supply chain attack threats for the TF-A project.

11.2.2. TF-A Overview

Figure 1 shows the different software components surrounding the TF-A project. A brief description of each component is provided below.

11.2.2.1. TF-A Repository

The TF-A repository contains generic and platform code contributed by TF-A contributors as well as libraries imported from other open-source projects, referred to as internal dependencies on Figure 1. These libraries include:

libfdt: libfdt is a utility library for reading and manipulating Device Tree Binary (DTB) files. It is part of the Device Tree Compiler (DTC) toolchain [1]. DTC is used as part of the build process on the host machine to build DTB files. libfdt is used to parse the DTB files at boot time.
zlib: zlib is a data compression library imported from [2].
compiler-rt: This is a collection of runtime libraries from the LLVM compiler infrastructure project [3]. We import the builtins library which provides low-level, target-specific compiler builtins from compiler-rt.

The TF-A repository also includes source code for host tools that supplement the TF-A build process. These tools include:

fiptool: This tool is used to create a Firmware Image Package (FIP) which allows for packing bootloader images into a single archive that can be loaded by TF-A from non-volatile platform storage.
cert_create: This tool is used to generate certificates for binary images.
encrypt_fw: This tool takes the plain firmware image as input and generates the encrypted firmware image which can then be passed as input to the fiptool utility for creating the FIP.
sptool: This tool is used to build the secure partition packages.

Figure 1: TF-A System Diagram

11.2.2.2. External Dependencies

These are software components that are not part of the TF-A repository but are required to build TF-A binaries and host tools.

Mbed TLS Library: This is a cryptography library from trustedfirmware.org (tf.org). It is required to build TF-A binaries where cryptography features are needed, such as Trusted Board Boot (TBB).
OpenSSL Library: This is another cryptography library used by TF-A host tools: fiptool, cert_create, and encrypt_fw.

The following table lists TF-A dependencies including the sources of the dependencies.

Table 1: TF-A Dependencies
Dependency	Location of Dependency	Original Source
libfdt	Local copy	[1]
zlib	Local copy	[2]
compiler-rt	Local copy	[3]
Mbed TLS	External	[4]
OpenSSL	External	[5]

11.2.2.3. Supplementary Binaries

These are binaries used to test TF-A based systems. Below is a brief description of each component and where they are sourced from.

SCP-firmware: For our tests, we use SCP-firmware binaries supplied by the Arm SCP team built from the source from the GitHub repository [6].
OP-TEE: Trusted Execution Environment (TEE) from tf.org that runs as Secure EL1. We use OP-TEE built from source or binaries supplied with Arm Reference Platforms depending on the test configuration.
EDK2 UEFI: Normal world bootloader from the EDK2 project [7]. We use EDK2 UEFI binaries hosted on tf.org servers for testing [8].

Other software components used to test TF-A include U-Boot, Linux kernel, RSS, MCP, and file systems, all sourced from the Arm Reference Platforms teams.

11.2.2.4. TF-A Toolchain

The TF-A project uses several tools to build, analyze and test the TF-A source code.

11.2.2.4.1. Node.js Tools

These are optional quality assurance and developer utility tools that are installed through the use of the Node.js package manager. They are pinned to specific versions described by the package.json file in the root of the TF-A repository, and their dependencies are downloaded from the internet at the point of installation. These tools may be installed locally on the developer machine and are installed within a Docker container in certain CI jobs. At present, these are:

Commitlint
Commitizen
Husky

11.2.2.5. Infrastructure

TF-A uses trustedfirmware.org (tf.org) and Arm infrastructures to host the source code, review code and run tests. Appendix A provides a security analysis of tf.org infrastructure.

11.2.3. TF-A Data Flow

Figure 2 below shows the data flow diagram for TF-A. The broken red lines indicate trust boundaries.

Figure 2: TF-A Data Flow Diagram

11.2.4. Attack Tree

Figure 3: TF-A Attack Tree

11.2.5. Threat Assessment and Mitigations

11.2.5.1. Impact and Likelihood Ratings

Rating

Impact

Likelihood

HIGH

Major impact to entire organization or single line of business if exploited.

Threat is relatively easy to exploit by an attacker with little effort and skill.

MEDIUM

Noticeable impact to line of business if exploited.

An expert attacker could exploit the threat without much difficulty.

LOW

Minor damage if exploited or could be used in conjunction with other vulnerabilities to perform a more serious attack.

Exploiting the threat would require considerable effort and resources.

11.2.5.2. Threats and Mitigations

Threat naming convention key

SC – Supply Chain
SRC – Source
DEP – Dependency
TOOL – Toolchain
REPO – Repository
MAIN – Maintainer

CONT – Contributor

Threat: TFA-SC-SRC-MAIN-01
Description	An attacker can submit and merge malicious code by posing as a maintainer after compromising maintainers’ credentials.
Impact	HIGH
Likelihood	MEDIUM
Threat and impact	In the TF-A code review process all submitted changes undergo review by a code owner and a maintainer. If the change is accepted, it will be merged (integrated) into an integration branch by a maintainer. A maintainer has the right to give a code owner review, a maintainer review and merge the submitted change. tf.org users (including maintainers) are authenticated through GitHub. The likelihood of a credential compromise depends on multiple factors. The authentication mechanism of GitHub is strong if the recommended best practices are followed [9] making credential compromise unlikely. GitHub (therefore tf.org) allows logins with two-factor authentication, requiring both a password and access to the user’s authentication code. Depending on the strength of the password and factors such as whether the maintainer reuses passwords across services, the likelihood of a compromise can be higher. If an attacker manages to compromise a maintainer’s credentials, posing as the maintainer, they can in theory submit a malicious change (as a maintainer or as a contributor), give all the necessary reviews and merge the change.
Mitigations	- Enforce best practices recommended by GitHub [9] - Not allowing a committer to both self-review and merge patches they have submitted. To achieve the commit the attacker would be required to compromise at least two credentials (reviewers and maintainer).
Mitigations implemented?	We have not disallowed self-review/merge of patches

Threat: TFA-SC-SRC-MAIN-02
Description	An attacker can submit and merge malicious code after becoming a maintainer through social engineering techniques.
Impact	HIGH
Likelihood	LOW
Threat and impact	According to the TF project maintenance process [10], maintainers of TF-A are selected by their peers based on merit. Some of the criteria of becoming a maintainer include being an active member of the project for a minimum duration and contributing a substantial number of non-trivial and high-quality patches. However, there are some weaknesses in the process: - There is no structured mechanism to establish trust with a maintainer other than the recommendations by peers - There is no continuous monitoring of the status of a maintainer (e.g. maintainer can move from one organization to another) To perform such an attack, in addition to becoming a maintainer, an attacker also must deal with all restrictions put on maintainers.
Mitigations	- Structured mechanism to establish trust with maintainers - Not allowing a committer to both self-review and merge patches they have submitted. To achieve the commit the attacker would be required to compromise at least two credentials (reviewers and maintainer).
Mitigations implemented?	There is a structured mechanism to establish trust with maintainers, but self-review/merge of patches is not disallowed

Threat: TFA-SC-SRC-CONT-01
Description	An attacker can submit malicious code patch as a contributor.
Impact	HIGH
Likelihood	LOW
Threat and impact	TF-A accepts external contributions to both the generic and platform code. Unlike maintainers, contributors do not have maintainer review or merging privileges, therefore the likelihood of injecting malicious code as a contributor is lower. However, even though unlikely, it is still possible for a malicious commit to go unnoticed through the code review and verification processes. If successful, the impact can range from low to high depending on the injected code. For example, an attacker can potentially deliberately insert a memory corruption vulnerability that is hard to notice on code review and will not be detected by the verification process. This vulnerability by itself may have a low impact but can have a major impact if used in combination with other vulnerabilities.
Proposed Mitigations	Code review and verification Static analysis to try to pick up issues that typically end in some form of attack vector
Mitigations implemented?	Yes, contributions go through the thorough review, verification, and static analysis process automated through CI

Threat: TFA-SC-DEP-01
Description	An attacker can inject malicious code into TF-A internal dependencies.
Impact	HIGH
Likelihood	LOW
Threat and impact	TF-A has two types of dependencies: those that are copied into the TF-A repository and shipped as part of TF-A code (referred to as internal dependencies here) and those that are downloaded from external repositories and used when building TF-A (referred to as external dependencies here). Currently TF-A has three internal dependencies: libfdt [1], zlib [2] and compiler-rt [3] libraries. These libraries are periodically updated by copying them from their source repositories. Although unlikely, it is possible for a contributor to copy the libraries from the wrong (and potentially malicious) repositories. For example, there are already multiple forks of libfdt (DTC) on GitHub. In addition to this, the official repositories are not immune to threats described above (TFA-SC-SRC-MAIN-01, TFA-SC-SRC-MAIN-02 and TFA-SC-SRC-CONT-01). The likelihood of an attack on TF-A through internal dependencies is lower than external dependencies for the following reasons: - Internal dependencies go through the normal code review process during upgrade - Once upgraded internal dependencies stay unchanged until the next upgrade. The upgrade window is typically long (for example libfdt has only changed 4 times over the past 4 years). This reduces the window of opportunity for an attacker to inject malicious code into the dependencies
Proposed Mitigations	Explicitly document versions and official sources of dependencies Keep a copy of a pinned version of the source code inside the TF-A tree so that the risk of getting malicious code from dependencies only arises when we upgrade them Monitor alerts for vulnerable dependencies from GitHub [11]
Mitigations implemented?	Yes, we explicitly document versions and official sources of dependencies, keep a copy of pinned versions of the source code, and monitor alerts for vulnerable dependencies for Python and Node.js, but we aren’t able to do this for C dependencies

Threat: TFA-SC-DEP-02
Description	An attacker can inject malicious code into TF-A external dependencies.
Impact	HIGH
Likelihood	MEDIUM
Threat and impact	Unlike internal dependencies, external dependencies are downloaded from external repositories by end-users. Although the TF-A documentation provides information about the versions of dependencies used for testing and links to repositories, it is up to the end-user to decide where to get the dependencies from. As such, the likelihood of an attack through an external dependency is higher compared to an internal dependency. The impact of an attack ranges from low to critical depending on which dependency and what part of the dependency is affected. For example, a malicious code that affects the signature verification functions in MbedTLS is considered critical as it can be used to bypass the TBB process of TF-A.
Proposed Mitigations	Explicitly document versions and official sources of dependencies Provide scripts and build options to automatically fetch the latest stable release of external dependencies
Mitigations implemented?	We explicitly document versions and official sources of dependencies, but do not yet provide scripts and build options to automatically fetch the latest stable release of external dependencies

Threat: TFA-SC-REPO-01
Description	An attacker can upload malicious versions of TF-A by compromising credentials of administrator accounts on tf.org or GitHub.
Impact	HIGH
Likelihood	LOW
Threat and impact	This attack is like TFA-SC-SRC-MAIN-01, but the likelihood and impact of the two attacks are different. The likelihood of compromising administrator credentials is lower than that of a maintainer’s (assuming both use authentication methods of similar strength) as there are smaller number of administrators than maintainers. On the other hand, the impact is higher since an administrator has more privileges than a maintainer: - An administrator can upload a malicious TF-A contribution unnoticed by other reviewers - An administrator can potentially rewrite the history of the repository to evade detection
Proposed Mitigations	Strong authentication (Follow best practices recommended by GitHub [9])
Mitigations implemented?	Yes, strong authentication is implemented through recommended best practices

Threat: TFA-SC-REPO-02
Description	An attacker can upload malicious versions of TF-A after getting write access to the repository by exploiting a vulnerability on tf.org or GitHub.
Impact	HIGH
Likelihood	LOW
Threat and impact	There are no reports of someone exploiting a vulnerability on GitHub or tf.org to upload malicious contributions. However, there are examples of vulnerabilities that allowed arbitrary code execution on popular hosting services [12]. Such vulnerabilities can potentially be used to upload malicious packages. In addition to being hard to exploit, vulnerabilities on popular hosting sites such as GitHub are typically detected quickly, making the window of opportunity for such attack small.
Proposed Mitigations	Monitor alerts of any vulnerabilities that might affect TF-A repository Ensure tf.org is up to date with latest security patches
Mitigations implemented?	Yes, alerts of vulnerabilities are monitored and tf.org is ensured to be up to date with the latest security patches

Threat: TFA-SC-REPO-03
Description	An attacker can host a malicious version of TF-A on an attacker-controlled repository, and trick end-users into downloading from that repository.
Impact	HIGH
Likelihood	MEDIUM
Threat and impact	It is not difficult for an attacker to create a website with a similar domain name and look as tf.org (website spoofing) and host a malicious TF-A source repository. Similarly, an attacker can create a mirror of the TF-A repository on GitHub with malicious code in it. However, for this attack to succeed the attacker needs to trick the end-user into using the attacker-controlled repositories.
Proposed Mitigations	Users should carefully check the URL of the website before visiting it and the URL of the repository before checking it out Accept reports of spoofing attacks on tf.org and broadcast a warning to partners
Mitigations implemented?	We accept reports of spoofing attacks on tf.org and will broadcast a warning to partners

Threat: TFA-SC-TOOL-01
Description	Malicious code can be injected at build time through malicious tools.
Impact	HIGH
Likelihood	LOW
Threat and impact	End-users of TF-A use make (or cmake), compilers and linkers (armgcc, armclang or LLVM) to build TF-A binaries. Although TF-A documentation specifies versions and official sources of tools used to build TF-A, users can potentially be tricked into using unofficial, malicious toolchains. Similar attacks have been used in the past to inject malicious code into final products [13].
Proposed Mitigations	Explicitly document versions and official sources of toolchains Provide scripts to automatically fetch the latest stable release of toolchains
Mitigations implemented?	We explicitly document versions and official sources of toolchains, but have not yet provided scripts to automatically fetch the latest stable release of toolchains

Threat: TFA-SC-TOOL-02
Description	Malicious code can be executed by developer’s tools at installation time through malicious Node.js dependencies.
Impact	HIGH
Likelihood	LOW
Threat and impact	Users of the Node.js tools, including the CI, may be exposed to malicious dependencies that have been missed by the Node.js dependency auditor. Users of these tools could potentially be executing malicious code when using these tools, which could potentially allow a malicious actor to make silent modifications to the repository or enable retrieval of user credentials. If successful, the impact can range from low to high depending on the user’s credentials. If the user is an administrator, this could imply TFA-SC-REPO-01.
Proposed Mitigations	Limit Node.js tools to a minimal set of trusted packages Pin Node.js packages to known versions Update dependencies for which Node.js’s auditor reports known CVEs Execute Node.js tools in the CI only from within a trusted container
Mitigations implemented?	Yes, Node.js tools are limited to a minimal set of trusted packages, packages are pinned to known versions, dependencies are updated when there are known CVEs reported, and Node.js tools are only executed within a trusted container in CI

11.2.6. Appendix A

Summary of trustedfirmware.org security:

Table 2: Security information of trustedfirmware.org
Software/ System	Source and integrity	Credential and permission management	Security incident response plan
Jenkins (including plugins)	Jenkins is built using Dockerfile which is based on the official Jenkins docker image Jenkins plugins are built using the official install- plugins.sh	Use oauth from Github only The password strength follows Github policy Do not enforce using two-factor authentication Jenkins uses matrix auth which allows users to manage “job” level ACL using Jenkins Job Builder No API token enabled Jenkins uses the inbuilt credential store where we store credentials for LAVA, Jenkins Job Builder, DockerHub, AWS and Gerrit tokens. The credentials are stored as a secret in Jenkins credential store. These credentials can be accessed via a Jenkins job, but someone would have to push a Jenkins Job through a Gerrit review to do this. Gerrit maintains the ACL for this and only admins and project approver can +2 a review.	Monitor CVE’s and update Jenkins LTS on a monthly cycle Keep plugins up- to-date. But it is up to the plugin owner to maintain said plugin
Gerrit (including plugins)	Gerrit package is installed from Linaro top level role, which has a md5sum check Gerrit Plugins are installed from Ansible playbook, from the official Gerrit CI. The plugins are downloaded from https://gerrit- ci.gerritforge. com/ Do not check md5sum for every plugin	Use oauth from Github only The password strength follows Github policy Do not enforce using two-factor authentication Gerrit has ACL setup within the UI per-project level No API token enabled A ci-bot-user created for getting comments from Jenkins	Keep plugins up- to-date. But it is up to the plugin owner to maintain said plugin
Git	Package is from Linaro OBS (Open Build Service) with a couple of “Linaro modifications”. (reference: Ansible playbook and cgit repo) No special integrity check	All credentials use GitHub. So password strength etc are based on GitHub policy	Monitor all CVE’s and apply them immediately and keep servers up-to-date monthly The security incident response plan is working in progress
Mailman	Installed from Ubuntu- distributed package No special integrity check (reply on APT security)	It has administrator passwords for the various mailing lists The password strength is not specified	Plan to monitor the CVE’s but no timetable at the moment
Website	The website is built on the IT Services’ CI/CD server, bamboo.linaro.org, from a Jekyll git repository stored on GitHub	There are no credentials associated with the website itself. Any permissions required by bamboo to carry out its tasks are provided through AWS instance role permissions	The websites themselves are static files hosted on AWS S3 and cached by AWS CloudFront The software used to build the website is all open source and Linaro occasionally gets reports from GitHub when an issue is detected. Apply a fix if it is available. This includes any Javascript frameworks that might be used within the web pages
ReadTheDocs	One webhook ID per project is used by TF CI for building documentation hosted by ReadTheDocs Secret token supplied as part of the webhook post build Updated content goes live automatically	One TF-A account with password stored in engineering password database is used to manage documentation Access request is required for database access Token for Jenkins webhook for CI uses secret credential storage in internal Jenkins and viewable only through ReadTheDocs admin page	Keep database access list up to date Monitor security advisories