A critical vulnerability Oracle's database product remains unpatched some four years after it was revealed, says the researcher who discovered it.
Oracle claimed to have patched the remote pre-authenticated vulnerability, dubbed TNS Poison, in April but security researcher Joxean Koret said the fix did not cover older versions.
In 2008, Koret reported the flaw to bug-bounty program iSight Partners which shared the details with Oracle per its reward program specifications. He later published a proof-of-concept for the bug that affected database versions 8i to 11g Release 2, the most current iteration.
Oracle acknowledged the bug in its quarterly security update this month and credited Koret for identifying it, in its "Security-In-Depth" program.
But an email exchange published by Koret indicated that Oracle had chosen not to patch the bug in existing versions of its database product because a patch may cause performance issues for customers.
Instead, Oracle addressed the vulnerability only in internal development versions, Koret said, noting that the company had not revealed which versions would receive the fix.
Koret told SC Magazine US that attackers could exploit TNS Poison to "sniff any connection" made to the database without the need for credentials, and inject malicious commands.
"In short, whatever they want," he said, adding that he was not aware of any in-the-wild attacks underway.
Oracle did not respond to a request for comment from SC Magazine.
The lack of a patch for older versions may indicate that Oracle does not consider the vulnerability as serious as Koret.
According to Oracle: "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."
Alex Rothacker, director of security research for Application Security Inc.'s TeamSHATTER, corroborated Koret's explanation of the threat, and said database administrators should consider workarounds in lieu of a permanent fix.
"Disable remote registration in the TNS Listener by setting ‘dynamic_registration = off' in the listener.ora file, then restart the listener," he said.
"However, if your installation is using this feature, you will need to make sure to now manually register all legitimate servers. This is also not a valid workaround for RAC (Real Application Clusters).
"Another workaround is to use valid node checking, but this is not foolproof, since an attacker could still attack from a valid client."
This article originally appeared at scmagazineus.com