Gaining Access to the Filesystem Through DB2

As with most database servers, DB2 supports a number of ways to interact with the operating system's filesystem. It is crucial that access to these methods be restricted. The reason for this is quite simpleif an attacker can gain read access to files that contain sensitive information, this can be used to further compromise the system; or indeed just gaining access to the information might be enough if that's the attacker's end goal. If an attacker can gain write access to the filesystem, this is considerably more dangerous because it can be used to create files with "executable" content, which could be scripted files such as shell scripts or even binary executables. One common theme among database servers is that access to the filesystem through the RDBMS is done with the security privileges of the account running the process; DB2 is not different. Let's examine how DB2 can allow attackers to gain read or write access to the filesystem.

The Load Method

DB2 supports a LOAD SQL query that allows a file's contents to be read and loaded into a table. To be able to use load, the user account must have the LOADAUTH authority. By default, PUBLIC does not have this authority. Assuming you have this authority files can be read in a similar way to the following:

 create table ldtest (t varchar(2000)) load from f:\test.txt of del insert into ldtest 

This will read the file f:\test.txt and insert the contents into the ldtest table. The LOADAUTH authority should be restricted.

XML Functions

If the DB2 database has been XML enabled, an attacker can use four of the functions that are created, namely, XMLVarcharFromFile, XMLClobFromFile, XMLFileFromClob, and XMLFileFromVarchar. The first two provide write access to the filesystem and the last two read access to the filesystem. For example, to read a file you can execute

 select db2xml.xmlvarcharfromfile('c:\boot.ini','ibm-808') from_sysibm.sysdummy1 

These functions execute with the privileges of the account running the DB2 server and not the privileges of the client account. It is hoped that IBM will at some point in the future change this. What makes XMLVarcharFromFile and XMLClobFromFile particularly dangerous is the fact that they can be used to create files with arbitrary binary content when used with the CHR() function. The CHR() function takes a decimal value as an argument and converts it to binary. So if I wanted to write out 0xCC to a file, twice, I could do so with the following:

 select DB2XML.XMLFileFromVarchar(CHR(204)CHR(204),'c:\test.bin') from_sysibm.sysdummy1 

This will create a 2-byte file with each byte having a value of 0xCC. If the file exists, then it is overwritten. This presents attackers the ability to overwrite binary executables with their own trojaned versions; or alternatively, simply drop an executable (or script) file into a directory where it will be executed automatically: for example, dropping a batch file into the administrator's startup folder.