/NXCOMPAT编译选项 : 数据执行保护DEP

来源：互联网发布：git安装教程mac 编辑：程序博客网时间：2024/05/29 01:52

x86 : XP支持/Win7支持

x64 : 不支持

概述

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

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

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

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

DEP和硬件支持

2.1软件DEP和硬件DEP

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

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

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

2.2 NX位

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

图1：页面内存映射

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

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

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

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

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

图2：DEP设置

使用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=Pexhttp://metasploit.com */

unsigned char scode[] =

"/x2b/xc9/x83/xe9/xdd/xe8/xff/xff/xff/xff/xc0/x5e/x81/x76/x0e/xd2"

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

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

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

"/xd3/x7f/x1c/xc1/xe9/xe9/xd3/x31/xa7/x58/x7c/x6a/xf6/xbc/x1c/x53"

"/x59/xb1/xbc/xbe/x8d/xa1/xf6/xde/x59/xa1/x7c/x34/x39/x34/xab/x11"

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

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

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

"/xa1/xd5/x6f/xcb/x58/xb3/xa0/xca/x35/xde/x96/x59/xb1/x93/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作为函数指针指向这段代码。整个程序的目的就是试图在数据页面上执行代码。

在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.exe程序被终止。

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

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机制的保护。

NXCOMPAT选项的内部实现

NXCOMPAT的实现，是通过在Windows PE文件头信息（PE Header）中设置IMAGE_DLLCHARACTERISTICS_NX_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_COMPAT

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

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

NXCOMPAT选项的局限

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

其次，NXCOMPAT选项，或者是IMAGE_DLLCHARACTERISTICS_NX_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】

总结

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

参考文献

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

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

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

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

0 0