精解——安全配置 Windows 2000服务器

图20所示的testlibsafe.c是一段非常简单的程序，字符串buf2[16]中首先被写满了''A''，然后再通过strcpy(3)将其拷贝到buf1[8]中。由于buf2[16]比buf1[8]要大，显然会发生缓冲区溢出，而且很容易想到，由于''A''的二进制表示为0x41，所以main函数的返回地址被改为了0x41414141。这样当main返回时就会发生Segmentation fault。

#include <string.h>void main(){        char    buf1[8];        char    buf2[16];        int     i;        for (i = 0; i < 16; ++i)                buf2[i] = ''A'';        strcpy(buf1, buf2);}

图20 测试Libsafe

$ gcc testlibsafe.c -o testlibsafe$ ./testlibsafeSegmentation fault (core dumped)

下面我们就来看一看Libsafe是如何保护我们免遭缓冲区溢出攻击的。首先，在系统中安装Libsafe，本文的附件中提供了其2.0版的安装包。

$ suPassword:# rpm -ivh libsafe-2.0-2.i386.rpmlibsafe################################################### exit

至此安装还没有结束，接下来还要正确设置环境变量LD_PRELOAD。

$ export LD_PRELOAD=/lib/libsafe.so.2

下面就可以来试试看了。

$ ./testlibsafeDetected an attempt to write across stack boundary.Terminating /home2/wy/projects/overflow/bof/testlibsafe.    uid=1011  euid=1011  pid=9481Call stack:    0x40017721    0x4001780a    0x8048328    0x400429c6Overflow caused by strcpy()

可以看到，Libsafe正确检测到了由strcpy()函数导致的缓冲区溢出，其uid、euid和pid，以及进程运行时的Call stack也被一并列出。另外，这些信息不光是在终端上显示，还会被记录到系统日志中，这样系统管理员就可以掌握潜在的攻击来源并及时加以防范。

那么，有了Libsafe我们就可以高枕无忧了吗？千万不要有这种天真的想法，在计算机安全领域入侵与反入侵的较量永远都不会停止。其实Libsafe为我们提供的保护可以被轻易的破坏掉。由于Libsafe的实现依赖于Linux系统为动态链接库所提供的预载机制，因此对于使用静态链接库的具有缓冲区溢出漏洞的程序Libsafe也就无能为力了。

$ gcc -static testlibsafe.c -o testlibsafe_static$ env | grep LDLD_PRELOAD=/lib/libsafe.so.2$ ./testlibsafe_staticSegmentation fault (core dumped)

如果在使用gcc编译时加上-static选项，那么链接时使用的便是静态链接库。在系统已经安装了Libsafe的情况下，可以看到testlibsafe_static再次产生了Segmentation fault。

另外，正如我们在本文前言中所指出的那样，如果读者使用的是较高版本的bash的话，那么即使您在运行攻击程序exe之后得到了一个新的shell，您可能会发现并没有得到您所期望的root权限。其实这正是的高版本bash的改进之一。由于近十年来缓冲区溢出攻击屡见不鲜，而且大部分的攻击对象都是系统中属主为root的setuid程序，以借此获得root权限。因此以root权限运行系统中的程序是十分危险的。为此，在新的POSIX.1标准中增加了一个名为seteuid(2)的系统调用，其作用在于改变进程的effective uid。而新版本的bash也都纷纷采用了这一技术，在bash启动运行之初首先通过调用seteuid(getuid())将bash的运行权限恢复为进程属主的权限，这样就出现了我们在高版本bash中运行攻击程序exe所看到的结果。那么高版本的bash就已经无懈可击了吗？其实不然，只要在通过execve(2)创建shell之前先调用setuid(0)将进程的uid