Oracle Customers Left to Deal With Unpatched Vulnerability On Their Own

Oracle recently patched a flaw in the TNS Listener service as part of their update release in April. As it turns out, the TNS Poisoning patch didn’t apply to current versions of Oracle, leaving existing customers on their own. The TNS Poison bug has quite the history, researcher Joxean Koret reported the issue in 2008, but the flaw itself has likely existed since Oracle 8i. Four years later, Oracle fixed the problem for future releases, but when asked why current customers were not included, the database giant said that the complexity of the problem made backporting it nearly impossible.

“This fix is in a sensitive part of our code where regressions are a concern. Customers have requested that Oracle not include such security fixes into Critical Patch Updates that increases the chance of regressions,” Oracle told Koret.

Koret said that the vulnerability exists in all Oracle versions, so customers using 8i, 9i, 10g, and 11g (11g R2) are impacted. This makes the lack of a patch for current customers a serious problem. Once the vulnerability is exploited remotely, the attacker owns the data that will be exchanged between the database server and its client machines. There is also the issue of session hijacking, allowing the attacker to inject commands at will.

“There is no patch at all for this vulnerability and Oracle refuses to write a patch for ANY existing versions,” Koret wrote in comments to the Full Disclosure mailing list. “So, yes, ALL versions are vulnerable and will remain vulnerable. As I published many workarounds for this vulnerability I believe it’s better to make this information public so Oracle database’s customers can protect themselves.”

With that said, a complete workup of the vulnerability, including proof-of-concept examples, and Koret’s workarounds are here.

Additionally, Alex Rothacker, Director of Security Research at Application Security, Inc., offered up some advice on a workaround.

“Disable remote registration in the TNS Listener by setting ‘dynamic_registration = off’ in the listener.ora file, then restart the listener,” Rothacker suggests. “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.”

Another workaround, Rothacker said, is to use valid node checking, but warned that this action is not foolproof, noting that an attacker could still attack from a valid client.

The last workaround, Rothacker suggested, is for “clients that are using ‘Oracle Advanced Security’ to configure the system to require the use of SSL/TLS for connections.”

“Oracle’s reason for not fixing a vulnerability in a CPU is usually, because the fix is complicated and has dependencies or side effects that make applying the patch complicated, with a chance of causing disruptions in production environments,” Rothacker concluded.