Security Advisory: DB2 DBMS – Critical Buffer Overrun Vulnerability


On May 05, 2006, IBM released fixpack 12 for its DB2 RDBMS package version 8. (see: ) This fixpack addresses, among other things a flaw in the implementation of its client-server network protocol. (see: ) By exploiting the flaw, any attacker with network access to the database server, can easily take the server down or even run arbitrary code on the server’s machine. It should be noted that no database credentials are required for successful exploitation of this vulnerability. In addition, this is a network level attack, thus it leaves no traces in the built-in auditing mechanisms of the database server. This is a major vulnerability. The two month delay between the problem’s discovery and the release of a fix highlights the risk of relying solely on the database vendor’s patches for an enterprise’s defense against database attacks.

The Vulnerabilities

In February of 2005, Imperva’s security research group, the Application Defense Center (ADC), discovered a severe vulnerability in the implementation of DB2 version 8 client-server protocol. The 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 containing objects that allow them to synchronize the characteristics of the session. This is done prior to authenticating the client to the database server. One of the objects sent from the client to server is called MGRLVLLS and it contains compatibility information about various protocol functions supported by the client.

As it turns out, sending a message with an overly long MGRLVLLS object from the client to the server invokes a buffer overrun condition in the server. As a result, the database server process crashes. It is possible to carefully craft the contents of the MGRLVLLS object in a manner that will allow its contents to be run.

The Problem of Relying on Database Patches

IBM was notified immediately of the flaw and ADC provided all necessary information for reconstructing the issue. In a matter of days, the vendor acknowledged the issue and its severity. However it took over two months for a patch to be released to address this critical vulnerability. During that time there was no recommended workaround for this undisclosed and unpatched vulnerability. While the complexity of modern database platforms may necessitate such delays they are not acceptable for companies who rely on databases to run their business. Databases hold the crown jewels of any organization and with the web connecting customers, partners, and remote employees to these databases they are more exposed than ever.

A More Logical Approach

What is needed is an alternative offering that provides database platform protection outside of the database platform itself. One that is focused on delivering fixes for newly discovered vulnerabilities in extremely short time-frames. There is an existing model for this approach. Anti-virus software became a vital part of any organization’s layered security because it was apparent that waiting for vendor patches was not acceptable when a new vulnerability is discovered. This idea can be applied to the database platform protection problem. In particular a new breed of database security gateways is becoming available from security vendors. These devices are installed in the line of traffic in front of the database server and scrutinize the messages going from clients to server, detecting possible attacks. Such products have the capability to provide protection against platform-level vulnerabilities in the timeframes of hours or days after a new vulnerability is discovered. Moreover, such security gateways are undetected and untouched by potential attackers and are oblivious to attacks that would render the database’s own security mechanisms useless.


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, for permission.