安全编码实践二：NXCOMPAT选项和数据执行保护DEP

《程序员》3月文章

申明。文章仅代表个人观点，与所在公司无任何联系。

1. 概述

在安全编码实践一中我们谈到GS编译选项和缓存溢出。缓存溢出的直接后果就是可能导致恶意代码的远<wbr></wbr>程执行。GS选项存在自身的局限，例如，有若干方法可以绕过GS选项的保护。

在这篇文章里，我们会介绍另外一个非常重要的安全特性<wbr></wbr>：数据执行保护，即DEP-Data Execution Prevention，以及与之对应的NXCOMPAT选项。

在栈溢出程序例子中，我们看到，恶意代码是被存放在栈（stack）上的。类似的，如果是一个堆（heap）溢出的安全漏洞，恶意代码是被存放在堆上。无论堆还是栈<wbr></wbr>，都是数据页面。在数据页面上，通常情况下，是不应该执行代码的。

DEP，就是禁止应用程序和服务在非可执行的内存区（non-executable memory）上执行指令。

1. DEP和硬件支持

2.1软件DEP和硬件DEP

在探讨DEP的原理前，我们先区分两个容易引起混淆的概念：软件DEP（Software DEP）和硬件DEP（Hardware-enforced DEP）。

软件DEP，并不是真正意义上的DEP。简单的说，它的原理是检查异常处理是否安全（SEH-Safe Exception Handling）。它是完全通过软件支持的一种安全特性。在以后的安全编码实践中<wbr></wbr>我们会专门讨论SEH。

硬件DEP，则是需要CPU提供支持的，同软件DEP相比，硬件DEP提供的保护更为全面。以后我们提到的DEP，都是指硬件DEP。

2.2 NX位

在80x86体系结构中，操作系统的内存管理是通过页面（page）存储方式来实现的。虚拟内存空间的管理，如代码，数据堆栈<wbr></wbr>，都是通过页面方式来映射到真正的物理内存上。原理参见下图【1】。

图1：页面内存映射

在AMD64位CPU上，在页面表（page table）中的页面信息加了一个特殊的位，NX位（No eXecute）。

• 如果NX位为0，这个页面上可以执行指令。
• 如果NX位为1，这个页面上不允许执行指令。如果试图执行指令的话<wbr></wbr>，就会产生异常。

Intel在它的CPU上也提供了类似的支持，称为XD 位（ eXecute Disable），其原理和AMD的NX是完全一样的。

操作系统对DEP的支持，就是将系统或应用程序的数据页面，标注上NX位。这样，一旦由于堆栈缓存溢出的安全漏洞，导致恶意代码试图在数<wbr></wbr>据页面上运行，CPU就会产生异常，导致程序终止，而不是去执行恶意指令。

Windows对DEP的支持是从Windows XP SP2，和Windows Server 2003开始的。用户可以通过Control Panel à System àAdvanced àPerformance来查看系统的DEP设置。

图2：DEP设置

1. 使用NXCOMPAT选项

NXCOMPAT是一个链接（LINK）选项，从Visual Studio 2005起开始支持。在具体介绍NXCOMPAT选项前，我们先看下面一段代码：

// DEP.cpp: Demo of how DEP protects executing code from data page

//

#include "stdafx.h"

/* win32_exec - EXITFUNC=process CMD=calc.exe Size=164 Encoder=Pex http://metasploit.com */

unsigned char scode[] =

"\x2b\xc9\x83\xe9\xdd\xe8\xff<wbr></wbr>\xff\xff\xff\xc0\x5e\x81\x76<wbr></wbr>\x0e\xd2"

"\xbd\xf7\x35\x83\xee\xfc\xe2<wbr></wbr>\xf4\x2e\x55\xb3\x35\xd2\xbd<wbr></wbr>\x7c\x70"

"\xee\x36\x8b\x30\xaa\xbc\x18<wbr></wbr>\xbe\x9d\xa5\x7c\x6a\xf2\xbc<wbr></wbr>\x1c\x7c"

"\x59\x89\x7c\x34\x3c\x8c\x37<wbr></wbr>\xac\x7e\x39\x37\x41\xd5\x7c<wbr></wbr>\x3d\x38"

"\xd3\x7f\x1c\xc1\xe9\xe9\xd3<wbr></wbr>\x31\xa7\x58\x7c\x6a\xf6\xbc<wbr></wbr>\x1c\x53"

"\x59\xb1\xbc\xbe\x8d\xa1\xf6<wbr></wbr>\xde\x59\xa1\x7c\x34\x39\x34<wbr></wbr>\xab\x11"

"\xd6\x7e\xc6\xf5\xb6\x36\xb7<wbr></wbr>\x05\x57\x7d\x8f\x39\x59\xfd<wbr></wbr>\xfb\xbe"

"\xa2\xa1\x5a\xbe\xba\xb5\x1c<wbr></wbr>\x3c\x59\x3d\x47\x35\xd2\xbd<wbr></wbr>\x7c\x5d"

"\xee\xe2\xc6\xc3\xb2\xeb\x7e<wbr></wbr>\xcd\x51\x7d\x8c\x65\xba\xc3<wbr></wbr>\x2f\xd7"

"\xa1\xd5\x6f\xcb\x58\xb3\xa0<wbr></wbr>\xca\x35\xde\x96\x59\xb1\x93<wbr></wbr>\x92\x4d"

"\xb7\xbd\xf7\x35";

int _tmain(int argc, _TCHAR* argv[])

{

void (*pRunCalc)();

pRunCalc = (void (*) ()) (void *) scode;

pRunCalc();

return 0;

}

字符串sCode所包含的是一段shellcode，也就是一段汇编代码。这段shellcode的功能是运行calc.exe，即计算器程序。pRunCalc作为函数指针指向这段代码。整个程序的目的就是试图在数据页面上执<wbr></wbr>行代码。

在Visual Studio 2005环境，用Win32 Console Application类型，编译这个程序，生成DEP.exe。

在一台Windows Vista 32位OS，有DEP支持的 机器上，运行DEP.exe。sCode指向的shellcode被执行，弹出了计算器窗口。

为什么DEP没有起保护作用呢？这是因为出于应用程序兼容性的考虑，在Windows Vista 32位的缺省配置下，DEP只负责保护Windows的系统程序和服务，而不包括其它应用程序。

如果在连接选项上加上/NXCOMPAT，重新链接生成DEP.exe。执行DEP.exe则会出现

图3：DEP.exe异常中止

关闭这个对话框后，在任务条上会弹出如下提示：

图4：DEP触发提示

这就表明是由于DEP保护机制的触发，而导致DEP<wbr></wbr>.exe程序被终止。

如果用WinDBG调试的话，会发现，当DEP.exe试图运行s<wbr></wbr>hellcode的第一条指令的时候，出现了系统异常。

0:000:x86> g

(1764.b38): Access violation - code c0000005 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

*** WARNING: Unable to verify checksum for DEP.exe

DEP!scode:

00000000`00417000 2bc9 sub ecx,ecx

0:000:x86> db 00417000 << 00417000就是sCode的地址

00000000`00417000 2b c9 83 e9 dd e8 ff ff-ff ff c0 5e 81 76 0e d2 +..........^.v..

00000000`00417010 bd f7 35 83 ee fc e2 f4-2e 55 b3 35 d2 bd 7c 70 ..5......U.5..|p

00000000`00417020 ee 36 8b 30 aa bc 18 be-9d a5 7c 6a f2 bc 1c 7c .6.0......|j...|

00000000`00417030 59 89 7c 34 3c 8c 37 ac-7e 39 37 41 d5 7c 3d 38 Y.|4<.7.~97A.|=8

00000000`00417040 d3 7f 1c c1 e9 e9 d3 31-a7 58 7c 6a f6 bc 1c 53 .......1.X|j...S

00000000`00417050 59 b1 bc be 8d a1 f6 de-59 a1 7c 34 39 34 ab 11 Y.......Y.|494..

00000000`00417060 d6 7e c6 f5 b6 36 b7 05-57 7d 8f 39 59 fd fb be .~...6..W}.9Y...

00000000`00417070 a2 a1 5a be ba b5 1c 3c-59 3d 47 35 d2 bd 7c 5d ..Z....<Y=G5..|]

我们看出，一旦使用的/NXCOMPAT选项，生成的程序在运行时候就会受到DEP机制的保护。

1. NXCOMPAT选项的内部实现

NXCOMPAT的实现，是通过在Windows PE文件头信息（PE Header）中设置IMAGE_DLLCHARACTERISTICS_NX<wbr></wbr>_COMPAT这个标志位。参见MSDN具体的定义信息如下【2】

typedef struct _IMAGE_OPTIONAL_HEADER {

WORD Magic;

BYTE MajorLinkerVersion;

BYTE MinorLinkerVersion;

… …

WORD DllCharacteristics;

… …

} IMAGE_OPTIONAL_HEADER,

*PIMAGE_OPTIONAL_HEADER;

DllCharacteristics

The DLL characteristics of the image. The following values are defined.

IMAGE_DLLCHARACTERISTICS_NX<wbr></wbr>_COMPAT

0x0100 The image is compatible with data execution prevention (DEP).

当IMAGE_DLLCHARACTERISTICS_NX<wbr></wbr>_COMPAT被设置时，就意味该程序选择在存在DEP支持的情况下，被DEP机制保护。

1. NXCOMPAT选项的局限

首先，并不是所有的CPU都提供了硬件DEP的支持。

其次，NXCOMPAT选项，或者是IMAGE_DLLCHARACTERISTICS_NX<wbr></wbr>_COMPAT的设置，只对Windows Vista系统有效。在以前的系统上，如Windows XPSP2，这个设置会被忽略。也就是说，应用程序并不能自己决定是否被DEP保护。

就性能而言，由于是CPU提供的硬件支持并触发异常，并不会有什么影响。

更大的考虑是兼容性。特别的，如果你的程序使用了ATL 7.1或更早的版本，由于ATL会在数据页面上产生执行代码（不要问我以前ATL为什么会这样设计。J），使用DEP保护运行时就会出现系统异常。

如果你的程序要使用第三方的插件DLL的话，而又事先无法确定第三方的DLL是否可以支持DEP的话，使用NXCOMPAT也可能会有问题。这是因为DEP的保护对象是进程一级。一个典型的例子是IE。IE需要支持第三方的IE Plugin插件。

使用Task Manager，选择Data Execution Protection列，可以看到在Windows Vista下，iexplorer.exe并没有被DEP保护。

图5：IE的DEP设置

同GS选项类似，也存在其它攻击方式可以绕过NXCOMPAT+DEP的保护机制，例如return-to-libc攻击。【3】

1. 总结

DEP，也就是数据执行保护，可以有效降低堆或栈上的缓存溢出漏洞<wbr></wbr>的危害性。采用NXCOMPAT选项后，应用程序的运行被DEP 机制保护。在考虑兼容性的前提下，建议开发人员采用NXCOMPA<wbr></wbr>T链接选项。

1. 参考文献

1）Page table：http://en.wikipedia.org/wiki<wbr></wbr>/Page_table

2）http://msdn2.microsoft.com/en<wbr></wbr>-us/library/ms680339(VS.85)<wbr></wbr>.aspx

3）Return-to-libc attack：http://en.wikipedia.org/wiki<wbr></wbr>/Return-to-libc_attack

4）Writing Secure Code for Windows Vista, Michael Howard, David LeBlanc.