一、Galois：使用自动化软件多样性保护应用程序
（接上文）
成功：强大的防御
CFAR计划包括一个独立的团队，负责对我们的技术进行定期安全评估。在这些评估中，我们的防御措施阻止了评估团队利用以下具体实例：
•代码和数据信息泄露漏洞（包括类似于“Heartbleed”的漏洞）
•堆栈变量损坏：溢出和偏移损坏漏洞
•全局变量的损坏：溢出和偏移损坏漏洞
•堆对象损坏：溢出和偏移损坏漏洞
•释放后使用漏洞，包括使用堆修饰
•控制流劫持漏洞，包括使用ROP
评估团队根据常见的CWE（取自社区开发的“常见弱点枚举”列表）对漏洞进行建模，旨在代表在野外发现的漏洞。
即使赋予评估团队强大的能力，我们的防御还是成功的，包括：
•完全访问应用程序源和原始应用程序中的漏洞知识
•全面了解所有变体二进制文件，具有在线和离线检查功能
随着计划的进展，评估扩大到为评估团队提供更多能力，旨在为不常出现的漏洞或防御者的其他预想场景建模。这包括向评估团队提供有关运行时内存布局的信息，甚至是每个变体在多变体环境中运行时的完整内存内容，模拟侧通道信息（例如通过Meltdown/Spectre样式攻击）。即使在这些恶劣的操作条件下，我们的防御也取得了成功。
我们生成的变体在集合受到攻击时表现不同，从而使我们能够通过观察变体行为的这些差异来检测攻击。检测到攻击后，我们可以重新启动变体或将变体回滚到已知的良好状态，在某些情况下，我们可以通过修复损坏的状态并安全地继续执行来做得更好。我们的想法是我们构建变体集，以便某些攻击不能同时破坏所有变体中的相同状态，并且我们使用来自其他变体的未破坏状态来修复损坏的程序状态。
实际设计决策
我们设计了变体集转换以保留程序员指定的合法行为，而且我们改变了源语言规范留下实现特定的许多方面。这可以防止或揭示许多常见类型的攻击，并且正确编写的代码将不依赖于我们更改的未定义行为的属性。
为了支持可能包括违反语言标准的实际代码的多样化，我们支持各种“白名单”技术，以省略特定问题区域、函数、变量或数据结构的多样化。使用这些工具和技术，我们已经能够为每个通过各自测试套件的 Apache、nginx、lighttpd和thttpd Web服务器生成多样化的多变体集。
MVEE在进行系统调用等敏感操作时会短暂暂停并交叉检查变体，但只要主机有资源（CPU和内存）来容纳应用程序的多个实例，变体就会“全速”运行。对CFAR最广泛的性能分析评估是在我们从Apache Web服务器生成的变体集上进行的。我们对 RADSS的性能目标是MVEE大约10%的性能开销和我们的多样性转换的10%开销，并且包含我们大部分转换（组合）的集合在测试中适合这个性能范围。少数具有较大性能影响的转换（例如细粒度的堆对象ID检查）以额外的开销换取针对复杂攻击的额外保护。
结论
软件多样性和多变种执行的结合可以提供强大的保护。但是要充分利用这一点可能会非常棘手，并且简单的最大化软件多样性最终可能会否定您打算添加的保护。
二、Galois：自动化软件多样性有时并非越多越好（摘要）
上一篇介绍了我们的研究，探索保护DARPA CFAR计划中过时应用程序的新策略。简而言之，我们的方法是生成目标应用程序的变体，这些变体在给定良性输入时表现相同，但在给定恶意输入时表现不同。然后我们在多变体执行环境 (MVEE) 中运行一组这些变体，它可以检测行为的差异，揭示缓冲区溢出等攻击，之后我们可以做出反应并恢复。
在这篇文章中，我们描述了一些生成安全变体集的策略，并强调了一些发现，这些发现说明了为什么选择适当的转换可能具有惊人的挑战性，因为在某些情况下，分层额外的防御可能会否定以前应用的保护。
变体生成转换
之前，我们描述了通过使用多样化编译器构建目标应用程序来生成程序变体的工作流程。我们将此称为“多编译器”，并将使程序多样化的特定技术称为“转换”。我们支持的一些转换包括：
*代码布局随机化：在二进制文件中重新排序函数，因此感兴趣的代码存在于每个变体的不同位置。
*全局布局随机化：填充和重新排序全局，因此它们的绝对和相对位置在每个变体中都不同。
*堆栈变量随机化：类似于全局布局随机化，但针对每个堆栈帧中的变量。
*堆布局随机化：运行时过度配置和随机分配以将堆对象放置在每个变体中的不同位置。
*C++ vtable 随机化：重新排序虚函数表条目以检测使用这些代码指针的攻击。
*数据随机化：在将数据存储到内存之前对数据进行异或运算，在加载时进行异或运算。
*数据交叉检查：检查条件中使用的数据值是否对应于集合中的所有变体。
*函数入口交叉检查：确保集合中的变体始终在运行时执行相应的函数。
*细粒度堆对象ID检查：跟踪集合中的分配和交叉检查变体以检测（例如，自由攻击后的使用）。
*结构布局随机化：通常，允许程序员对结构字段的底层顺序做出假设，但在可以安全置换的情况下，这有助于检测结构内的攻击。
运行变体集
内存损坏漏洞很脆弱，因为它们依赖于程序的特定内部和低级属性。通过在每个变体中改变这些属性，我们可以生成变体集，其中针对一个变体的漏洞无法用来针对另一个变体。但是，变体究竟是如何在 MVEE 中一起运行的呢？
不同 MVEE 的功能/性能权衡各不相同，但我们依赖于所有变体同时运行的核心属性，并且 MVEE 统一每个变体和效果（例如系统调用）的输入和输出，以使集合看起来像单个实例到系统的其他部分。
这意味着 MVEE 将攻击者的输入广播到所有变体——攻击者不能向每个变体发送不同的输入。类似地，MVEE 拦截每个变体产生输出或其他系统效应（如文件 I/O）的尝试并统一此输出，或检测、阻止，对行为分歧做出反应。因此，攻击者无法直接查询每个变体，获取特定于变体的数据。
盲目应用软件多样性技术的危害
从概念上讲，如果随机化降低使攻击成功的概率机会为P，并且您将N变体组合在一个集合中，那么人们可能会猜测该集合仍然易受攻击的概率是P^N。事实上，情况并非总是如此，编写软件多样化技术需要小心，因为某些组合可能会否定您认为要添加的安全性。
填充与洗牌
除了打乱变量的顺序之外，我们还可以在变量之间随机填充以增加熵的数量。这在变量很少的区域（例如，小的堆栈帧）似乎特别有吸引力。虽然在某些情况下，填充会使攻击者更难猜测随机布局，但在某些情况下，添加填充会使在多变体环境中检测攻击变得更加困难。
跨栈帧攻击和 SafeStack
代码随机化导致检测到许多缓冲区溢出，这些缓冲区溢出写入堆栈变量缓冲区的末尾并写入父堆栈帧的内容，因为这些溢出破坏了两个堆栈帧之间的返回地址。攻击者的有效载荷必须包含有效的返回地址值，变体用于返回到函数调用者的上下层，其中父堆栈帧中的（损坏的）数据在范围内。精心选择的数据布局（避免上述陷阱）限制了攻击者，使他们无法创建有效载荷，在所有变体中使用有效代码地址覆盖返回地址，而 MVEE 未检测到攻击。同样，攻击者可能无法用所有变体中的有效地址覆盖保存的基指针。
SafeStack是一种堆栈保护技术clang，它将所有潜在的易受攻击的堆栈变量移动到一个单独的“不安全堆栈”。具体来说，地址获取的变量被移动到不安全的堆栈中，因为这些变量通常容易越界访问。这使得返回地址和已知变量只能在“真实”堆栈上安全访问，攻击者无法从不安全堆栈上的溢出中访问。不幸的是，将 SafeStack 添加到变体中可以使攻击者更容易溢出和破坏父堆栈帧中的数据，因为在包含易受攻击的 SafeStack 的“不安全堆栈”上的堆栈帧之间没有保存的返回地址（或保存的基指针等）缓冲区。
在这种情况下，将 SafeStack 添加到变体，实际上引入了以前不可行的纯数据父堆栈帧覆盖的可能性。
危害：数据随机化+“倾斜数据”
上面的示例显示了组合多个转换的一些危险，但我们还必须仔细推理各个转换以了解每个转换的局限性。
我们的“数据随机化”转换使用别名分析来确定可以通过给定内存访问寻址的内存位置集。别名分析的结果用于对数据引用进行分区，并为每个集合分配一个唯一的 XOR“键”。在将数据存储在内存中之前，将变体数据与其对应的密钥进行异或运算，然后在加载时对其进行异或运算。每个变体中的密钥都不同，因此这为受这些密钥保护的数据值提供了与我们从代码随机化中获得的代码指针类似的保护：即使攻击者知道他们在每个变体中需要什么值，他们也无法将不同的值写入每个变体。至少有一种变体以攻击者无法控制的“垃圾”告终。
乍一看，这似乎相当强大：对于 64 位密钥，密钥“排列”为攻击者特定期望值的概率为264/1。但是，有一个问题：“倾斜的数据范围”问题。具体来说，攻击者的期望值可能不会均匀地分布在目标变量的可能值中。考虑代码：
if(is_admin) { ... }
攻击者不需要完全控制is_admin每个变体中的内容，而只需is_admin在整个集合中使用非零，即使数据随机化也是极有可能的。
我们的解决方案是插入数据交叉检查，以确保条件中使用的值的确切内容在变量集中是等效的。在变体生成期间，我们检测变体以在运行时将这些值传递给 MVEE 监视器，因此 MVEE 可以在集合中的所有变体之间进行比较。这最大化了我们的数据随机化转换的价值，因为现在 MVEE 检测到如果is_admin在每个变体中具有不同的值的不同行为，条件表达式在每个变体中都被评估为真。插入这些交叉检查需要一些额外的分析以避免交叉检查指针值，因为我们的预计地址会因我们的其他转换而在集合中变化。
结论
软件多样性转换以微妙的方式相互作用，可能会影响多变量集的安全性，并且单纯的最大化随机性并不能最大化检测攻击的机会。我们通过采取更有条理的方法来加强我们的防御。
（来源：综合外网及外媒等。本文参考内容均来源于网络，仅供读者了解和掌握相关情况参考，不用于任何商业用途。侵删）