Instructions on how to exploit an unpatched Oracle Database Server vulnerability in order to intercept the information exchanged between clients and databases were published by a security researcher who erroneously thought that the company had patched the flaw.
Oracle’s April 2012 Critical Patch Update (CPU) advisory, published on 17 April, credited security researcher Joxean Koret for a vulnerability he reported through cyber-intelligence firm iSIGHT Partners.
In an e-mail sent to the Full Disclosure mailing list on 18 April, Koret revealed that the vulnerability is located in the Oracle TNS Listener, a component that routes connections from clients to Oracle database servers depending on which database they are trying to reach.
TNS Listener has a default feature, introduced in 1999, that allows clients to register a database service or database instance remotely without authentication, Koret said.
The client sends a remote registration request to the TNS Listener and defines a new service name, its IP address, the database instances under it, and other settings. The TNS Listener then starts routing all client requests that include that service name or database instance.
However, TNS Listener also allows the remote registration of a database instance or service name that is already registered, Koret said. "The TNS listener will consider this newer registered instance name a cluster instance (Oracle RAC, Real Application Clusters) or a fail over instance (Oracle Fail over)," he said.
In this case, the TNS Listener performs load balancing between the two instances by sending the first client to the most recently registered one and the second client to the original one. This allows a local attacker to route between 50 and 75% of clients to a database server that he controls, Koret said.
The attacker can then use the TNS Listener on the server he controls to route the client requests back to the legitimate database instance, effectively establishing a TNS proxy that allows him to intercept all data exchanged between clients and the targeted database.
However, this is not the only attack scenario that this vulnerability allows. By being in a man-in-the-middle situation, the attacker can also inject rogue commands in the SQL queries sent by clients or completely hijack their sessions to execute arbitrary queries, Koret said.
The researcher mentioned that he didn’t test whether Oracle’s patch for this vulnerability, that he believed to be included in the April 2012 CPU, actually addressed all attack vectors.
However, after a few follow-up e-mails with Oracle, he realised that the company hadn’t actually patched the flaw for currently supported versions of the database server, but instead addressed it in a yet-to-be-released version.
Oracle decided to patch the flaw in an upcoming version, but not in existing ones, because the fix is very complex and backporting it could lead to other problems, Koret said in a second e-mail sent to the Full Disclosure mailing list on Thursday. Oracle did not immediately return a request for comment.
The decision to publicly disclose details about the vulnerability, including instructions on how to exploit it, was taken after confirming with Oracle that the vulnerability had been addressed, Koret said. However, he added that the company told him it "was fixed in future releases of the product."
The researcher believes that receiving credits in Oracle’s April 2012 CPU advisory for a vulnerability that wasn’t fixed in the actual update was misleading and said that the company should stop doing this in the future.
However, Koret was credited in the "Security-In-Depth Contributors" section of Oracle’s advisory which states that: "People are recognised for Security-In-Depth contributions if they provide information, observations or suggestions pertaining to security vulnerability issues that result in significant modification of Oracle code or documentation in future releases, but are not of such a critical nature that they are distributed in Critical Patch Updates."
Koret described several workarounds to mitigate the vulnerability without deploying a patch in his 18 April advisory. One was to disable the TNS Listener remote registration feature by setting "dynamic_registration = off" in the in the listener.ora configuration file.
However, this is not feasible for configurations that actually require the feature, like Oracle RAC clusters. "To apply this workaround with Oracle RAC environments one needs to implement load balancing at the client side, changing all the client’s tnsnames.ora configuration file to add the complete list of Oracle RAC nodes," Koret said.
IDG News Service
Ltd
