Oracle won?t patch four-year-old zero-day in TNS listener

Oracle has issued a safety bulletin this week, recommending customers consider workarounds to address an extended-standing zero-day vulnerability in nearly all versions of its database management system.

The four-year-old Oracle database vulnerability became a problem last week when the researcher who discovered the flaw issued details and proof-of-concept code to hold out a “TNS listener poison attack.” Joxean Koret, a safety researcher based in Spain, reported the vulnerability to Oracle in 2008. In accordance with Oracle's blog, last week Koret, “[had] mistakenly, assuming that the issue were backported in the course of the CPU… fully disclosed its details.”

The Transparent Network Substrate (TNS) Listener is a feature that routes the connections between a consumer and the server. In keeping with Koret's advisory (.pdf), an attacker using a person-in-the-middle technique could hijack legitimate established connections and route all the data being sent from the client to a remote server controlled by the attacker. Without authorization, the attacker could record the data or send simple commands to the server to add, drop or modify data.

“To inject commands, simply wait for the customer to send an SQL query/statement, replace the contents of the statement with our desired command and that's all,” Koret wrote in his blog and in a message on the Full Disclosure mailing list.

The vulnerability is present in Oracle database versions 10.2.0.3 to 11.2.0.3. The Oracle alert for CVE-2012-1675 also warns that “since Oracle Fusion Middleware, Oracle Enterprise Manager, Oracle E-Business Suite include the Oracle database component that is affected by this vulnerability, Oracle recommends that customers apply the solution for this vulnerability to the Oracle database component.”

Alex Rothacker, director of security research at TeamSHATTER, Application Security Inc.'s research team, said Koret was more patient than other researchers before disclosing his proof-of-concept code. A lack of clarity by Oracle on whether the bug was fixed lead to the disclosure, and Rothacker believes that Koret acted “in good faith.”

Oracle had not yet patched the bug and said it has no plans to, stating that “such backporting is very difficult or impossible because of the amount of code change required, or because the fix would create significant regressions…” The problem has been fixed within the main line of code, according to Rothacker, so new versions of the Oracle database will be secured against this vulnerability.

Rothacker suggests the real problem has nothing to do with the miscommunication that led to the attack code being released. The problem, he said, is that Oracle has known about this very serious vulnerability for four years and done nothing to fix it. “How many other problems do they know about that they haven't fixed?” he asked.

Oracle suggests workaround

As a workaround, the company suggests customers on single-node configurations refer to the My Oracle Support Note titled “Using Class of Secure Transport (COST) to Restrict Instance Registration” to limit registration to the local node and the IPC protocol through the COST (Class Of Secure Transport) feature in the listener. RAC (Real Application Cluster) and Exadata customers should refer to the Oracle Support Note titled “Using Class of Secure Transport (COST) to Restrict Instance Registration in Oracle RAC” to implement similar restrictions.

All previous restrictions for implementing COST restrictions in RAC environments have been updated to allow customers not previously licensed for Oracle Advanced Security to protect themselves against this type of attack. Oracle and Rothacker both suggest any company using an Oracle database check the alert and follow the steps to reconfigure the infobase and listener.