黑客利用信息规避ASLR与DEP保护机制

　　今日，有越来越多的漏洞攻击都是利用“返回指标程序设计” (Return Oriented-Programming，简称 ROP) 技巧来躲避新版 Windows 的数据执行保护 (DEP) 机制。ROP 技巧要能成功，黑客必须事先知道某个模组在记忆体内的基底位址。然而，Windows 有另一项称为“地址空间配置随机化”(Address Space Layout Randomization，简称 ASLR) 的安全机制可让黑客很难事先预测目标位址，因为这项机制会随机安排主要数据区域的位址。

　　但是，有几种方法可以避开 ASLR。例如，我们就见过一种利用即时 (just-in-time，简称 JIT) 载入的攻击技巧，利用 Adobe Flash Player 的 JIT 组译器将大量的程序代码载入系统记忆体内。另外，我们也看过一些没有启用 ASLR 机制的 DLL (例如 Java 或 .NET 相关 DLL)，专门锁定 Windows 7 当中的 Internet Explorer (IE) 8 漏洞。此外，信息外泄也能让黑客取得关于系统记忆体配置的信息，进而避开 ASLR 机制。现在，让我们来看看最近出现的一种概念验证 (POC) 攻击，此攻击同时运用了信息外泄与 ROP 技巧来躲避 DEP+ASLR 机制。

　　这项原创的 POC 攻击已经发表在 Exploit Database (漏动攻击数据库) 上，而且也用于攻击已知的 Windows 漏洞。这项漏洞在 2011 年 1 月份的 Patch Tuesday 中已修正 (详见 Microsoft 信息安全公告 MS11-002)。这项漏洞由 Peter Vreugdenhil 所发现，并已列入已知漏洞清单：CVE-2011-0027。当配合另一个“使用已释放位址”(use-after-free) 的漏动时，就能入侵一个使用 IE8 的已修补 Windows 7 系统，这项攻击让 Vreugdenhil 赢得 了”Pwn2Own 2010"大奖。

　　虽然 Vreugdenhil 的概念验证程序代码根本还算不上可靠的漏洞攻击，但其背后的概念仍旧值得探讨。

　　漏洞分析

　　让我们来看看这项漏洞本身。这是一个 Microsoft Data Access Components (数据库存取元件) 当中的记忆体溢出问题。此漏洞可透过一个恶意网站来发动攻击。最简单的攻击程序代码如下：

　　如果您在一个没有套用 MS11-002 修补程序的系统上使用 IE 来开启某个文件，您的系统将会当机。

　　该 .HTML 文件会存取一个所谓的 XML Data Island。实际上，这是一个数据库程序界面。其底层是一个 MSAdo 物件。只要透过一个 RecordSet 物件就能存取这些 XML 数据。RecordSet 物件当中有一个属性叫做 CacheSize，用来记录快取缓冲区大小，此快取缓冲区用来记录已存取数据列的编号。例如，如果程序代码先存取第八列、再存取第一列，这个快取就会记录着 8 这个列号。

　　变更 RecordSet 的 CacheSize 属性会造成一种该缓冲区重新配置，该快取新的记忆体缓冲区配置大小 (allocation size) 计算方式为：Allocation Size = (CacheSize * 4) + 4。这两个数字都是以 32 位元正整数储存。因此，如果 CacheSize 非常大，计算出来的结果将可能超过该变数能够表示的大小。因而造成真正配置的空间远小于所指定的空间。但是系统仍旧会已为自己配置了足够的记忆体来满足 CacheSize 所指定的大小。

　　为了看清楚一点，让我们在除错器当中看看上述程序代码。这道指令 localxmlid1.CacheSize = 0×40000358 改变了快取记忆体的配置大小。在除错器上，我们执行到这里：

　　esi=0×40000358 代表新的快取大小 (十进位等于 1,073,742,680)。该数值会储存在 CRecordSet 物件内部位址偏移 0x10C 的地方。然而，实际用来配置记忆体的程序代码在此：

　　其中，eax=0×40000358 代表新的 CacheSize，该数值要先乘以四，然后再加四，才是记忆体配置大小。最后的结果再传到实际配置记忆体的 MpHeapAlloc 函数。

　　让我们来算一下。(0×40000358*4) + 4 = 0x100000D64 (十进位等于 4,294,970,724)。这个数值已经超出一个 32 位元正整数所能表示的范围，因此，只有最后面的十六进位数字能够保留下来，也就是：0xD64 (十进位等于 3,428)，而这数值远小于所指定的大小。

　　让我们继续执行下去。系统所配置的记忆体缓冲区基底位址在：0x021112a8。记住，该缓冲区很小，只有： 0xD64 位元组 (十进位等于 3,428 位元组)。而每一次执行 for-do 回圈都会将一个 4 位元组的数据列编号写到该快取缓冲区当中。因此，很快就会造成该缓冲区溢出，如下所示。请注意看，溢出的记忆体缓冲区当中填满了连续的数据列编号：

　　利用漏洞来读取记忆体

　　只要黑客能直接读取关键的记忆体区块，他们就能找出目前系统记忆体的配置方式 (如：透过 VTables 或操作系统的数据结构)。而这正是 ASLR 希望预防的事。

　　大多数时候，远端的黑客都无法自由检视使用者系统记忆体的内容。不过，Vreugdenhil 利用了记忆体缓冲区溢出的漏洞来达成这项目的。虽然我们不想在这里讨论这项漏洞攻击的细节，但我们可以说明一下其背后的主要概念。

　　首先，先利用 JavaScript 程序代码来配置一个字串。接着，使用记忆体缓冲区溢出漏洞来覆写字串的结束字元 (两个零)。当黑客再度存取该字串时，系统就不会看到结束字元，因此会读超过原始字串以外的记忆体内容。这项技巧说明如下。

　　字串在记忆体中的储存方式如下：前四个位元组储存了字串的长度值 (以位元组为单位)，接下来是字串内容，最后是二位元组的结束字元。所以，如果我们用这段程序代码宣告了一个字串：“var s = ‘AA’”，那麽，字串在记忆体中看起来像这样：

　　其中的‘B’的部分是记忆体中的其他内容。正常情况下，存取这个字串时会得到“AA”的内容，但是，如果我们透过溢出技巧让数据列编号盖过这个字串的结束字元，记忆体看起来会像这样： 在这个范例中，数据列编号的第一个数字是 0×10120：

　　接着，黑客只要仔细查看原始字串之后的记忆体内容就能发现一些可以用来进一步攻击的信息。

　　@原文文章来源：TrendLabs 　 Malware Blog - by Trend Micro