Researcher confused over handling of Oracle database bug

Share this article:

A security researcher who reported a vulnerability in the popular Oracle database product said Thursday that his discovery was never patched and remains wide open to attack.

The curious case -- detailed here on the Full Disclosure mailing list -- involves a man-in-the-middle flaw that engineer Joxean Koret reported four years ago to bug-bounty program iSight Partners, which in turn, shared the details with Oracle per its reward program specifications.

In last week's quarterly security update, the database giant finally fixed the bug. Or at least that's what Koret thought, considering he was given credit by Oracle in its "Security-In-Depth" program.

Koret said he casually followed up with Oracle to learn which vulnerability he was being credited for -- and then, thinking the coast was clear, published a proof-of-concept for the bug, which affects database versions 8i to 11g Release 2, the most current iteration.

But he sent another email to Oracle after being confused by some language in the first exchange. As it turned out, the defect was only repaired in future versions of the database.

The flaw carries a perfect CVSS score of 10, making it the most severe issue possible, Koret told SCMagazine.com on Thursday. Attackers can exploit it to "sniff any connection" made to the database without the need for credentials, and can also inject malicious commands.

"In short, whatever they want," he said, adding that he is not aware of any in-the-wild attacks underway.

An Oracle spokesman did not respond to a request for comment from SCMagazine.com. But Koret published what he said was an email exchange between him and a company representative, who told him that the vulnerability wasn't remediated in existing versions -- only in internal development versions -- because a patch is complex and may cause performance regressions for customers.

There may be another explanation. Oracle may 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."


Share this article:
You must be a registered member of SC Magazine to post a comment.

Sign up to our newsletters

TOP COMMENTS