Friday, January 8, 2010
Gaining Access to the Filesystem Through DB2
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 simple—if 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.sysdummy1These 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.
No comments:
Post a Comment