安全漏洞是如何造成的：缓冲区溢出

查看整个缓冲区溢出过程。在这段视频中，我们将shellcode添加到了缓冲区内，而后通过执行以棋牌室返回地址。我们的shellcode运行了Windows计算器程序。

为了利用这种溢出手段而非单纯向内存栈中写入大量“A”以破坏一切内容，攻击者需要在缓冲区中添加shellcode：这是一小段可执行代码，其能够执行攻击者所选定的一系列操作。在此之后，返回地址会被缓冲区所引用的地址所覆盖，进而在从某函数调用返回后将处理器定向至shellcode执行位置。

为了实际这一目标，攻击者可以选择多种技术手段。代码片段可以将包含有null字符的shellcode转换为具备同等作用的形式以避免出现问题。它们甚至能够处理更为严格的限制，例如一条已被篡改的函数可能只接收能够通过标准键盘进行输入的结果。

内存栈本身的地址中通常也包含有null字节，这同样会引发问题：这意味着返回地址无法直接被设定为栈缓冲区的地址。一般来讲这倒不是什么大问题，毕竟那些可用于填写缓冲区的函数(当然，也会造成潜在的溢出隐患)会自行写入一个null字节。但在某些情况下，它们则可被用于将null字节添加到正确的位置当中，从而篡改内存栈中的返回地址。

即使无法进行返回地址篡改，这种状况也可被攻击者们用于重新定向。程序及其全部相关库的存在意味着，内存当中可以驻留可执行代码。大部分此类可执行代码都能够拥有属于自己的“安全”地址，也就是说其中不包含任何null字节。

攻击者们要做的就是找到一个包含一条指令的可用地址，例如x86架构中的call esp，其会将栈指针的值作为函数地址看待并加以执行——这显然非常适合用来承载shellcode。攻击者随后会利用callesp指令的地址来覆盖返回地址;如此一来，处理器会在该地址处进行一次额外的跳转，但最终仍会运行该shellcode。这项利用其它地址强行实现代码执行的方法被称为“trampolining”，也就是蹦床。

有时候我们很难利用缓冲区地址来覆盖返回地址。为了解决这个问题，我们可以利用目标程序(或者其对应库)中的特定可执行代码片段地址来覆盖返回地址。这部分代码片段能帮助我们对缓冲区位置进行转换。

之所以这种方式能够奏效，是因为正如前面提提到，程序及其配套库在每时运行时都会使用同样的内存地址——即使是多次启动甚至在不同设备之上都不会改变这一点。而非常有趣的是，用于提供“蹦床”的库本身并不需要执行call esp指令。该库只需要提供两个字节(在本次示例中为0xff与0xd4)并保证彼此相邻即可。它们可以作为其它指令中的组成部分甚至直接以数字形式存在;x86对于这类内容并不挑剔。另外，x86的指令长度可以相当之长(最高为15字节!)并指向任意地址。如果处理器从中间部分读取某条指令——例如在一条长度为4字节的指令中从第二个字节开始读取——那么最终的执行结果可能会完全不同、但却仍然切实生效。考虑到这一点，攻击者确实可以很轻松地找到可资利用的“蹦床”。

不过有时候，攻击活动无法直接将返回地址篡改为所需位置。不过由于内存布局总是非常相似，不同设备或者不同运行进程之间的设定几乎完全相同。举例来说，某个可利用的缓冲区的具体位置可能会出现变化，而存在差异的几个字节则取决于系统名称或者IP地址。另外，软件的小型更新可能也会让内存地址出现稍许变动。为了解决这一问题，攻击者只需要找到返回地址的大概正确位置即可，而不必保证其完全符合实际情况。

面对这类状况，攻击者的处理办法也很简单，这就是使用所谓“NOP sled”技术。相较于直接向缓冲区内写入shellcode，攻击者可以在真正的shellcode之前编写数量庞大的多条“NOP”指令(所谓NOP也就是’no-op‘，是指那些不会真正执行的指令)，有时候可以多达数百条。要运行该shellcode，攻击者只需要将返回地址设定在这些NOP指令当中的某个位置即可。只要该地址被包含在NOP当中，处理器就会快速将其略过并直接执行真正的shellcode。

你的错、他的错——都是C的错

导致上述攻击得以实现的核心bug——具体来讲，就是向缓冲区内写入超出其容纳能力的内容——听起来可以很轻松地加以避免。将这些问题完全归咎于C编程语言及其各类兼容性分支方案——例如C++以及Objective-C——或许有些夸张，但也不能说毫无道理。C语言本身已经相当陈旧，但却应用广泛且作为我们操作系统以及各类软件的基础性元素存在。正是由于C语言的流行，才让这些本来可以轻松避免的bug长期生效并影响到无数开发者与用户。

作为C语言自身阻碍安全开发实践的一项实例，我们在这里要着重谈谈gets()。作为一项函数，gets()会获取一条参数——也就是一个缓冲区——并从标准输入内容中(通常意味着’键盘输入内容‘)读取一行数据，而后将其添加到缓冲区当中。细心的朋友可能已经注意到，gets()当中并不会对将被添加至缓冲区内的参数长度作出限制，而且作为C语言设计中的一种有趣现象，我们没办法利用gets()了解缓冲区的实际大小。这是因为gets()并不会对输入内容的大小作出任何要求：它只负责从标准输入内容中读取数据——直到电脑前的操作者按下回车——而后尝试将全部内容添加到缓冲区内，即使操作者写入的内容远远超出了缓冲区容纳能力，gets()也完全不予理会。

很明显，这项函数属于彻头彻尾的安全隐患。由于我们无法制约通过键盘输入的文本内容总量，因此也就不可能避免由gets()引发的缓冲区溢出结果。C语言标准的制定者们确实意识到了这个问题，并在1999年的再版C语言规范中对gets()加以弃用，最终在2011年的更新中将其完全移除。但它的存在——以及不时出现的实际使用——证明了C语言确实给用户们挖了一个非常危险的潜在陷阱。

而作为诞生于1988年的世界首个可通过互联网传输的自我复制恶意软件，莫里斯蠕虫利用的恰恰是这项函数。BSD 4.3 fingerd程序会通过端口79对网络连接进行监听，也就是我们常说的finger端口。事实上，finger也是一个非常古老的Unix程序，其作为网络协议存在并负责识别是谁登录到了远程系统当中。它的使用方式分为两种;其一是远程系统可以利用它来查询当前已经登录的每位用户，其二则是用于查询特定用户名并告知我们与该用户相关的部分信息。

每当有连接出现在finger的后台进程当中，它都会利用gets()从网络中读取数据并将其添加到内存栈中一个512字节的缓冲区内。在通常操作中，fingerd会随后生成finger程序，并在可能的情况下向其传递相关用户名。该finger程序才是真正负责监听用户接入或者提供与特定用户相关信息的主体，而fingerd本身仅仅负责监听网络并在需要时启动finger。

鉴于惟一的“真实”参数基本只会是用户名，因此512字节的缓冲区设定已经不算小了。应该没人会设定一个长达512位的用户名——不过系统本身并不会对此作出强制要求，因为在这里负责内容获取工作的正是臭名昭著的gets()函数。当我们通过网络发出超过512字节的用户名时，fingerd就会乖乖地造成缓冲区溢出状况。而这也正是Robert Morris的具体作法：他向fingerd发送了537字节的数据内容(其中包含537个字节外中一个换行符，这直接导致gets()停止读取输入数据)，顺利实现缓冲区溢出并覆盖了返回地址。在此之后，返回地址被轻松设置为内存栈中的缓冲区地址。

莫里斯蠕虫的可执行负载非常简单。它会发起400条NOP指令，从而让内存栈布局出现轻微的变化，而后再接上一小段代码片段。这些代码会生成一条shell，即/bin/sh。这是攻击负载当中很常见的选择;fingerd程序会以root权限运行，因此在遭到攻击并被迫运行shell时，该shell也将拥有root权限。另外，fingerd会被引导至网络当中，这意味着其接收的“键盘输入内容”可以实际来源于网络传输，并将输出结果通过网络发送出去。这两大特性都明显昭示其为shell所利用的潜在可能性，也就是说这一root shell现在已经能够为攻击者所远程操控。

尽管想要绕开gets()并不困难——事实上即使是在莫里斯蠕虫刚刚诞生的时候，就出现了能够彻底禁用gets()的fingerd修复版本——但C语言的其它一些组成部分仍然难以被忽略，甚至几乎不可能被彻底修复。C语言对于文本字符的处理方式就是一种常见的问题根源。正如之前所提到，C语言在处理字符串时会在读取至null字节后中止。在C语言中，一条字符串就是一段字符序列，其末尾以null字节作为字符串中止标记。C语言当中有一系列函数负责操作这些字符串。其中最典型的例子要数strcpy()——负责从来源处将一条字符串复制至目标位置——以及strcat()——负责从来源处将一条字符串添加至目标位置——这对奇葩了。这两项函数都没有对指向目标缓冲区的参数作出长度限制，因此添加之后会不会造成缓冲区溢出根本就不在这二者的考量范围之内。

即使C语言的字符串处理函数能够对指向缓冲区的参数长度作出限制，同样的错误及溢出状况仍然得不到彻底解决。C语言分别为strcat()与strcpy()提供一对姐妹函数，分别名为strncat()与strncpy()。名称当中额外的n代表的正是其所获取参数的长度。但正如很多资深C语言程序员们所知，这个n并不是将要写入的缓冲区的具体大小;相反，它其实是来源处将要进行复制的字符数量。如果来源提供的数据量超出了对应字符限制(因为达到了null字节的位置)，那么strncpy()与strncat()将会通过向目标位置复制更多null字节的方式来补足差额。换句话来说，这些函数仍然完全不关心目标缓冲区的实际大小。

与gets()不同，我们其实有能力以安全方式使用以上函数，只不过有点困难罢了。C++与Objective-C都针对C语言的函数库提供更理想的替代方案，这使得我们能够更轻松且更安全地实现字符串操作——不过由于向下兼容的考量，某些C语言中的陈旧特性仍然被继承了下来。

除此之外，二者还包含了C语言的一大根本性缺陷：缓冲区自身并不了解自己的确切大小，而且C语言也根本不会验证缓冲区之上所执行的读取与写入操作——这就使得缓冲区溢出成为了可能。正是同样的机制导致OpenSSL当中曝出了Hearbleed漏洞，但值得强调的是，它并不算是溢出、而属于读取越界。OpenSSL当中的C代码会尝试读取超出缓冲区容纳能力的内容，并最终导致敏感信息泄露至外部环境。#p#

修复此类漏洞

无需赘言，随着人类智慧的进一步发展，我们如今已经拥有了更多更出色的语言选项——它们会对指向缓冲区的读取与写入操作进行验证，这就彻底阻断了溢出问题的发生。由Mozilla打造的Rust等编译语言、安全运行时环境的杰出代表Java以及.NET，外加Python、JavaScript、Lua以及Perl等虚拟化脚本语言都彻底解决了缓冲区溢出的问题(当然，.NET仍然允许开发人员直接关闭所有保障措施，在这种选项设置之下缓冲区溢出会再度成为可能)。

缓冲区溢出目前仍然作为安全领域的一大关注重点存在，同时也是C语言持久生命力的有效证明。任何存在这一问题的遗留代码都有可能引发重大的安全事故。但目前世界上仍在运行的C代码依旧数不胜数，其中包括众多主流操作系统的内核以及OpenSSL等高人气代码库。即使开发人员倾向于使用C#这样安全性更出色的语言，他们也仍然需要使用大量由C语言编写而成的第三方库。

性能水平则是C语言继续被广泛使用的另一大理由，虽然关于这方面的具体判断方式仍然比较模糊。确实，经过编译的C与C++代码能够带来更理想的执行速度表现，而且在某些情况下起到了无可替代的重要作用。然而目前大多数用户所使用的处理器在绝大部分情况下都处于资源闲置的状态;如果我们能够牺牲百分之十的总体性能来让自己的浏览器获得更为坚实的安全保障，包括缓冲区溢出以及其它众多潜在安全隐患，那么相信大家绝对会选择这种方式。只要有厂商愿意开发出这样值得依赖的浏览器，我们就能够根据自己的实际需要作出权衡。

尽管如此，C语言和它的整个大家族却仍然广泛存在——当然也包括由其带来的缓冲区溢出风险。

目前已经有不少相关举措努力阻止溢出错误影响到开发人员以及使用者。在开发过程中，我们可以选择多种工具对源代码进行分析，并通过程序运行来检测其中是否存在危险结构或者溢出错误，这就避免了此类bug被实际添加到软件成品当中。AddressSantizer等新型工具以及Valgrind等传统方案都可以实现上述功能。

然而，这些工具需要开发人员的积极采用方能奏效，否则就是一堆毫无意义的0和1——也就是说仍有相当多的程序并没有将其纳入开发流程。另有一些系统层面的保护手段，能够在缓冲区溢出问题真正发生之后尽可能保证其它软件免受其侵害。在这方面，操作系统以及编译器开发者们已经采取了一系列方案，旨在提高攻击者使用这些溢出漏洞的难度。

某些系统的存在目的正是让一部分特定攻击活动变得更难实现。当前的多套Linux系统补丁就能够确保系统库全部被加载在底端内存地址处，从而保证其地址中至少包含一个null字节。在这种情况下，攻击者将很难利用C字符串处理方式在缓冲区溢出攻击中使用这些地址。

其它防御机制也更为普遍。目前很多编译器都拥有某种类型的内存栈保护机制，其会将一个名为“canary”(意为金丝雀)的运行时检测值写入到返回地址存储位置附近的内存栈末尾。在每项函数执行结束之前，系统都会检查该值以确定返回指令是否遭到了修改。如果该canary值发生了变化(因为其在缓冲区溢出中被覆盖)，那么该程序将立即崩溃而非继续执行。

而最重要的单项保护手段之一正是名为W^X(意为’单纯写入或执行‘)、DEP(意为’数据执行保护‘)、NX(意为‘不执行’)、XD(意为‘执行禁用’)、EVP(意为‘增强病毒保护’，AMD公司往往比较喜欢使用这一术语)、XN(即‘从不执行’)等一系列措施。它们所采取的概念非常简单。这些系统会尽可能让内存拥有可写入能力(适用于缓冲区)或者可执行能力(适用于库及程序代码)，但不会使其二者兼备。因此，即使攻击者能够使缓冲区出现溢出并控制其中的返回地址，处理器最终仍然会拒绝执行对应的shellcode。

无论具体使用什么样的名称，这都是一项重要的技术，这主要是因为其能够在无需额外成本的前提下起效——这类方案使用的是处理器自身内置的、作为虚拟内存硬件支持而存在的保护机制。

正如之前所提到，在虚拟内存当中每个进程都拥有属于自己的内存地址。操作系统与处理器会共同保持一套映射机制，从而令虚拟地址指向其它位置;有时候一个虚拟地址可能会对应一个物理内存地址，但有时候其会对应磁盘上某个文件的一部分，有时候甚至会因为尚未分配而不对应任何对象。这是映射机制是高度细化的，通常以4096字节为一个区块——也就是我们所说的page单位。

用于存储这一映射的数据结构不仅包含有每个page的位置(物理内存、磁盘以及无位置)，同时(通常)也包含有另外三个用定义page保护的字位：即该page是否可以读取、其是否可以写入以及其是否可以执行。在这样的保护之下，进程对应的内存区域能够被标记为可读取、可写入但不可执行。相反，程序的可执行代码片段以及库则会被标记为可读取、可执行但不可写入。

NX的一大出色之处在于，操作系统通过更新获得对应的支持能力之后，它就能够以追溯方式应用于现有程序。某些程序偶尔也会在运行中遇到问题。Java以及.NET当中所使用的即时编译器就会在运行时环境下在内存中生成可执行代码，这些代码则要求内存同时具备可写入性与可执行性(不过严格来讲，这些代码一般不会同时要求这两种能力)。在NX出现之前，内存始终同时具备可读取性与可执行性，因此这些即时编译器完全无需针对其可读取/可写入缓冲区作出任何调整。但在NX出现之后，即时编译器必须要确保将内存保护机制从读取-写入变更为读取-执行。

市场对于NX这类安全方案的需求非常明确，特别是对于微软阵营来说。早在2000年初，两大蠕虫的相继出现就证明了微软公司的系统代码当中存在着一些严重的安全问题：Code Red于2001年7月感染了35万9千套运行有微软IIS Web Server的Windows 2000系统，而随后的SQL Slammer则于2003年1月侵入了超过7万5千套运行有微软SQL Server数据库的系统。这些都让软件巨头陷入严重的被动局面当中。

这两种蠕虫利用的都是内存栈中的缓冲区溢出漏洞，而且令人吃惊的是虽然距离莫里斯蠕虫诞生已经分别过去了13年和15年，但它们的开发方式几乎完全相同。三者都将恶意负载添加到内存栈的缓冲区内，并通过覆盖返回地址的方式加以执行。(惟一的区别在于，这两位相对年轻的继任者使用了‘蹦床’技术。相较于当初直接将返回地址设置为内存栈地址的方式，这二者将返回地址设置成了一条能够传递至内存栈并执行的指令。)

当然，这些蠕虫方案在其它多个方面也算有所发展。Code Red的负载不仅能够实现自我复制，同时也会侵入网页并试图执行拒绝服务攻击。SQL Slammer则囊括了一切感染其它计算设备并在网络上进行传播的功能组件，同时将自身体积控制在数百字节水平——这意味着受感染的机器上不会留下明显的痕迹，而且重新启动之后这些痕迹就会彻底消失。这两种蠕虫也都开始以互联网作为着眼重点，这也使它们超越了老祖宗莫里斯蠕虫、成功感染了更多计算机设备。

不过问题的关键在于，这样一种能够被直接利用的缓冲区溢出漏洞已经算是古董级别的隐患了。正是由于两种蠕虫病毒的相继出现，才使人们对使用Windows接入互联网并作为服务器系统产生了质疑情绪。面对重重压力，微软公司表示将开始认真对待安全问题。Windows XP SP2就是第一款真正让安全意识融入其中的成品。它对软件进行了一系列调整，包括提供软件防火墙、调整IE以避免工具栏乃至插件的静默安装——当然，也实现了对NX的支持。

在硬件层面支持NX在2004年之后成为主流，当时英特尔公司刚刚推出了其奔腾4处理器。而操作系统对于NX的支持也在Windows XP SP2迈出第一步后成为了业界共识。Windows 8在这方面表现得更加果断，干脆不支持未配备NX硬件的陈旧处理器。#p#

后NX时代

随着NX支持能力的逐步普及，缓冲区溢出也在当下找到了新的实现途径——换言之，攻击者们发现了一系列能够有效绕开NX的技术手段。

其中最早的一种与前面提到的“蹦床”机制非常相似，它能够通过来自其它库或者可执行代码的指令绕开系统在内存栈缓冲区内对shellcode的控制。不同于以往寻找可执行代码片段来直接将shellcode传递至内存栈当中，攻击者们如今转而开始特色确实拥有实际作用的代码片段。

而其中最理想的选项也许要数Unix的system()函数了。这项函数会获取一个参数：一条字符串的地址代表着一条将被执行的命令行，从传统角度讲该参数会被传递至内存栈当中。攻击者可以创建一条命令行字符串，并将其添加至内存栈中以实现溢出效果，而且由于在传统角度上内存中所承载的内容不会发生位置变动，因此该字符串的地址将以已知形式存在、并作为内存栈中配合攻击活动的组成部分。在这种情况下，被覆盖的返回地址不会再被设置为缓冲区地址，而是被设置为system()函数的地址。当造成缓冲区溢出的函数执行完成后，它不会返回至调用函数处，而是运行system()以执行攻击者选定的命令。

这就巧妙地绕过了NX的保护。作为系统库的组成部分，system()函数始终处于执行状态。这种漏洞利用方式并不需要在内存栈中执行代码，而只需要从内存栈中读取已有命令行。这项技术被称为“return-to-libc”(即回库)，最初是由俄罗斯计算机安全专家Solar Designer于1997年发明的。(libc也就是Unix库的名称，其负责实现多种关键性函数，包括system()。Unix库通常会被载入到每个单独的Unix进程当中，而这也使其成为攻击活动的首选目标。)

虽然确切有效，但这项技术在某种程度上亦可以被扼制。一般来讲，函数并不会从内存线中获取自己的参数，而倾向于将其传递到寄存器当中。在命令行字符串中传递参数以实现执行虽然想法不错，但却往往会因为其中出现的恼人null字节而导致运转停止。另外，这会让多个函数同时调用变得非常困难。虽然并非无法解决——同时提供多个返回地址而非一个——但我们将完全无法变更参数顺序、使用返回值或者实现其它操作。

相较于利用shellcode填写缓冲区，我们现在选择利用返回地址与数据序列进行填充。这些返回地址会在目标程序及其库之内传递对现有可执行代码片段的控制权。每个代码片段都会执行一项操作而后返回，将控制权传递给下一个返回地址。

在过去几年当中，return-to-libc技术被广泛用于突破现有安全保护措施。2001年末，安全业界就曾记录下多种通过扩展return-to-libc执行多函数调用的方法，并提供了解决null字节问题的办法。这些技术并未受到严格限制，因此2007年由此衍生出的另一种复杂度更高的攻击手段开始出现——这种消除了大部分上述限制的方案正是ROP，即“返回导向编程”技术。

其基本设计思路与“回库”以及“蹦床”差不多，但却从普适性方面更进了一步。“蹦床”是利用单一代码片段将可执行shellcode添加到缓冲区当中，而ROP则是利用大量被称为“gadget”的代码片段。每个gadget都遵循一种特定模式：它会执行某些操作(包括向寄存器中添加一个值、向内存中写入或者添加两个寄存器等等)，而后加上一条返回指令。x86的固有特性让“蹦床”的设计思路在这边再度起效;进程当中所加载的系统库中包含着成百上千个能够被解释为“执行一项操作，而后返回”的序列，因此它们也成为了实现ROP攻击的潜在基础。

这些gadget彼此之间通过一条长返回地址序列(也可以是其它任何有用或者必需的数据)被串连在一起，并作为缓冲区溢出的组成部分被写入至内存栈当中。返回指令则很少甚至完全无需借助处理器中的calling函数——而是单纯利用returning函数——在gadget之间跳转。值得注意的是，人们发现可资利用的gadget的数量与种类如此之多(至少在x86平台上是如此)，攻击者几乎能够利用它们实现任何目标。这一奇特的x86子集在特定使用方式之下往往会呈现出完备的图灵特性(虽然其具体功能范围取决于特定程序所加载的库类型，并以此决定哪些gadget能够切实起效)。

正如“回库”技术一样，所有可执行代码实际上都来源于系统库，因此NX保护也就无处发力了。这套方案的出色灵活性意味着，攻击者能够甚至能够实现原本依靠“回库”技术所难于完成的任务，包括调用从寄存器内获取参数的函数或者将来自某一函数的返回值作为另一函数的参数等等。

ROP负载可谓变化多端。有时候它们只以简单的“创建一个shell“形式的代码出现，但大多数情况下攻击者都会利用ROP来调用某项系统函数，从而变更某一内存page的NX状态、将其由可写入转变为可执行。通过这种方式，攻击者将能够利用便捷的非ROP负载在执行过程中实现ROP。

随机性提升

NX的这一弱点早已为安全专家们所了解，而这同时也成为最大的薄弱环节在各类攻击活动中反复出现：攻击者们在动手之前就已经掌握了内存栈与系统库的确切内存地址。正因为各类攻击活动皆以此类知识作为基础，因此解决安全隐患的最佳途径就是使这些知识失去效用。有鉴于此，地址空间布局随机化(简称ASLO)技术应运而生：它会对内存栈的位置、内存内库以及可执行代码的位置进行随机化处理。一般来讲，这些位置在程序每次运行时、系统启动时或者二者同时发生时都会出现变化。

这极大地增加了攻击活动的实施难度，因为几乎在一夜之间，攻击者根本不知道哪些ROP指令片段会驻留在内存当中、甚至弄不清楚要实现溢出的缓冲区到底在哪里。

ASLR在多个方面与NX携手合作，因为它主要负责封杀“回库”以及“返回导向编程”这两大NX未能堵住的缺口。然而遗憾的是，它的介入深度有些过度。除了即时编译器以及少数其它非常用程序之外，NX几乎能够被成功添加到任何现有软件当中。但ASLR在这方面则问题多多，程序及库需要确保自身的正常运行不会受到内存地址随机变化的影响。

举例来说，在Windows当中，DLL就基本不会受到内存地址随机化的影响。DLL在Windows系统上始终支持利用不同内存地址加载数据，但EXE文件就没这么幸运了。在ASLR出现之前，EXE文件会始终以0x0040000作为起始加载位置，并安全地以此为运行前提。但ASLR出现之后，情况就完全不同了。为了确保不出现差错，Windows在默认条件下要求EXE可执行文件对ASLR提供支持，并提供启用选项。不过出于安全的考虑，即使对应程序并未明确表达支持能力，Windows仍然默认在所有可执行程序及库中启用该选项。而且在大多数情况下，结果还是令人满意的。

比较糟心的情况出现在x86 Linux系统当中。在使用ASLR的情况下，Linux平台的性能损失可能高达26%。除此之外，这套方案明确要求可执行程序与库以ASLR支持模式进行编译。这意味着管理员根本无法像在Windows环境中那样对ASLR进行授权。(x64也没能彻底解决Linux的性能损失问题，不过损失程度得到了显著降低。)

在ASLR启用之后，它能够为系统提供良好的缓冲区溢出状况保护。不过ASLR本身还远远称不上完美——举例来说，其能够提供的随机水平就比较有限，而且这种情况在32位系统中表现得尤为严重。尽管内存空间所能提供的地址数量高达40亿个，但并不是所有地址都能够被用于加载库或者旋转内存栈。

相反，其分配方式会受到各种约束，而且其中一部分还属于泛用性目标。总体而言，操作系统倾向于将各个库以相邻方式进行加载，以保证各个进程的地址空间首尾相连，这样就能尽可能多地为应用程序运行提供充裕的内存容量。大家当然也不希望让一个库以256 MB为单位遍布在整个内存空间当中——256 MB是我们能够作为整体进行分配的最大内存单位，这种作法会限制应用程序处理大型数据库集的能力。

可执行文件和库通常在启动后必须进行加载，且至少被包含在一个page当中。通常来讲，这意味着它们必须以4096整数倍的形式进行加载。平台也可以对内存栈采用类似的协议;举例来说，Linux会以16字节的整数倍形式启动内存栈。迫于内存的压力，系统有时候需要对随机性进行进一步削减，从而保证一切能够顺利运行。

这种变化看起来影响不大，但却意味着攻击者有时候可以猜测到某个地址的可能位置，而且有相当高的机率猜测成功。即使猜对的可能性非常低——例如二百五十六分之一——在某种情况下攻击者依然足以利用其实施恶意活动。当攻击某台会自动重启崩溃进程的Web服务器时，256次攻击中有255次出现崩溃完全不是什么大问题。只需要经过简单重启，攻击者就能再次尝试下一个内存地址。

不过在64位系统当中，由于地址空间变得更加庞大，单纯的猜测就不足以解决问题了。攻击者面对的很可能是上百万个——甚至数十亿个——潜在内存地址，机率如此之低也就不值得我们为之忧心了。

另外，对于攻击者来说，猜测与崩溃这段手段不适用于浏览器之类的场景;没有哪个用户会连续对浏览器进行256次重启来“帮助”攻击者完成试探。也就是说，在这种情况下NX与ASLR的联手协作将让攻击者们变得无机可乘。

但如果有其它帮助手段存在，情况就不一样了。在浏览器当中的一种常见实现途径在于利用JavaScript或者Flash——二者都包含着有能力生成可执行代码的即时编译器——向内存中塞进大量经过精心构建的可执行代码。由此生成的大型NOP sled也就是我们目前经常提到的“heap spraying”(也就是堆喷射)技术。另一种实现方式则是找出某个有可能泄露库或者栈内存地址的次级漏洞，从而帮助攻击者获得构建自定义ROP返回地址组所必需的相关信息。

第三种方法在浏览器当中比较常见：利用那些不支持ASLR的代码库。举例来说，Adobe PDF插件或者微软Office浏览器插件的某些早期版本就不支持ASLR，而且Windows在默认情况下不会强制在非ASLR代码中启用该功能。如果攻击者能够强制载入这类库(举例来说，通过在隐藏的浏览器帧中加载某个PDF文件)，那么他们就能够直接绕过ASLR，即利用这些非ASLR库容纳自己的ROP负载。

一场永远休止的战争

攻击技术与保护技术之争就像是猫与老鼠的竞逐。像ASLR以及NX这样强大的保护系统能够提高安全漏洞的利用门槛，从而在一定时期内彻底阻止缓冲区溢出这类简单漏洞的肆虐。然而聪明的攻击者们仍然能够找到其它安全缺陷，并将它们组合起来以继续发动攻势。

这场军备竞赛仍在不断升级。微软公司的EMET(即‘增强缓解体验工具包’)当中包含一系列半实验性保护方案，旨在检测“堆喷射”乃至其它任何以ROP为基础尝试利用特定高危函数的行为。不过在这场永无休止的数字化对抗中，这些安全技术同样在持续遭到淘汰。这并不是说它们没有作用——各类新型保护技术的出现确实提高了漏洞利用的难度与成本——但大家必须正视一个现实，即警惕之心须长久保持。

英文：How security flaws work: The buffer overflow