Security Advisory: DB2 RDBMS – Critical Denial of Service Vulnerability in Database Communication Protocol
On August 14, 2006, IBM released FixPak 13 for its DB2 RDBMS package version 8. This FixPak addresses, among other things, a flaw in the implementation of its client-server database network protocol.
[See: The line starting with IY87211 on the webpage ftp://ftp.software.ibm.com/ps/products/db2/fixes/english-us/aparlist/db2_v82/APARLIST.TXT]
By exploiting the flaw, an attacker with basic access credentials to the database server can take down the server. The attack is done at the database communication protocol level, and thus it leaves no traces in the built-in auditing mechanisms of the database server.
This vulnerability is an example of the growing number of major security vulnerabilities that are being identified in the database communication protocols of all database vendors. In this case, there was a seven month delay between the discovery of the problem and the release of a fix. Given the long lead-time between discovery and patch, there is a clear need for a database security solution that validates database communication protocols, similar to the way Web application firewalls validate HTTP and HTTPS traffic and the way network firewalls validate TCP/IP protocols.
In January 2006, Imperva’s security research group, the Application Defense Center (ADC), discovered a severe vulnerability in the implementation of DB2 version 8 client-server protocol. This discovery was the result of the ADC’s extensive research into the implementation of database access protocols.
DB2 uses a network protocol called DRDA to exchange information and commands between clients and servers. This is a complex protocol comprising many types of objects conveyed between participating parties.
During communications setup, the client and the server exchange a number of messages with respect to the client’s identity and the requested database’s identity. If some allegedly “optional” fields are omitted from those messages, a client session is established but sending any command on this session causes a termination of the database’s main process, resulting in a denial of service.
For instance, if the field for the name of a specific database within a server is omitted, then the act of connecting to that server creates some kind of race condition within the server, resulting in a crash.
Database Communication Protocol Vulnerabilities on the Rise
The vulnerability described above is one of two security related fixes included in the DB2 FixPak. Both fixes relate to database communication protocol level vulnerabilities. In the previous FixPak for DB2, two of the five security related fixes are database communication protocol level vulnerabilities, one of which was discovered and reported by Imperva’s ADC.
As stated earlier, the rise in database communication protocol level vulnerabilities is not specific to IBM’s DB2. Fifty percent of the vulnerabilities fixed in the latest quarterly patch from Oracle are also database communication protocol level vulnerabilities.
Why the Trend Will Continue
All commercial and public domain database servers use a proprietary network protocol (usually riding above various transport layer protocols such as TCP and Named Pipes) to communicate commands and data between clients and servers. The database communication protocols are barely documented and mostly obscure. They also carry along many years of backwards compatibility (at least 5 years in IBM’s case, and at least 15 years with Oracle).
Traditionally, the database vendors produced the client software (mainly in the form of ODBC or JDBC drivers, as well as low level APIs). Therefore, the implementation of the protocol was only validated against the behavior of those legitimate, well behaved clients.
With the rise of network based database security solutions, researchers started looking into these database communication protocols and began to find vulnerabilities. As more researchers examine these protocols, more vulnerabilities will be discovered. While there has been an up tick in this trend throughout 2006, it is expected to grow tremendously in 2007 and 2008, as better research tools are developed and made available. It should be noted that such trends among researchers usually follow similar trends among sophisticated hackers.
One of the most interesting things about database communication protocol violations is that they operate at a lower level of the network protocol stack and yet affect database data rather than the operating system files.
The Challenge: Detecting Database Communication Protocol Violations
In order to detect database communication protocol violations, a security solution must be able to monitor and audit the database communication protocol layer in the protocol stack. This is currently beyond the capabilities of built-in database security and traditional security solutions.
Intrusion protection solutions do not extract enough information about these protocols to enable detection of these vulnerabilities. Given the lack of available documentation for the protocols and the variable nature of the vulnerabilities, IPS can’t cover them simply by using a regular expression or “signature.”
Network firewalls are bound to let database communication protocol attacks through since they ride over the legitimate database service ports.
The database server itself is completely oblivious because database protocol attacks occur below the layers that are covered by built-in audit mechanisms. Moreover, once a specific vulnerability is discovered, there is no workaround for protecting servers until a vendor patch is issued and installed.
Surprisingly, even most of the newest database activity monitoring and database security solutions disregard database communication protocol violations and are unable to detect them as attacks or keep an audit trail of them.
The Need for Full Database Activity Monitoring
As this new breed of database communication protocol attacks proliferate, it becomes increasingly urgent for organizations to boost their defense mechanisms. A delay in doing so exposes the enterprise’s database servers to severe risks. An analysis of this year’s database protocol vulnerabilities shows that most of them were introduced into the products years ago.
The only way to effectively protect a database sever against this type of attack is to deploy an independent security solution that can fully monitor and analyze the proprietary database communication protocols used by vendors and discern the malicious behavior from legitimate client software traffic.
Enterprises serious about data security should insist that their database security solutions provide this validation of the database communication protocols such that database activity that violates protocol standards raises immediate alerts to the security staff and is noted in audit logs. Just as most enterprises have Web application firewalls to validate HTTP and HTTPS traffic and network firewalls to validate TCP/IP protocols, it is reasonable to expect similar real-time monitoring of database communication protocols.
The information within this advisory is subject to change without notice. Use of this information constitutes acceptance for use in an AS IS condition. Any use of this information is at the user’s own risk. There are no warranties, implied or expressed, with regard to this information. In no event shall the author be liable for any direct or indirect damages whatsoever arising out of or in connection with the use or spread of this information.
Redistribution of this alert electronically is allowed as long as it is not edited in any way. To reprint this alert, in whole or in part, in any medium other than electronic medium, firstname.lastname@example.org for permission.