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 email 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 recognized 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 April 18 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.