5.2.1 数据驱动攻击

讨论完口令猜测攻击后，我们该解释获取远程访问权限的事实标准——数据驱动攻击(data driven attack)了。数据驱动攻击是通过向某个活动中的服务发送数据，以产生非预期结果来进行的攻击。当然，“非预期结果”这一说法因人而异。从攻击者看来结果是所希望的，因为它们给出了访问目标系统的许可权。从编程人员看来，那是他们的程序收到了未曾料到的将导致非预期结果的输入数据。数据驱动攻击分为缓冲区溢出攻击(buffer overflow attack)和输入验证攻击(input validation attack)。下面分别讨论这两种攻击。

1.缓冲区溢出攻击

流行度：

8

简单度：

8

影响力：

10

风险评级：

9

1996年11月，计算机安全的未来发生了历史性转变。Bugtraq邮件列表的创始人Aleph One给安全杂志Phrack Magazine(第49期)写了一篇题目为“Smashing The Stack For Fun And Profit”的文章。这篇文章对于安全界产生了深远的影响，因为它清楚地阐明了糟糕的编程行为在缓冲区溢出攻击下会如何危及安全。缓冲区溢出攻击可追溯到1988年臭名昭著的Robert Morris蠕虫事件；然而关于这种攻击的有用信息直到1996年才为人所知。

在某个用户或进程试图往一个缓冲区(即固定长度的数组)中放置比原初分配的空间还要多的数据的时候，就会出现缓冲区溢出条件(buffer overflow condition)。这种情况与C特有的函数，例如strcpy()、strcat()、sprintf()等有关。正常的缓冲区溢出条件会导致段越界发生。然而精心利用这类情况，可以达到访问目标系统的目的。尽管我们讨论的是远程缓冲区溢出攻击，缓冲区溢出条件在本地系统上也同样发生，在本章稍后会继续谈及。为了理解缓冲区溢出的发生过程，下面举一个非常简化的例子。

我们有一个长度固定为128字节的缓冲区。假设该缓冲区定义成可作为存放sendmail的VRFY命令的输入数据。第3章中我们曾使用VRFY来帮助确认目标系统上的可能存在的用户，方法是验证他们的电子邮件地址。再假设sendmail是将用户ID设(SUID)为root的程序，从而不论谁执行都以root特权运行。这种假设对于现实系统可能成立，也可能不成立。如果攻击者连接到目标系统的sendmail守护进程后，给VRFY命令发送一块由1000个字母“a”构成的数据，而不是一个简短的用户名，情况会是什么样呢？

echo "vrfy ‘perl -e 'print "a" x 1000'’" | nc www.example.com 25

VRFY缓冲区将溢出，因为它只能容纳128个字节。往VRFY缓冲区中填塞1000个字节可能导致拒绝服务和sendmail守护进程的崩溃；然而由此精心设计一下，让目标系统执行攻击者选定的代码将更为危险。这恰好是成功的缓冲区溢出攻击的工作机理。

攻击者当然不会向VRFY命令发送1000个字母“a”，而是发送将使缓冲区溢出并执行命令/bin/sh的特定代码。既然sendmail是作为root运行的，因此当执行/bin/sh时，攻击者即具备直接的root访问权。你可能对于sendmail如何知道攻击者想要执行/bin/sh心存疑惑，其实过程并不复杂。当执行攻击时，称为“egg”的特殊汇编代码被作为溢出缓冲区的实际字符串的一部分发送给VRFY命令。当VRFY缓冲区溢出时，攻击者可设置导致问题的函数的返回地址，以改变程序的执行流。此时该函数不再返回其正确的内存位置，而是执行攻击者作为缓冲区溢出数据的一部分发送的恶意汇编代码，该代码将以root特权运行/bin/sh。于是大功告成。

必须注意，汇编代码与体系结构和操作系统直接相关。Solaris X86的缓冲区溢出与Solaris SPARC不同。下面的例子说明了Linux X86的特定“egg”汇编代码：

char shellcode[] =

"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"

"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"

"\x80\xe8\xdc\xff\xff\xff/bin/sh";

显然，缓冲区溢出攻击极为危险，已造成了许多安全方面的损害。上述例子非常简化，而创建一个有效的“egg”代码是极端困难的。然而已有不少特定系统的“egg”代码被创建出来，可从因特网上获取。如果你对缓冲区溢出的内容不熟悉，建议阅读Aleph One发表在Phrack Magazine(第49期)上的文章。

2. 针对缓冲区溢出攻击的防范对策

对这些威胁性有了清楚的认识后，让我们调查一些应对缓冲区溢出攻击的防范措施。任何一种措施都有自身的优缺点，从成本和效率方面认识他们的差异性是非常重要的。

(1)遵循安全编码实践

预防缓冲区溢出的对策是遵循安全编码实践。尽管不可能设计和编写没有缺陷的程序，但有些措施将有助于最小化缓冲区溢出条件。下面是些建议：

程序从一开始设计起就考虑到安全。太多的情况是，程序匆匆编写而成以努力满足程序主管的期限要求，安全是去解决的，还往往被遗漏。在对一些近期发行的代码上，厂家近乎漫不经心。许多厂家对其在安全编码上的草率心知肚明，但是他们却没花时间去解决这样的问题。关于Linux和UNIX的安全编程可以详细参见www.dwheeler. com/secure-programs/Secure-Programs-HOWTO。

实现gcc程序编译器提供的Stack Smashing Protector(SSP，Stack Smashing攻击保护)功能。SSP是Immunix的Stackguard的提高版，已经被正式地包含于程序编译器中。SSP和Stackguard都是通过使用信号分析软件识别堆栈溢出，从而将缓冲区溢出的影响降至最小。OpenBSD的默认设置启动了这一功能，其他操作系统可以通过将fstack-protect 以及fstack-protect-all标志传递给gcc来实现这一功能。

当从用户或其他程序接收输入时，必须验证参数的有效性。这种验证包括对每个变量的边界检查，特别是环境变量。

使用fgets()、strncpy()和strncat()之类安全的函数，并检查系统调用的返回值。

如有可能，采用更好的string库。Bstrings是一种可移植、独立和稳定的库，能够帮助减轻缓冲区溢出攻击。Bstring的补充资料可以在bstring.sourceforge.net找到。

减少以root权限运行的代码。减少使用SUID root程序。这样即使攻击者成功地执行了缓冲区溢出攻击，他们还得继续把自己的特权升级到root。

安装所有相关的由厂家提供的安全补丁。

(2)测试并审核每个程序

测试并审核每个程序非常重要。许多时候编程人员并未意识到存在潜在的缓冲区溢出条件，然而，第三方可能不怎么费力就检测出这种缺陷。测试和审核UNIX代码的例子之一是由Theo de Raadt领导的OpenBSD项目(www.openbsd.org)。OpenBSD阵营一直在审核他们的源代码，且已修复了数百个缓冲区溢出条件，更不用提其他类型的安全相关问题了。正是这种彻底审核让OpenBSD赢得了这样的声誉：最安全的免费版本UNIX之一(注：最安全并不等同于无法渗透)。

……