Oracle获得安全权限非常重要，不过迄今为止，Oracle在这方面的表现却比较差。与其他的数据库服务器产品相比，Oracle RDBMS(关系型数据库管理系统，Relational Database Management System)存在的安全漏洞更加严重。这里的严重是指远程攻击者不需要用户ID和密码就可以利用那些缺陷，而且可以完全控制数据库服务器。IBM的DB2有1个漏洞；Informix有2个漏洞；Microsoft SQL Server有2个漏洞；Oracle有9个漏洞。Oracle存在的漏洞比其他数据库所有的安全漏洞加起来还要多。另一方面Oracle的隐患也比其他数据库多，这些隐患需要用到用户ID和密码，攻击者利用它们可以完全控制数据库。这些事实与号称自己产品“无懈可击”的Oracle市场宣传大相径庭。当Oracle的执行官说“我们已经解决了安全问题，这正是我们所擅长的…”，您可能会想他们到底在说什么。迄今为止，问题仍然没有解决，而且为绝大多数的政府网络开发安装软件的企业永远都不能满意。这也正是Oracle为什么要把它做好的原因—— 国家安全正受到威胁。 Oracle对于安全的认识在很大程度上是依据美国国防部的保证标准形成的。这就是为什么Oracle可以宣称“他们是安全的”。这或许在15年前是对的，不过从那时起安全的范畴已经完全改变了。下面进一步解释这个问题。Oracle RDBMS是按照通用标准EAL4(保证等级4)进行评估的，这是很难做到的。虽然Oracle先前的几个版本通过了EAL4的评估，但是在身份认证机制中仍存在缓冲区溢出漏洞。若传给服务器一个长的用户名，基于堆栈的缓冲区就会溢出，程序控制信息会被覆盖，攻击者会获得完整的控制权。这些到底是如何实现的以及如何不被人发现的呢？问题的答案是因为安全“标准”的意义与现实安全的意义有很大的区别。当然，标准的作用很重要，但是它们并不是安全所追求的全部目标和最终目标，Oracle应该吸取这个教训。标准意味着规则，但是攻击者却并不遵守这个规则。 或许Oracle已经意识到了这一点。他们已经动摇并改善了自己的编码标准，而且投资了许多工具来帮助自己开发更加安全的代码。有证据表明，它在安全方面的表现越来越好。Oracle 10g Release 2对10g Release 1做了巨大的改进。虽然在10g Release 2中仍然存在安全漏洞，但是数量比10g Release 1少了很多。Oracle还改进了自己的安全补丁发布机制。在每个季度，Oracle会发布一个关键补丁更新(Critical Patch Update，CPU)，而且至2006年7月，每个CPU都会因为修复失败、遗漏故障或其他问题而被多次重新发布。2006年7月的CPU与此不同，它只发布了一次—— 希望这会是一种新趋势的开始。 考虑到情况正在改善，即Oracle正在一步步地接近“安全”的理想境界—— 这是否意味着安全的产品完全匹配市场的要求？为了回答这个问题，对每一个出售者而言，最关键的是要观察他们如何回应安全研究人员。在2006年夏天的Blackhat Security Briefing中，笔者所在的小组就是讨论揭露安全隐患的。来自Gartner公司的小组主持人Paul Proctor很有远见地评价“Microsoft正在接纳阶段。Cisco正在缓慢地从愤怒阶段向接纳阶段过渡。另一方面，Oracle才刚刚走出否定的阶段，并开始走进愤怒阶段。” 在笔者看来，这个评价非常准确。就像几年前的Microsoft，也就是在Scott Culp发布自己的论文“Information Anarchy”的时候，Oracle也曾经评论过安全研究人员。Oracle的首席安全官Mary-Ann Davidson撰写了自己的文章：“When Security Researchers Become the Problem”。Mary-Ann的文章与Scott的论文的不同之处在于Scott的论文不需要说明，因为这篇论文是在信息混乱出现很久之后而且不再继续揭露很多漏洞的时候发表的。这是说服安全研究人员和供应商一起合作的一次尝试。Mary-Ann的文章几年之后仍然不能深入人心，这是因为她所藐视的安全研究人员已经在与Oracle一起尽力改善他们的产品了。Oracle未能看到自己与安全研究人员们一道朝着共同的目标—— 更加安全的服务器而努力。Mary-Ann文章的某些部分讨论了公开和私下制造威胁的安全研究人员，例如“在接下来的三周内修复它，因为要在Black Hat上提交论文。”但是，Oracle应该理解安全研究人员没有义务通知他们自己要提交论文，如果他们确实告知了Oracle，Oracle应该对此举表示感谢。这样的举措是一种礼貌。把它称之为“含蓄的威胁”是毫无诚意的，而且还会疏远有助于自己保护产品安全的人们。Oracle度过自己的愤怒阶段并尽快进入接纳阶段，这应该对所有的人都有好处。 对Oracle的评论已经足够了，至少就目前阶段而言已经足够了。下面看一看为什么要写本书来详细说明他们的RDBMS中存在的漏洞以及如何利用这些隐患。简而言之，这是因为它是一个非常流行的数据库服务器，它是黑客、犯罪组织、商业间谍和外国间谍的主要攻击目标。因此，数据库和安全管理员应该能够知道自己的系统是如何被攻击的，以及哪里存在漏洞。这样在设计防御策略和减轻攻击的时候他们才能处于有利的地位。 本书就是要提供这些信息。的确—— 这样的一本书在本质上是荒谬的：试图有助于防御，但是它不但把信息告诉了防御者而且也告诉了攻击者。但是根据笔者的经验，绝大多数攻击者都已经知道了这些信息，而防御者却并不知道。即便是现在，假设所有的证据恰恰相反，前面已经介绍过Oracle的“专家们”声称Oracle是安全的，引用的证据是Oracle“常常安装在防火墙之下”而且“运行在Unix平台上”。坦白地说，这些“原因”与Oracle是否安全无关。进入运行在Linux或Solaris平台上的Oracle服务器与进入运行在Windows平台上的Oracle服务器一样容易。一旦在防火墙上打开了一个洞，就可以通过它令自己的业务逻辑和Web应用程序连接到数据库服务器，这样防火墙就会变得无关紧要—— SQL注入是一个主要问题。 此外，说Oracle常常安装在防火墙之下也是无稽之谈。根据笔者在2005年12月完成并于2006年6月发布的“数据库曝光调查”，相对于210 000个可以访问的Microsoft SQL Server，网络上大约有140 000个Oracle数据库服务器可供访问。假设许多SQL Server都是MSDE，那么考虑一下Oracle Express会对这个数字产生什么样的影响。Oracle Express是在这个调查完成之后发布的。但是回到问题的核心部分，Oracle领域里的那些人却没有充分意识到自己的服务器存在危机。Oracle已经同意每3个月发布一次关键补丁更新，至少到2007年7月(写这本书期间)，这意味着在这期间Oracle数据库服务器处于极度危险的状态中。这确实发人深省。这也正是原因所在。如果要对自己的系统安全负责，在知道了它们确实不安全之后，需要知道它们不安全的原因—— 只有这样才能采取措施，防止自己的系统受到威胁。 笔者希望本书能够对读者有所帮助并能增长见识，同时也希望能够激起读者阅读的兴趣。笔者一直希望能够回答这些有关数据库安全的问题，所以请尽管提问。 祝好， David Litchfield david@databasesecurity.com 书中的代码示例 若想下载书中相关的代码示例，请访问本书的Web站点,合作站点www.tupwk.com.cn/downpage。 Oracle与安全性 1997年6月，Larry Ellison和Robert Miner成立了公司Software Development Labs。他们两个都曾经在Ampex工作过。Robert曾经是Larry的上司。他们两个都受到了Edgar Codd工作的启发。Codd曾经做过IBM的研究员并提出了关系数据库的思想。在1970年他发表了论文“RelationalModel of Data for Large Shared Data Banks”。IBM很久以后才看到Codd思想的前景，而Larry和Robert却不是。在1979年，他们把自己的公司更名为Relational Software, Inc.,而且没过多久就又改名为Oracle。Oracle曾经是Larry和Robert在Ampex工作时所参与的一个CIA项目的代码名。其实，Oracle公司最初几年的客户就是CIA和NSA。知道了这些，就可以猜想到安全性应该是Oracle的首要日程。 在1999年，Oracle开始受到了安全研究团体的关注。根据，同年4月29日公开了Oracle的第1个安全故障：Dan Sugalski公开oratclsh程序是setuid root而且可以被*nix组的“其他人”执行。这意味着任何人都能够以root用户的身份运行TCL脚本。不久之后，作者和Georgi Guninski公开了与Oracle Web Listener有关的许多安全隐患，以及与默认许可有关的其他问题。在2000年，Oracle开始发布自己的警报，不过这些都是基于ad-hoc发布的，而且常常是在某个缺陷被公布之后的几个月内发布的。 图0-1给出了“早”几年所报告的故障数量。可以看到，故障的数量呈指数级增长，而且实际上这也是图中没有给出2003年和之后故障数目的唯一原因—— 可以说故障的数目会超出最高限度。绝大多数的故障都和RDBMS中的缓冲区溢出或应用程序服务器有关。Oracle的一个严重缺陷就是PL/SQL注入，这个问题直到2003年11月5日Oracle发布了第61号警报的时候才被公开—— 这个警报涉及笔者发现的许多注入隐患。这引发人们发现了大量的PL/SQL注入隐患，而且即使是在今天，Oracle所修复的绝大多数问题都是注入问题。在本书的后面会看到，PL/SQL中的隐患是RDBMS的弊端，而且它们一旦被利用就会允许攻击者完全控制数据库服务器。 图0-1 1999~2002年之间故障数量稳步增长 “不可攻破”的市场宣传 伴随着Oracle 9i的发布，Oracle在2001年12月展开了新的市场宣传。他们宣称自己的产品是“不可攻破的”，而且没有人可以“破坏它”或“强行进入它”。对许多安全行业的人来说，这就是所谓的短暂瞬间：每个人都记得自己第一次听到Oracle的发布内容时自己在做什么。笔者当然记得自己当时在做什么，而且毫无疑问，还记得此后做过的许多其他事情—— 下载这个“不可攻破的”软件并看看它到底有多健壮。在发布期间，笔者和弟弟Mark发给Oracle一些报告，上面详细说明了破解和强行进入服务器的许多方法。Oracle修复了这些隐患之后，笔者在2002年2月的BlackHat Securtiy Briefing上提交了一篇关于这个问题的论文。Oracle完全被破解了。 现在，Oracle会说自己的宣传口号表明了自己对安全的承诺，但是并不能看作是对自己产品安全性的评价。 独立安全性评估 因此该如何看待Oracle的安全性承诺呢？他们那样说到底意味着什么？Oracle已经投入了大量的资金来独立评估自己的产品。这些证明Oracle是安全的积极证据是用来欺骗消费者的。但是在“现实的”安全领域中，通过了通用标准下的EAL4(保证等级4)并不能说明什么。Oracle和IBM的Informix(EAL2)都通过了通用标准，但是它们都存在长用户名导致的缓冲区溢出漏洞。产品中的许多特征都能够通过这个标准，但是它们都存在漏洞。如果城堡的门都是软的，那么这个城堡就不再是城堡了。 最早通过EAL4的Oracle版本是1998年9月发布的7.2版本，接下来就是2000年10月的Oracle 8.0.5，然后是2001年7月的8.1.7.0。2003年9月，Oracle 9iR2通过了认证，接下来在2005年9月，10g Release 1也通过了认证。既然是为了通过认证，那么所有的这些版本都是有所欠缺的，是不合格的。 笔者并不是独立安全性评估的粉丝，但是却认为独立安全性评估确实有自己的作用，能为开发人员提供前进的目标。但是只有在软件开发不是为了遮掩或美观的时候，这种说法才成立。 展望未来 Oracle 10g Release 2 是一个很好的产品。在安全性方面，它对10g Release 1做了很大的改进。为此应该对Oracle加以称赞。但是，“任务还没有完成”。10g Release 2中仍然存在故障(本书中讨论了很多)，而且还有很多故障没有被发现。尽管如此，在10g Release 1中只需要进行5~10分钟的搜索就可以发现一个新故障，而在10g Release 2中要花费一天或更多的精力才能找到一个新故障。这些进步在很大程度上得益于对源代码审计工具的巨大投资。这些工具负责寻找绝大多数隐患，但是它们也存有局限—— 例如，在PL/SQL过程调用C函数或Java函数的时候，这个工具似乎不能找到在这些交叉点所出现的隐患。为了找出这些残留的问题，Oracle需要对这些工具进行改进。应该把源代码审计工具用作一种“最终的防御”机制。若要在安全性改善方面取得巨大的进步，开发者代码是关键，必须有好的安全编码标准和过程。就像Microsoft发布关于安全开发生命周期(Security Development Lifecycle，SDL)的标准和过程一样，笔者也希望Oracle能够这样做。这对整个行业也是有益的。