新一篇: IE8的最新安全特性 | 旧一篇: 2008腾讯安全峰会有感

《程序员》3月文章

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

1. 概述

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

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

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

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

2. 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设置

3. 使用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\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机制的保护。

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

5. 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】

6. 总结

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

7. 参考文献

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.

 

 

 

 

发表于 @ 2008年04月26日 04:50:00|评论(loading...)|编辑

新一篇: IE8的最新安全特性 | 旧一篇: 2008腾讯安全峰会有感