They found that by sending certain packets of information to systems using SolidDB it is possible to trigger a non-recoverable error in the program and thus terminate related server processes, creating the potential for remote Denial of Service attacks. As a result, many other products that utilize SolidDB are also vulnerable to the same type of compromise.
IBM issued a SolidDB update that addresses the vulnerability (SolidDB/Universal Cache 6.3 Fix Pack 3) on Nov. 13, 2009. In a related announcement, HP issued a security advisory addressing a vulnerability in the database server core component of its OpenView Network Node Manager. CoreLabs researchers first discovered the involved HP NNM vulnerability and reported it to the vendor as well.
CoreLabs initially discovered the vulnerability in IBM SolidDB as part of its ongoing research efforts into security issues found in other products that utilize the in-memory caching software, namely HP OpenView NNM. The DoS flaw specifically affects IBM SolidDB Server versions 188.8.131.52 and 184.108.40.206. Other versions may also be vulnerable but were not tested by Core.
The IBM SolidDB product family consists of relational, in-memory database technology that promises to accelerate the speed and performance of database applications via the use of SQL coding.
In addition to use in third party technologies, the in-memory database is also leveraged as core component of IBM's SolidDB Universal Cache, a performance improvement application for relational databases such as IBM DB2, Microsoft SQL Server, Oracle and Informix products.
CoreLabs researchers discovered a remotely exploitable vulnerability in the database server core component of SolidDB. Exploitation of the bug does not require authentication and will lead to a remotely triggered denial-of-service of the database service.
Specifically, IBM SolidDB server listens and accepts remote connections on port 2315/tcp. The service is implemented by 'solid.exe' which is started automatically on boot of the program. For certain transactions, upon receiving a packet from the network the service will attempt to determine and display an error code string based on a error code number specified in the packet.
By sending a specially crafted packet with an invalid error code number it is possible to trigger an exception that forces abnormal termination of the involved SolidDB service.
Based on CoreLabs’ research it appears unlikely that the vulnerability could be exploited for anything other than remote DoS attacks.