目录
一、简介
二、TF-A 概述
2.1、TF-A 存储库
2.2、外部依赖
2.3、附加二进制文件
2.4、TF-A工具链
2.5、基础设施
三、TF-A数据流
四、攻击树
五、威胁评估与缓解
5.1、影响和可能性评级
5.2、威胁和缓解措施
六、附录
一、简介
软件供应链攻击旨在向软件产品注入恶意代码。恶意代码可以通过几种方式注入到软件产品（开源项目）中。这些方式包括：
• 恶意代码提交：这种攻击直接将代码注入到项目库（repository）中。例如，可以通过开发者/维护者凭证劫持或恶意外部贡献者来实现这一点。
• 恶意依赖项：在这种情况下，恶意代码通过项目依赖的其他代码或软件包引入到项目中。例如，通过typosquatting attack，攻击者创建一个与通用软件包名称非常相似的恶意软件包，并将其托管在通用的软件包库上。
• 恶意工具链：这涉及通过被攻击的资源引入的恶意代码，这些资源在开发和/或构建过程中使用，如编译器和集成开发环境（IDE）。
二、TF-A 概述
下图显示了围绕TF-A项目的不同软件组件。下面提供了每个组件的简要描述。
2.1、TF-A 存储库
TF-A存储库包含由TF-A贡献者提供的通用和平台代码，以及从其他开源项目导入的库，如上图中的内部依赖项所示。这些库包括：
• libfdt：libfdt是用于读取和操作设备树二进制（DTB）文件的实用程序库。它是设备树编译器（DTC）工具链的一部分。DTC用于在主机机器上的构建过程中构建DTB文件。libfdt用于在启动时解析DTB文件。
• zlib：zlib是从zlib Home Site导入的数据压缩库。
• compiler-rt：这是来自LLVM编译器基础设施项目的一组运行时库。我们导入了builtins库，该库提供了来自compiler-rt的低级别、特定于目标的编译器builtins。
TF-A存储库还包括用于补充TF-A构建过程的主机工具的源代码。这些工具包括：
• fiptool：此工具用于创建固件镜像包（FIP），允许将引导加载程序镜像打包到一个单一的archive中，TF-A可以从非易失性平台存储加载。
• cert_create：此工具用于为二进制镜像生成证书。
• encrypt_fw：此工具以明文固件镜像为输入，并生成加密的固件镜像，然后可以将其作为输入传递给fiptool utility以创建FIP。
• sptool：此工具用于构建安全分区包。
2.2、外部依赖
这些软件组件不是TF-A存储库的一部分，但它们是构建TF-A二进制文件和主机工具所必需的。
• Mbed TLS库：这是来自trustedfirmware.org（tf.org）的密码学库。在需要密码学功能的TF-A二进制文件（例如可信引导（Trusted Board Boot)）构建中需要它。
• OpenSSL库：这是TF-A主机工具（fiptool、cert_create和encrypt_fw）使用的另一个加密库。
下表列出了TF-A的依赖项，包括依赖项的来源。
| Dependency | Location of Dependency | Original Source |
|---|---|---|
| libfdt | Local copy | dtc/dtc.git - The Device Tree Compiler |
| zlib | Local copy | zlib Home Site |
| compiler-rt | Local copy | "compiler-rt" Runtime Library |
| Mbed TLS | External | Mbed TLS |
| OpenSSL | External | /index.html |
2.3、附加二进制文件
这些是用于测试基于TF-A系统的二进制文件。以下是每个组件的简要描述及其来源。
• SCP固件：在我们的测试中，我们使用Arm SCP团队提供的SCP固件二进制文件，这些二进制文件是从GitHub存储库中构建的源代码获取的。
• OP-TEE：来自tf.org的可信执行环境（TEE），作为Secure EL1运行。根据测试配置，我们使用从源代码构建或与Arm参考平台一起提供的OP-TEE二进制文件。
• EDK2 UEFI：来自EDK2项目的正常世界引导加载程序。我们使用托管在tf.org服务器上的EDK2 UEFI二进制文件进行测试。
用于测试TF-A的其他软件组件包括U-Boot、Linux内核、RSS、MCP和文件系统，所有这些都来自Arm参考平台团队。
2.4、TF-A工具链
2.4.1、Node.js工具
这些是可选的质量保证和开发人员实用工具，通过Node.js软件包管理器安装。它们被固定到TF-A存储库根目录中的package.json文件描述的特定版本，并且它们的依赖关系在安装时从互联网上下载。这些工具可以在开发者的本地机器上安装，并在某些CI作业中安装在Docker容器中。目前，这些工具包括：
• Commitlint
• Commitizen
• Husky
2.5、基础设施
TF-A使用trustedfirmware.org（tf.org）和Arm基础设施来托管源代码、审查代码和运行测试。附录部分提供了tf.org基础设施的安全分析。
三、TF-A数据流
下图显示了TF-A的数据流程图。红虚线表示信任边界。
四、攻击树
五、威胁评估与缓解
5.1、影响和可能性评级
| Rating | Impact | Likelihood |
|---|---|---|
| HIGH | 如果被利用，将对整个组织或单个业务线产生重大影响。 | 攻击者相对容易利用威胁，只需很少的努力和技巧。 |
| MEDIUM | 如果被利用，对业务线有明显的影响。 | 专业攻击者可以毫不费力地利用这种威胁。 |
| LOW | 如果被利用，则会造成轻微损害，或者可以与其他漏洞一起使用来执行更严重的攻击。 | 利用这种威胁需要相当大的努力和资源。 |
5.2、威胁和缓解措施
威胁命名约定：
-
SC – Supply Chain
-
SRC – Source
-
DEP – Dependency
-
TOOL – Toolchain
-
REPO – Repository
-
MAIN – Maintainer
-
CONT – Contributor
| Threat: TFA-SC-SRC-MAIN-01 | |
|---|---|
| Description | 攻击者可以在泄露维护者的凭证后冒充维护者提交并合并恶意代码。 |
| Impact | HIGH |
| Likelihood | MEDIUM |
| Threat and impact | 在 TF-A 代码审查流程中，所有提交的更改都会由代码所有者和维护者进行审查。如果更改被接受，将由维护者将其合并（集成）到一个集成分支中。维护者有权进行代码所有者审查、维护者审查和合并提交的更改。 tf.org 用户（包括维护者）通过 GitHub 进行身份验证。凭据泄露的可能性取决于多个因素。如果遵循推荐的最佳实践，GitHub 的身份验证机制就很强大，使凭据泄露的可能性降低。GitHub（因此 tf.org）允许使用双因素身份验证登录，需要密码和用户身份验证代码的访问权限。根据密码的强度和维护者是否在服务之间重复使用密码等因素，泄露的可能性可能更高。 如果攻击者成功地窃取了维护者的凭据，并冒充维护者，他们理论上可以提交恶意更改（作为维护者或贡献者），给予所有必要的审查并合并更改。 |
| Mitigations | - 强制执行GitHub推荐的最佳实践 - 不允许提交者自我审查和合并他们提交的补丁。要实现提交，攻击者将需要损害至少两个凭证(审阅者和维护者)。 |
| Mitigations implemented? | 我们没有禁止自我审查/合并补丁 |
| Threat: TFA-SC-SRC-MAIN-02 | |
|---|---|
| Description | 攻击者可以通过社会工程技术成为维护者，并提交、合并恶意代码。 |
| Impact | HIGH |
| Likelihood | LOW |
| Threat and impact | 根据TF项目维护流程，TF-A的维护者是由同行根据功绩选择的。成为维护者的一些标准包括至少在项目中担任活跃成员一段时间，并贡献了大量非平凡且高质量的补丁。然而，该流程存在一些弱点：
要执行这样的攻击，除了成为维护者外，攻击者还必须应对维护者面临的所有限制。 |
| Mitigations | -与维护者建立信任的结构化机制 -不允许提交者自我审查和合并他们提交的补丁。要实现提交，攻击者将需要损害至少两个凭证(审阅者和维护者)。 |
| Mitigations implemented? | 有一个结构化的机制来与维护者建立信任，但是补丁的自我审查/合并是不允许的 |
| Threat: TFA-SC-SRC-CONT-01 | |
|---|---|
| Description | 攻击者可以作为贡献者提交恶意代码补丁。 |
| Impact | HIGH |
| Likelihood | LOW |
| Threat and impact | TF-A接受外部对通用代码和平台代码的贡献。与维护者不同，贡献者没有维护者审查或合并权限，因此作为贡献者注入恶意代码的可能性较低。然而，尽管不太可能，恶意提交仍然有可能在代码审查和验证过程中被忽略而不被察觉。 如果成功，其影响可能从低到高，这取决于注入的代码。例如，攻击者可以故意插入一个在代码审查中难以察觉并且不会被验证过程检测到的内存损坏漏洞。这种漏洞本身可能影响较小，但如果与其他漏洞结合使用，则可能产生重大影响。 |
| Proposed Mitigations |
|
| Mitigations implemented? | 是的，贡献要经过彻底的审查、验证，以及通过CI自动化的静态分析过程。 |
| Threat: TFA-SC-DEP-01 | |
|---|---|
| Description | 攻击者可以将恶意代码注入TF-A的内部依赖项中。 |
| Impact | HIGH |
| Likelihood | LOW |
| Threat and impact | TF-A有两种类型的依赖关系：一种是复制到TF-A存储库并作为TF-A代码的一部分进行发布的依赖关系（以下称为内部依赖关系），另一种是从外部存储库下载并在构建TF-A时使用的依赖关系（以下称为外部依赖关系）。
目前，TF-A有三个内部依赖关系：libfdt、zlib和compiler-rt库。这些库定期通过从它们的源存储库复制而进行更新。尽管不太可能，但贡献者有可能从错误的（潜在恶意的）存储库复制这些库。例如，GitHub上已经存在多个libfdt（DTC）的分支。除此之外，官方存储库也不免受到上述威胁（TFA-SC-SRC-MAIN-01、TFA-SC-SRC-MAIN-02和TFA-SC-SRC-CONT-01）。
与外部依赖关系相比，通过内部依赖关系对TF-A进行攻击的可能性较低，原因如下：
|
| Proposed Mitigations |
|
| Mitigations implemented? | 是的，我们显式地记录版本和依赖的官方来源，保留固定版本的源代码副本，并监控Python和Node.js的脆弱依赖警报，但我们无法对C依赖做这些。 |
| Threat: TFA-SC-DEP-02 | |
|---|---|
| Description | 攻击者可以将恶意代码注入TF-A外部依赖项中。 |
| Impact | HIGH |
| Likelihood | MEDIUM |
| Threat and impact | 与内部依赖关系不同，外部依赖关系是由最终用户从外部存储库下载的。虽然TF-A文档提供了有关测试使用的依赖版本的信息和存储库链接，但是由最终用户决定从哪里获取依赖关系。因此，与内部依赖关系相比，通过外部依赖关系进行攻击的可能性更高。 攻击的影响范围从低到严重不等，这取决于受影响的依赖关系及其哪些部分受到影响。例如，影响MbedTLS中签名验证功能的恶意代码被认为是严重的，因为它可以用于绕过TF-A的TBB过程。 |
| Proposed Mitigations |
|
| Mitigations implemented? | 我们明确地记录版本和依赖的官方来源，但还没有提供脚本和构建选项来自动获取外部依赖的最新稳定版本 |
| Threat: TFA-SC-REPO-01 | |
|---|---|
| Description | 攻击者可以通过破坏tf.org或GitHub上管理员帐户的凭据上传恶意版本的TF-A。 |
| Impact | HIGH |
| Likelihood | LOW |
| Threat and impact | 这种攻击类似于TFA-SC-SRC-MAIN-01，但两种攻击的可能性和影响不同。 假设管理员和维护者都使用相似强度的身份验证方法，那么妨害管理员凭据的可能性要低于妨害维护者的可能性，因为管理员的数量比维护者少。另一方面，影响会更大，因为管理员比维护者拥有更多的特权： • 管理员可以上传恶意的TF-A贡献，而其他审阅者可能未能察觉到。 • 管理员有可能重写存储库的历史记录以逃避检测。 |
| Proposed Mitigations | 强认证(遵循GitHub推荐的最佳实践) |
| Mitigations implemented? | 是的，强身份验证是通过推荐的最佳实践实现的 |
| Threat: TFA-SC-REPO-02 | |
|---|---|
| Description | 攻击者可以利用tf.org或GitHub上的漏洞，在获得对存储库的写访问权后，上传恶意版本的TF-A。 |
| Impact | HIGH |
| Likelihood | LOW |
| Threat and impact | 目前没有关于有人利用GitHub或tf.org上的漏洞上传恶意贡献的报告。然而，有一些漏洞的例子允许在流行的托管服务上执行任意代码。这些漏洞可能被用来上传恶意软件包。除了难以利用之外，像GitHub这样的流行托管网站上的漏洞通常会很快被检测到，使得这种攻击的机会窗口很小。 |
| Proposed Mitigations |
|
| Mitigations implemented? | 是的，对漏洞的警报进行监控，并确保tf.org与最新的安全补丁保持同步 |
| Threat: TFA-SC-REPO-03 | |
|---|---|
| Description | 攻击者可以在攻击者控制的存储库上托管恶意版本的TF-A，并欺骗最终用户从该存储库下载。 |
| Impact | HIGH |
| Likelihood | MEDIUM |
| Threat and impact | 对于攻击者来说，创建一个类似于tf.org的网站并看起来与其相似（网站仿冒），并托管一个恶意的TF-A源代码存储库并不困难。同样，攻击者可以在GitHub上创建TF-A存储库的镜像，并在其中插入恶意代码。然而，要使此攻击成功，攻击者需要诱使最终用户使用由攻击者控制的存储库。 |
| Proposed Mitigations |
|
| Mitigations implemented? | 我们接受对tf.org进行欺骗攻击的报告，并将向合作伙伴广播警告 |
| Threat: TFA-SC-TOOL-01 | |
|---|---|
| Description | 恶意代码可以通过恶意工具在构建时注入。 |
| Impact | HIGH |
| Likelihood | LOW |
| Threat and impact | TF-A的最终用户使用make（或cmake）、编译器和链接器（如armgcc、armclang或LLVM）来构建TF-A二进制文件。虽然TF-A文档指定了用于构建TF-A的工具的版本和官方来源，但用户可能会被诱使使用非官方的、恶意的工具链。类似的攻击过去曾被用来向最终产品中注入恶意代码。 |
| Proposed Mitigations |
|
| Mitigations implemented? | 我们明确地记录了工具链的版本和官方来源，但还没有提供脚本来自动获取工具链的最新稳定版本 |
| Threat: TFA-SC-TOOL-02 | |
|---|---|
| Description | 恶意代码可以在安装时通过恶意Node.js依赖被开发人员的工具执行。 |
| Impact | HIGH |
| Likelihood | LOW |
| Threat and impact | 使用Node.js工具的用户，包括CI，可能会接触到被Node.js依赖审计程序所忽略的恶意依赖。当使用这些工具时，用户可能会执行恶意代码，这可能允许恶意行为者对存储库进行悄无声息的修改或者获取用户凭据。 如果成功，其影响可能从低到高不等，取决于用户的凭据。如果用户是管理员，这可能意味着TFA-SC-REPO-01。 |
| Proposed Mitigations |
|
| Mitigations implemented? | 是的，Node.js工具仅限于一组最小的可信包，包被固定到已知版本，当有已知cve报告时，依赖项会更新，Node.js工具只在CI中的可信容器中执行 |
六、附录
trustedfirmware.org安全概述：
| Software/ System | Source and integrity | Credential and permission management | Security incident response plan |
|---|---|---|---|
| Jenkins (including plugins) |
|
|
|
| Gerrit (including plugins) |
|
| • 保持插件更新。但是维护插件取决于插件所有者。 |
| Git |
| 所有凭据都使用GitHub。所以密码强度等是基于GitHub策略 |
|
| Mailman |
|
| • 计划监测CVE，但目前没有时间表 |
| Website | 该网站建立在IT Services的CI/CD服务器bamboo.linaro.org上，来自GitHub上存储的Jekyll git存储库 | 没有与网站本身相关联的凭证。bamboo执行其任务所需的任何权限都是通过AWS实例角色权限提供的 |
|
| ReadTheDocs |
|
|
|
参考：11.2. TF-A Supply Chain Threat Model — Trusted Firmware-A 2.10.0 documentation
