Experiencing a Security Breach?

24 Hour Hotline: +1 (866) 659-9097 Option 5

General

+1 (312) 873-7500

Monday - Friday 8:00 AM - 6:00 PM CT (UTC -6)

Sales

Contact a Trustwave solution specialist.

+1 (888) 878-7817

Monday - Friday 8:30 AM - 5:30 PM CT (UTC -6)

Loading...

Blogs & Stories

SpiderLabs Blog

Attracting more than a half-million annual readers, this is the security community's go-to destination for technical breakdowns of the latest threats, critical vulnerability disclosures and cutting-edge research.

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.

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.

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:

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!

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:

Valid credentials to connect to the database

CONNECT privilege on the database

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.

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.