Chapter 8: Attacking DB2

This section details the many ways in which an attacker can compromise a DB2 installation. Many of the problems discussed here can be fixed with a patch ”but in addition to that the risk associated with many of these issues can be removed, or at least mitigated, with a workaround. DB2 administrators should be aware of these attacks and take steps to protect their servers against them.

Buffer Overflows in DB2 Procedures and Functions

Procedures and functions in the DB2 world are known as routines and most are written in C. As such, they can be vulnerable to the standard C issues such as buffer overflows and format string vulnerabilities. As it happens they are. During the course of researching DB2 for this book Mark Litchfield and I found a number of buffer overflow vulnerabilities in various procedures and functions. These were reported to IBM and a patch has been made available. The following procedures and functions are known to suffer from buffer overflow vulnerabilities.

REC2XML

XMLClobFromFile

XMLVarcharFromFile

XMLFileFromClob

XMLFileFromVarchar

SatEncrypt

GENERATE_DISTFILE

Of particular interest are the overflows in the XML* functions. The overflow they are vulnerable to is one of the strangest I've ever come across and the peculiarity makes them very easy to exploit. Essentially they all call the same bit of code, that when a certain length is specified for the third parameter the saved return address on the stack is overwritten with a pointer to somewhere in the middle of the buffer! This essentially means that when the vulnerable function returns it does so into the user-supplied data. When it comes to exploiting a normal stack-based overflow, the attacker needs to overwrite the saved return address with an address that points to a bit of code, a "jmp esp" for example, that'll get the processor executing code from the user -supplied buffer. This often involves a bit of guesswork on the part of the exploit-writer, but with these XML* overflows none of the guesswork is required because a pointer to the user-supplied buffer is written over the saved return address automatically. To demonstrate this, consider the following SQL:

 SELECT db2xml.xmlvarcharfromfile('c:\boot.ini', 'AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLL LLMMMMNNNNOOOO'  chr(204) 'PPPQQQQRRRRSSS STTTTUUUUVVVVWWWWXXXXYYYY') from sysibm.sysdummy1 

When executed, this SQL will overflow the stack-based buffer; in doing so, a pointer to the middle of the buffer overwrites the saved return address. As a result, the chr(204) resolves to 0xCC ”a breakpoint ”and is executed. Later, we'll examine how these functions can be used by an attacker to gain access to the filesystem with potentially devastating consequences.

Note  

The best way to defend against these overflows and overflows that have yet to come to light is to limit who can execute functions and procedures. That said, one of the most frustrating things about DB2, though, is the inability to revoke execute access on procedures and functions from PUBLIC if the routine is in the SYSIBM or SYSFUN schemas.

Other Overflows in DB2

DB2 is vulnerable to other buffer overflows that are related to routines. A while back a report came in about a buffer overflow with the LOAD command. By supplying an overly long parameter to LOAD, a stack-based buffer was overflowed. This allowed for an attacker to gain control. To be successful the attacker would need to have the LOADAUTH authority. Similar to this LOAD overflow, the CALL command is likewise vulnerable. In DB2 it is possible to execute a function within a library using the following syntax:

 CALL libname!function 

This is in and of itself a vulnerability (see the following note) but it is also vulnerable to an overflow. This is triggered when a long library name is supplied. This occurs because the sqloLoadModuleEP() function calls an unnamed subfunction, which declares a 260-byte buffer on the stack. The install path for DB2 is then copied to this buffer and then "function\fenced." The user-supplied library name is then appended. Because the attacker can supply a library name of up to 250 bytes, it's easy to see that the buffer can be overflowed. This can be used by an attacker to run arbitrary code.

Note  

The CALL overflow is useful only if the attacker can't place his own DLL or shared object on the system. If he can place his own library onto the filesystem, then rather than exploiting the overflow all the attacker needs to do is call his function in a library. One restriction is that the function cannot take a parameter ”though this really doesn't present a problem. All the attacker needs to do is export a function that contains the code for what he wants to do, compile the library, then place it on the system. With this done the attacker uses CALL to load the library and execute the function. Currently, there is nothing to stop this other than by ensuring that the attacker can't place arbitrary libraries on the system.

Incidentally, the same vulnerable bit of code can be reached through the CREATE WRAPPER command:

 CREATE WRAPPER DTLIB LIBRARY 'longlibname' 

This will trigger the same overflow. I alerted IBM to this flaw and it has since released a patch, available from the IBM web site.

It is interesting to note that many of the procedures that touch the filesystem are vulnerable in a similar fashion, for example the generate_distfile procedure. generate_distfile is implemented as a C function, exported by db2dbappext.dll. It takes as its third parameter the name of a file. This parameter can be up to 255 characters long.

One of the subfunctions of generate_distfile takes the third parameter, the user-supplied filename, and appends it to the directory where DB2 has been installed. It does this by creating a 264-byte buffer on the stack. The subfunction then calls sqloInstancePath() to get the install path for DB2.

This returns C:\PROGRA~1\IBM\SQLLIB\DB2. \tmp\ is then appended to this. After \tmp\ is appended the user-supplied filename is appended using a while loop that continues to copy data until a NULL terminator is found. Because the DB2 install path (C:\PROGRA~1\IBM\SQLLIB\DB2\tmp\) takes up some of the buffer, if the user has supplied a third parameter of 255 bytes, the stack-based buffer is overflowed.

However, once the buffer is overflowed, as well as overwriting the saved return address, a pointer is also overwritten. This pointer points to a buffer where the resulting full path should be copied to. This interrupts a straight return address overwrite exploit; however it can still easily be exploited in several ways. Because the attacker "owns" the pointer to where the path is copied to, he can write arbitrary data to an arbitrary location allowing a full compromise. One such method would be to overwrite the pointer to the Windows UnhandledExceptionFilter function; because access violations aren't handled, the UEF kicks in and, because the attacker controls the UEF, the flow of execution can be redirected by the attacker to arbitrary code.

DB2 Set Locale LCTYPE Overflow

Underneath the covers, once a client authenticates, one of the first things a client will do is set the locale lctype:

 SET LOCALE LCTYPE = 'en_GB' 

By specifying an overly long string, 60 bytes in the case of DB2 8.1.6, the saved return address is overwritten allowing the attacker to gain control of the server's path of execution.

Note  

I discovered this overflow very late in the process of writing this chapter. The problem has been reported to IBM and a fix should be out before this book is published.

DB2 JDBC Applet Server Buffer Overflow

The DB2 JDBC Applet Server acts as a gateway between a java applet client and the database. I suppose the reason it exists is so that the client is not required to have the DB2 libraries installed to be able to communicate with a DB2 database. The JDBC Applet Server listens for requests on TCP port 6789 by default and the client connects using a binary proprietary protocol. The client's connect packet looks similar to

 ValidDb2jdTokenFromTheClientSide DSN=toolsdb;UID=  username;  PWD=  password  en_GB s021023 

The binary information has been removed from the preceding text to make it more legible. As you can see the client sends the name of the database it wishes to connect to, the username and password, the language, and the client version ”s021023. If the client version does not exactly match the server version, the server will return an error. Of course, if the username or password is wrong, or the database doesn't exist, then an error is also returned. What's important to note here is that this information is not encrypted in any way. In other words, if this can be sniffed from the network wire, an attacker can gain access to the clear text password of an OS account. Although this is a problem, it's not the biggest problem. The JDBC Applet Server is vulnerable to a buffer overflow vulnerability in its connection protocol. The problem surfaces only when a first connect packet is sent with an overly long version number. On the server side this version information, if overly long, overwrites a null terminator. Consequently, when a second connect packet is sent with an overly long username, what should have been two strings is formed into one and the resulting string is too large to fit into a stack-based buffer. When this long string is copied to the buffer, the buffer is overflowed allowing the attacker to overwrite the saved return address stored on the stack. With the saved return address under the control of the attacker, he can redirect the process's flow of execution. By redirecting the flow of execution into the buffer, the attacker has the ability to run arbitrary code.

Note  

This overflow was discovered while researching for this book. The flaw was reported and IBM quickly fixed it. The fix is contained in Fixpak 7.

Because the JDBC Applet Server increases the attack surface of the host, it should be disabled if it's not in use. This will help to secure the DB2 installation.