DEP与ASLR的有效性分析

DEP（数据执行防护）和ASLR（地址空间布局随机化）已被证明是针对当前常见漏洞利用的重要且有效的防护措施。当然，任何有用的防护技术都会受到 scrutiny，过去一年中，关于绕过DEP和ASLR的研究和讨论越来越多[1,2]。本文旨在通过分析攻击研究中概述的绕过技术，讨论这些防护措施的有效性。关键要点包括：

DEP和ASLR旨在增加攻击者的漏洞开发成本并降低其投资回报率
DEP和ASLR的组合能有效阻断当前常见的漏洞利用，但在某些情况下可能被绕过
针对Microsoft和第三方漏洞的利用已能在浏览器和第三方应用环境中绕过DEP和ASLR
目前尚未发现能绕过Windows内置服务及其他应用域中DEP和ASLR的远程利用
对潜在绕过技术的了解直接指导我们改进DEP、ASLR及其他防护技术的鲁棒性和弹性

DEP有效性（无ASLR）

在之前的博客系列中，我们详细介绍了DEP的原理和工作方式[第一部分, 第二部分]。简而言之，DEP的目的是防止攻击者将数据当作代码执行，从而阻止攻击者直接从栈、堆及其他非代码内存区域执行代码。因此，堆喷射（shellcode）或返回到栈等利用技术无法直接实现。

DEP的有效性取决于攻击者能否：1）利用已可执行的代码；或2）使攻击者的数据变为可执行（从而表现为代码）。在没有ASLR的平台（即Windows Vista之前的版本）上，攻击者通常能轻松找到并利用加载在进程地址空间可预测位置的模块（DLL和EXE）中的代码。返回导向编程（ROP）是攻击者如何使用加载模块中的代码替代（或作为跳板）其shellcode的最广泛示例[3,1]。除了加载的模块，某些设施（如即时编译器）可能允许攻击者生成部分内容可控的可执行代码，从而在其他合法指令流中嵌入shellcode（“JIT喷射”）[2]。

没有ASLR时模块加载在可预测地址的事实也使攻击者能够将其数据变为可执行代码。实现方式多样，但基本方法是使用加载模块中的代码调用系统函数（如VirtualAlloc或VirtualProtect）来使攻击者的数据变为可执行。

总结：DEP打破了攻击者传统依赖的利用技术，但无ASLR的DEP在大多数情况下不足以防止任意代码执行。

ASLR有效性（无DEP）

攻击者在开发漏洞利用时通常对进程的地址空间布局做出假设。例如，攻击者通常假设模块将加载在可预测地址，或所有PC的特定地址存在可读/可写内存。ASLR旨在通过使进程的地址空间布局对无本地机器访问权限的攻击者未知来打破这些假设，从而防止攻击者直接可靠地利用加载模块中的代码。

ASLR的有效性取决于地址空间布局的完全未知性。在某些情况下，尽管有ASLR，内存可能跨PC映射到可预测地址。当DLL或EXE因未通过/DYNAMICBASE链接器标志选择加入ASLR而加载到可预测地址时，可能发生这种情况。在Internet Explorer 8.0之前，攻击者还可能强制某些类型的.NET模块在浏览器环境中加载到可预测地址[6]。攻击者还可以使用各种地址空间喷射技术（如堆喷射或JIT喷射）将代码或数据放置在地址空间的可预测位置。

在地址空间初始不可预测的情况下，攻击者可以尝试通过地址空间信息泄露或暴力破解来发现某些内存区域的位置[5]。地址空间信息泄露发生在攻击者能够强制应用程序泄漏一个或多个地址（如DLL内函数的地址）时。例如，如果攻击者能够覆盖字符串的NUL终止符，然后强制应用程序从字符串读取并将输出提供回攻击者，则可能发生这种情况[4]。读取字符串的行为将导致返回相邻内存，直到遇到NUL终止符。这只是一个例子；地址空间信息泄露可以采取许多其他形式。

另一方面，暴力破解可能允许攻击者针对有用代码或数据可能存在的所有可能地址多次尝试其利用，直到成功。暴力破解攻击虽然在某些情况下可能，但传统上在攻击Windows应用程序时不实用，因为错误的猜测将导致应用程序终止。可能遭受暴力攻击的应用程序（如Windows服务和Internet Explorer）通常采用重启策略，旨在防止进程在发生一定数量的崩溃后自动重启。但需要注意的是，在某些情况下可以在Windows上执行暴力攻击，例如当目标应用程序的易受攻击代码路径包含在全面异常块中时。

某些类型的漏洞也可能使使用所谓的部分覆盖绕过ASLR成为可能。该技术依赖于攻击者能够覆盖地址的低位（不受ASLR随机化影响）而不扰动高位（由ASLR随机化）。

总结：ASLR打破了攻击者对进程地址空间中代码和数据位置的假设。如果攻击者能够预测、发现或控制某些内存区域（特别是DLL映射）的位置，ASLR可能被绕过。DEP的缺失可能允许攻击者使用堆喷射将代码放置在地址空间的可预测位置。

DEP+ASLR有效性

在前几节中，我们描述了DEP和ASLR单独的有效性。实际上，DEP和ASLR设计为在Windows Vista及更高版本中组合使用。这两种防护在重要应用程序（如Internet Explorer 8、Microsoft Office 2010以及随OS提供的内置服务和应用程序）的环境中启用。这意味着试图在这些环境中利用漏洞的攻击者需要克服这两个障碍（以及许多其他防护）。

当前攻击研究中探索的DEP+ASLR绕过技术主要集中于识别和改进绕过ASLR的方法。一旦ASLR被绕过，通常可以使用已建立的技术（如返回导向编程）轻松绕过DEP。目前，已有多个利用实践证明了在特定应用域（如浏览器和第三方应用程序）中绕过DEP+ASLR组合的可能性。这些利用通过使用可预测的DLL映射、地址空间信息泄露或JIT喷射绕过了ASLR，并通过使用返回导向编程（或其更简单变体）或JIT喷射绕过了DEP。在许多情况下，这些利用依赖于由第三方组件附带的DLL或非默认浏览器插件中包含的JIT编译功能引起的可预测映射。这意味着如果未安装所需组件，这些利用将失败。

尽管已编写出能够绕过DEP+ASLR组合的利用，但迄今为止编写的大多数利用不具备此类能力，而是严格针对未启用这些防护的应用程序和平台。这证实了我们的立场：尽管当前实现存在弱点，DEP+ASLR是针对当前常见攻击的强大防护措施。

总结：DEP+ASLR组合使用时最有效；但其组合有效性 heavily dominated by ASLR的有效性。已开发出能够在浏览器和第三方应用程序环境中绕过DEP+ASLR的利用。尽管如此，迄今为止编写的大多数利用未尝试绕过DEP+ASLR组合。

未来方向

展望未来，攻击者显然会越来越 incentivized 尝试开发能够绕过DEP+ASLR组合的利用。我们对DEP和ASLR绕过方式的了解直接指导我们改进防护技术鲁棒性和弹性的未来工作。尽管这项工作正在进行中，但我们想强调两个值得注意的改进。

第一个改进可见于最新版本的增强缓解体验工具包（EMET），现在支持称为强制ASLR的功能。该功能强制所有模块使用ASLR，无论它们是否支持ASLR（在Windows Vista及更高版本上启用时有效消除可预测的DLL映射）。这解决了我们之前描述的ASLR绕过技术，并在实践中用于成功缓解野外利用。第二个改进包括已直接纳入Internet Explorer 9测试版中最近发布的JavaScript JIT编译器的JIT喷射缓解措施。这些缓解措施作为对抗攻击研究中描述的JIT喷射技术的对策。

这两个改进有助于进一步说明我们的信念：DEP、ASLR及一般漏洞利用防护极其重要，因为它们对开发可靠利用的成本产生影响，并对攻击者提出知识要求。此类防护使我们能够主动为可能运行具有未知或未修补漏洞的软件的客户提供额外保护。最终，我们关于漏洞利用防护的目标是达到漏洞可靠利用成本过高的程度——这是我们积极努力的目标。

建议

对于企业和用户

我们建议企业和用户为所有关键应用程序启用DEP，并运行支持ASLR的Windows版本（如Windows 7）。增强缓解体验工具包（EMET）可用于轻松为进程启用DEP和其他防护。您可以在此处阅读更多关于EMET的信息： http://support.microsoft.com/kb/2458544

对于ISV

DEP和ASLR等防护在整个Windows生态系统中的有效性 heavily contingent on ISV采用。鼓励有兴趣在其产品中启用DEP、ASLR和其他防护的ISV参考以下指南： http://msdn.microsoft.com/en-us/library/bb430720.aspx

Matt Miller, MSEC Security Science

参考文献

[1] Dino Dai Zovi. Practical Return-Oriented Programming. April, 2010.
[2] Dionysus Blazakis. Interpreter Exploitation: Pointer Inference and JIT Spraying. February, 2010.
[3] Hovav Shacham. Return-Oriented Programming: Exploits Without Code Injection. August, 2008.
[4] Peter Vreugdenhil. Pwn2Own 2010 Windows 7 Internet Explorer 8 Exploit. March, 2010.
[5] Hovav Shacham et al. On the Effectiveness of Address-Space Randomization. 2004.
[6] Alexander Sotirov and Mark Dowd. Bypassing Browser Memory Protections. August, 2008.

发布内容"按原样"提供，无任何保证，也不授予任何权利。