eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Security researchers have uncovered a critical client/server protocol flaw in IBMs DB2 database.
Impervas Application Defense Center reported on June 12 that it had discovered the vulnerability in DB2 Version 8. The flaw allows attackers with network access to the database server to bring the server down or to run arbitrary code.
In addition, due to the fact that this is a network-level flaw, attacks slip by DB2s built-in auditing mechanism.
When requested for comment on the flaw, IBM took the opportunity to thumb its nose at archrival Oracle, whose “Unbreakable” slogan and slow patch times have gotten it into sticky situations in the past few years.
“IBM realizes that it is unrealistic to claim that any database is unbreakable and that code—by its very nature—may contain some flaws,” IBM engineers relayed in a statement e-mailed by a spokesperson for the Armonk, N.Y., company.
“This is why the IBM development teams are continually working with various security entities throughout the industry to evaluate our code and detect any potential problems,” IBMs statement continued. “Our engineers then work to quickly address any problems with an immediate patch rather than leaving our customers exposed until the next scheduled Fixpack release.”
IBMs engineers were referring to security researchers complaints that known vulnerabilities in Oracles product set have gone unpatched for months. The most recent example of this was the April 2006 quarterly CPU (Critical Patch Update). Weeks after the database server vendor announced the release of that CPU, customers were still waiting for several important fixes.
Oracle blamed the most recent delay on ongoing patch quality testing, as it has done in the past. Oracle has shipped all its patches to fix the recent issues, said Alexander Kornbrust, founder and CEO of Red-Database-Security, in Neunkirchen, Germany. Oracle didnt respond to requests for comment on the late patches.
In May, Kornbrust told eWeek that the absence of the patches a full month after the scheduled release date pointed to a resource problem at the Redwood Shores, Calif., vendor.
“Its very normal for Oracle to release all the patches for all platforms, but this month its been extreme. This defeats the purpose of having a scheduled release cycle,” Kornbrust said at the time. Kornbrust, who regularly reports database and server flaws to Oracle, said the purpose of implementing a rigid patch release cycle is to help database administrators prepare for patch testing and deployment.
“If these DBAs now have to wait weeks and months for patches, whats the use of having an Oracle patch day?” Kornbrust asked.
In contrast, IBM is proud of the fact that it released a fixpack for its recently discovered DB2 flaw on May 12. IBMs APAR (Authorized Program Analysis Report) IY84096, which documents the flaw, is available along with the fixpack on IBMs site.
According to IBMs APAR, the flaw results in a buffer overflow after a bad connect request causes memory corruption and crash.
“A malicious CONNECT or ATTACH request sent to a DB2 server may cause a buffer overflow and instance crash, resulting in a denial of service,” the APAR reads.
Affected DB2 versions include DB2 on Unix, Linux and Windows (all versions and all platforms).
According to IBM, DB2 users can disable or restrict remote access to the database server to effect a temporary fix. Users should disable the DB2 TCP/IP listener if not required, IBM says in its APAR. This is done by setting SVCENAME to NULL in the database manager configuration or by using a firewall to restrict connections to the DB2 TCP/IP listener port. IBM also provides in its APAR the following instructions for a local fix: Disable or restrict remote access to the database server.