Carnegie Mellon大学CERT协调中心（CERT / CC）的安全分析师Will Dormann本月早些时候在推特称Win10执行被称为全系统强制ASLR的安全功能“本质上是毫无价值的”时引发了一场大规模的混乱。

他用CERT的忠告跟随了这个推特，这反过来又引起了科技媒体的一阵骚动，以ZDNet自己的故事为代表：关键的Win10防御“毫无价值”，而bug的历史可以追溯到Windows 8。

这个标题有两个问题。

首先，这个功能并不是“Win10的关键防御”。全系统强制ASLR是一个深奥的选择，主要适用于边缘情况，必须手动配置。

其次，微软认为Dormann抱怨的行为不是一个错误。微软公司的Matt Miller在微软响应安全中心的一篇博客文章中写道：“CERT / CC所观察到的强制性ASLR行为是通过设计来实现的......”

简而言之，ASLR按预期工作，CERT / CC描述的配置问题仅影响EXE尚未选择加入ASLR的应用程序。配置问题不是一个漏洞，不会造成额外的风险，并且不会削弱应用程序现有的安全状态。

CERT / CC确实发现了Windows Defender Exploit Guard（WDEG）的配置界面问题，该问题目前阻止了系统范围的自下而上的随机化。 WDEG团队正在积极研究这个问题，并将相应地解决这个问题。

最初报道这个故事的新闻报道大部分都把它当作一个经典的他所说的他们所说的故事。这一点很复杂，因为这个特性与配置一样难以解释。我们来分解一下。

地址空间布局随机化（ASLR）是每个现代操作系统的基本安全特性。十多年前，随着Windows Vista的发布，ASLR支持被添加到了Windows中。

正如名字所解释的，ASLR的要点是随机化可执行代码（包括DLL）使用的内存地址，以便发现内存漏洞（如缓冲区溢出）的攻击者不能轻易利用它。

（有关ASLR如何与另一个称为数据执行保护（DEP）的安全功能结合使用的详细技术说明，请参阅此StackExchange主题：“ASLR和DEP如何工作？”对于Microsoft在Windows 8中实现ASLR的说明稍后请参阅“软件防御：减轻常见的开发技术”。）

自2010年以来，Windows程序开发人员通过在编译程序时设置/ DYNAMICBASE标志，可以选择加入ASLR。如果您运行的是过去六七年内更新的任何Windows程序，它几乎肯定会在本地支持ASLR。

在windows10中，ASLR在选择的程序上运行良好，其中包括Office 2013和Office 2016，Adobe Creative Cloud套件中的每个程序，Chrome和Firefox等现代浏览器，Windows本身附带的每个可执行文件，以及每个分发的程序通过Windows应用商店。

（要确认为您的PC上运行的进程启用了ASLR，请下载并运行Microsoft Sysinternals实用程序Process Explorer并添加ASLR列。）

对于那些每天Windows用户所做的绝大多数的程序，ASLR不会被破坏，越野车或毫无价值。它的工作原理与之前一样，阻止了之前会变成零日攻击的攻击类型。

那么，问题在哪里？

ASLR在Win10（以及之前的Windows版本，就此而言）的问题出现在运行旧版程序时尚未使用选择ASLR的标志进行编译。出于兼容性原因，Windows不会随机化这些程序的地址。因为它们位于内存中的可预测地址，所以它们更容易受到基于内存的攻击。

在Windows 7和Windows 8.x中，可以使用名为增强型缓解体验工具包（Enhanced Mitigation Experience Toolkit，EMET）的工具来强制随机化其中一个较旧，不安全的程序。 （我在2011年写了关于EMET的文章，称它为“每个Windows用户应该知道的一个安全工具”。）

从刚刚发布的Win10版本1709开始，Microsoft已经不赞成使用EMET，并已将其漏洞利用缓解功能构建到操作系统中。要获得称为Windows Defender Exploit Guard（WDEG）的此功能，请打开Windows Defender安全中心，单击应用程序和浏览器控制，然后单击利用防护设置。

如该屏幕所示，您可以更改系统范围内的WDEG设置或基于每个程序。

如果选择每个程序选项，则必须确定特定的程序，然后按照此处所示调整设置。

对于我的测试，我使用了一个在2008年最后更新的Windows实用程序，之后将ASLR的支持添加到Microsoft的开发工具中。该实用程序仍然在Win10上工作（我已经模糊了程序的名称，这与此处的讨论无关）。

打开强制ASLR这个程序的选项将其基地址重定位到内存中，但该位置仍然是可预测的，因此容易受到与内存相关的攻击。

该屏幕上的第二个选项，即自下而上的ASLR，是将程序的地址重定位到内存中真正的随机位置，并防止可能的攻击。不幸的是，在这种情况下，它也阻止程序运行。

当您使用WDEG系统设置强制所有程序与ASLR一起运行时，出现CERT / CC标识的配置问题。从前面提到的微软博客文章：

只有当进程EXE选择进入ASLR时，自底向上随机化才被默认启用。这是出于兼容性原因，因为EXE没有选择加入ASLR（通过/ DYNAMICBASE）的应用程序不一定期望他们的地址空间布局从一个执行改变到下一个。

可以通过在Win10版本1709中修改注册表来覆盖该行为，但是最好的选择是在每个程序的基础上启用此行为。正如微软所言：

CERT / CC提出的一个值得注意的观点是，在Windows 7上通过EMET实现系统范围的强制ASLR并不表现出上述行为。相反，EXE没有选择加入自下而上的ASLR的流程仍被观察到是随机的。原因是Windows 7上的EMET使用不同的设置来强制ASLR，而不是现在在Windows 8和更高版本上使用的设置。

EMET在Windows 7上使用的设置不推荐使用，并且由于与应用程序兼容性风险相关而被默认隐藏。 EMET用户必须通过导航到EMET的高级选项公开此设置，如此处所述。

对于大多数人来说，这种行为是不成问题的。没有被编写来支持ASLR的较旧的程序比起支持该安全功能的较新程序本质上不太安全。如果您必须运行一个可能成为攻击目标的较旧程序，则可以为该程序启用ASLR和自下而上的随机化，并希望其运行。