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工具链

TF-A项目使用多种工具来构建、分析和测试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进行攻击的可能性较低，原因如下： * 内部依赖关系在升级过程中经过正常的代码审查流程 * 一旦升级，内部依赖关系将保持不变，直到下一次升级。升级窗口通常很长（例如，过去4年中libfdt仅更改了4次），这减少了攻击者向依赖关系注入恶意代码的机会窗口。
Proposed Mitigations	* 显式地记录版本和依赖项的官方来源 * 在TF-A树中保留一个固定版本的源代码副本，这样只有当我们升级依赖项时，才会出现从依赖项中获得恶意代码的风险 * 监控来自GitHub的脆弱依赖的警报
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	* 监视可能影响TF-A存储库的任何漏洞警报 * 确保tf.org安装了最新的安全补丁
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	* 用户在访问网站之前应该仔细检查网站的URL，在签出之前应该仔细检查存储库的URL * 接受对tf.org进行欺骗攻击的报告，并向合作伙伴广播警告
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	* 将Node.js工具限制为一组最小的可信包 * 将Node.js包固定到已知版本 * 更新Node.js审计员报告已知cve的依赖项 * 只能从可信容器内执行CI中的Node.js工具
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)	* Jenkins是使用基于官方Jenkins docker镜像的Dockerfile构建的 * Jenkins插件是使用官方的install- plugins.sh构建的	* 只从Github使用oauth * 密码强度遵循Github策略 * 不强制使用双因素身份验证 * Jenkins使用矩阵认证，允许用户使用Jenkins job Builder管理"作业"级别的ACL * 未启用API令牌 * Jenkins使用内置的凭证存储，我们存储LAVA, Jenkins Job Builder, DockerHub, AWS和Gerrit令牌的凭证。凭据作为秘密存储在Jenkins凭据存储库中。这些凭证可以通过Jenkins作业访问，但是必须有人通过Gerrit审查来推动Jenkins作业。Gerrit为此维护ACL，并且只有管理员和项目审批人可以+2审查。	* 每月监测CVE并更新Jenkins LTS * 保持插件更新。但是维护插件取决于插件所有者。
Gerrit (including plugins)	* Gerrit包是从Linaro的顶级角色安装的，它有一个md5sum检查 * Gerrit插件是通过Ansible playbook从官方的Gerrit CI安装的。这些插件是从https://gerrit-ci.gerritforge.com/下载的。 * 不检查每个插件md5sum	* 只从Github使用oauth * 密码强度遵循Github策略 * 不强制使用双因素身份验证 * Gerrit在每个项目级别的UI中设置了ACL * 未启用API令牌 * 为获取Jenkins的评论而创建的ci-bot用户	• 保持插件更新。但是维护插件取决于插件所有者。
Git	* 包是来自Linaro OBS(开放构建服务)与一对"Linaro修改"。(参考:Ansible playbook和git repo) * 没有特别的完整性检查	所有凭据都使用GitHub。所以密码强度等是基于GitHub策略	* 监控所有CVE并立即应用，每月更新服务器 * 安全事件响应计划正在进行中
Mailman	* 从Ubuntu-分发包安装 * 没有特别的完整性检查(回复APT安全性)	* 它有各种邮件列表的管理员密码 * 未指定密码强度	• 计划监测CVE，但目前没有时间表
Website	该网站建立在IT Services的CI/CD服务器bamboo.linaro.org上，来自GitHub上存储的Jekyll git存储库	没有与网站本身相关联的凭证。bamboo执行其任务所需的任何权限都是通过AWS实例角色权限提供的	* 网站本身是托管在AWS S3上的静态文件，由AWS CloudFront缓存 * 用于构建网站的软件都是开源的，当检测到问题时，Linaro偶尔会从GitHub获得报告。如果可用，应用修复程序。这包括任何可能在网页中使用的Javascript框架
ReadTheDocs	* 每个项目一个webhook ID被TF CI用于构建ReadTheDocs托管的文档 * 作为webhook post构建的一部分提供的秘密令牌 * 更新后的内容自动上线	* 文档管理使用一个TF-A账号，其密码存储在工程密码数据库中 * 访问数据库需要访问请求 * 用于CI的Jenkins webhook令牌在Jenkins内部使用秘密凭证存储，并且只能通过ReadTheDocs管理页面查看	* 保持数据库访问列表的更新 * 监控安全通告

参考：11.2. TF-A Supply Chain Threat Model --- Trusted Firmware-A 2.10.0 documentation