Linux 下数据库安全漏洞有哪些分类

Linux下数据库安全漏洞分类如下：

• 验证协议中的漏洞

• 未经验证访问功能

• 在固有的SQL元素中执行任意代码

• 在不安全的SQL元素中执行任意代码

• 通过SQL注入进行特权提升

• 本地特权提升的问题

因此我们将从最危险的安全漏洞（网络协议中未经验证的漏洞）类别开始研究，这里指数据库系统使用潜在网络协议时的缓冲区溢出、格式化字符串漏洞等问题。下面简单介绍几个。

1. 网络协议中未经验证的漏洞

   这个类别中著名的bug是NGS公司的Chris Anley在Oracle的extproc机制中发现的一个漏洞，它允许远程的、未经验证的缓冲区溢出。NGS公司的Mark Litchfield还在Oracle的验证处理代码中发现了漏洞，在这种漏洞下，超长的用户名将触发可利用的栈溢出（CAN-2003-0095）。David Litchfield还在DB2的JDBC AppletServer中发现了一个漏洞（没有CVE，但bug的id号为11401），它允许远程的、未经验证的用户触发缓冲区溢出。通常，防御这类问题、保护自己的最好方法是打补丁。然后，应该努力确保只有可信任的主机才能连接到你的数据库服务器，可以通过其他一些验证机制，如SSL/SSH或IPSec来加强这种信任。根据你的数据库服务器所履行的角色而定，这需要一定的技巧。另一种可行的防御办法是实现IDS（Intrusion DetectionSystem，入侵检测系统）或IPS（Intrusion Prevention System，入侵预防系统）。在有关安全的著作中已广泛讨论过这些系统，它们的价值具有争议。尽管IDS能够（有时）告知你处境危险，但它通常不会防止危险发生。当然，IDS能制止潜在的攻击者，或者曝光那些不幸的攻击者，倘若这些系统能对熟练的人员、好的防范以及不错的程序进行补充（而不是替换），那么它们还是值得实现的。

   另一方面，IPS的确防御了部分攻击。但是根据调查，只要做少量的工作就能绕过IPS，因此大部分情况下的安全保障，只能指望攻击者不知道你使用了哪种商业IPS。有人可能会推荐某个IPS，说它能在一定程度上阻止所有任意代码执行的攻击，这确实是一件极好的事情。然而，这样的可能性极小。

2. 网络协议中经过验证的漏洞

   这类漏洞比较少。这可能反映了在安全研究领域中，与未经验证的bug相比，人们对远程的、经过验证的漏洞的关注程度低一些。David最近又在DB2中发现了同类型的另一个漏洞，这个漏洞是攻击者指定的超长本地LC_TYPE的。数据库会在用户验证后使用LC_TYPE，它会触发溢出。还有其他一些bug属于这种类型，这些bug通常是关于Web应用服务器组件的。因为我们关注的是数据库本身，所以不会讨论它们。通常，保护自己不受这类bug侵害的最好方法是仔细控制那些访问数据库的用户；强健的口令策略将会有所帮助——只要你不使用明文验证协议（稍后介绍）。审核已验证的用户也是好方法。如果有人尝试强制猜出口令，而他的确成功了，这一定会使你烦恼，但至少你还知道从何处开始检查。

3. 验证协议中的漏洞

   有一些数据库系统使用明文（plaintext）验证协议，这种协议是指口令以明文形式或者很容易解码的形式在线路上进行传输。在默认配置中（Sybase公司对此发出了警告，但我们看到它仍然被使用），Sybase以明文形式传输口令。在这两种情况下，销售商都警告说不要使用他们验证协议中的明文版本，并且提供了配置相对简单而强健的加密机制——但使用默认设置的情况依然存在，它们依然很危险。从历史上看，MySQL已经在验证协议方面产生过大量严重的问题。4.1版本以前的MySQL中验证协议还存在更深层次的问题，协议仅仅测试了口令信息的相关知识，还不是口令本身。如果用户在某种情况下能够确定另一个用户的口令信息，这将导致非常严重的问题。众多问题中就已经存在一些可能导致这种现象的问题。

4. 未经验证访问功能

   有些与数据库相关的组件允许对功能进行未经验证的访问，而实际上它们恰恰需要验证。下面举例说明：David Litchfield曾发现Oracle 8和9i TNS Listener有这样的问题，远程的、未经验证的用户能够通过“extproc”机制（CVE-2002-0567），下载并执行任意函数。此函数可以有任意的原型，所以这种攻击模式显然是为了下载1ibc或msvcrt库（依赖目标平台），并且执行“系统”函数，以允许攻击者能够执行任意命令行。命令一旦被执行，就使攻击者拥有了这样的特权，数据库将如同UNIX系统上的“Oracle”一样运行，或者使攻击者成为相当于Windows系统下的本地系统用户。目前，David Litch field揭示了这样一个问题，即在Oracle作为安全背景来运行系统的情况下，能够允许任一本地用户执行命令（CAN.2004-1365）。这个问题与先前列出各问题的运行机制几乎完全相同（CVE-2002.0567），不同之处在于，这种错误利用了extproc在本地主机上设置的隐式信任机制。Oracle并不认为这是个问题，但必须警告你，千万不要忘了考虑安全隐患，而允许用户掌控Oracle服务器的shell。很明显，允许用户掌控数据库服务器shell无论如何都是危险的，但如果存在一种已知的、被引证的向量，它用来应对销售商无法修复攻击的情况，那么这就是特例了。