A critical vulnerability in 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 said 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.
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 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."
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
Copyright © SC Magazine, US edition
Issue: 338 | May 2015
Access CRN's extensive online resources including; email bulletins, community discussions and unique online news.
Processing registration... Please wait.
This process can take up to a minute to complete.
A confirmation email has been sent to your email address - SUPPLIED GOES EMAIL HERE. Please click on the link in the email to verify your email address. You need to verify your email before you can log on to the CRN website or start posting comments on articles.
If you do not receive your confirmation email within the next few minutes, it may be because the email has been captured by a junk mail filter. Please ensure you add the domain '@crn.com.au' to your white-listed senders.