第三方软件开发不能忽视Vista安全功能

ZDNet安全频道原创翻译 转载请以文字链形式注明出处

作者：内森·马菲特史
 
考虑到微软花费了大量人力和物力为Vista操作系统添加安全功能，但还是有老的经典漏洞出现。这是为什么？答案其实很简单，第三方创建的代码并没有利用这些强大的保护机制。

我并不是第一个谈论这个问题的人，但是始终觉得这个问题是需要继续强调的，特别是在这些保护机制被更广泛地利用之前。实际上，我看到过最近对这些保护机制的几次大讨论。

Vista操作系统内置了多种安全机制，但本文将主要关注地址空间布局随机化（ASLR）和数据执行保护（DEP）这两种。

· 数据执行保护（DEP）可以防止一个非可执行内存区域里的代码被执行。它是硬件和软件相结合的，有两种实现方式，运行的情况如下说明：

a.基于硬件的数据执行保护模式，如果处理器可以支持NX（No eXecute : 不可执行）特性的话，基于硬件的系统保护可以将内容位置标记为“不可执行”，为Windows操作系统提供更充分的保护。

b.基于软件的数据执行保护模式也叫做安全结构例外处理（SafeSEH），可以对地址异常处理的代码进行管理，防止受到劫持。

· 地址空间布局随机化（ASLR）的过程中，数据的位置是随机。这就意味着，即使你找到了一个可能的位置，也无法进行攻击，因为位置是可能改变的。

不幸的是，数据执行保护（DEP）模式可能会导致一些兼容性问题，象在Java的世界里，就有可能由于自我修改代码或者汇编代码引起错误。因此，数据执行保护（DEP）模式是一个可选项。这也就意味着，在某些情况下，我们可能不会受到这样的保护。约翰·汉森的文章中就有一个典型的例子。一个Java Applet可以通过使用攻击者制作的TrueType字体执行代码，从而实现攻击的目的。

除此之外，数据执行保护（DEP）模式不会提供地址空间布局随机化（ASLR）的保护。地址空间布局随机化（ASLR）本身也是一个可选项。正因为如此，即使启用数据执行保护（DEP）模式，一个有缺陷的代码也还可以被利用进行返回libc攻击。返回libc攻击（Return-to-libc attack）通常以缓冲器漫溢开始， 其中在堆栈中的这个返回地址被在程序中的另一个函数地址取代。这样的话，就可以将恶意代码注入到一个程序中。

此外，数据执行保护（DEP）模式在地址空间布局随机化（ASLR）没有使用的时间可能被关闭，在“绕过Windows操作系统基于硬件的数据执行保护模式 ”一文中，有相关的介绍。

所有这一切说明了什么？问题关键在于虽然Windows操作系统的安全已经取得了重大改进的时间，我们加入的组件却会让安全性能下降，并出现大问题。因此，梅诺在他的Blog中提到：

“回到地址空间布局随机化技术这个话题，它可能会让少数几个软件出现问题，但大部分软件是没有受到影响的。因此，软件开发商没有理由继续无视这个问题。其实，我们发现在目前流行的软件中：Mozilla的Firefox浏览器、谷歌的工具栏、苹果的iTunes、Adobe的PDF阅读器、Roxio的媒体制作工具和DivX的播放器实际上都没有考虑地址空间布局随机化技术的影响。”

我希望早改变总比晚改变好。