(LiveHacking.Com) – The details of a zero day (0day) vulnerability in Oracle’s Database product have been published when the researcher, who originally found the problem, mistakenly believed that Oracle told him it had been fixed.
Almost two weeks ago Oracle released 88 security patches for a whole range of its products including Oracle Database 10g and 11g. Included in the security advisories published Joxean Koret was credited by Oracle for work submitted under the “Security-In-Depth” program. The relevant vulnerability was submitted to Oracle in 2008 and has taken Oracle four years to fix. Joxean contacted Oracle to be double sure that the vulnerability was fixed. The reply from Oracle said the vulnerability “was fixed in future releases of the product”. Since he was credited in the security advisories for the patch and Oracle said it was fixed, Joxean went ahead and published his own advisory explaining the vulnerability and a proof of concept.
However it turns out that Oracle didn’t fix the problem and in fact has no intention of fixing the problem in released versions of Oracle Database but will only release a fix in the next version of the product. The reason Oracle give for this is that “the fix is very complex and it is extremely risky to backport” and that there are concerns over regression. According to Joxean this means that “there is no patch at all for this vulnerability and Oracle refuses to write a patch for any existing versions, even for Oracle 11g R2. All versions are vulnerable and will remain vulnerable”.
The bug, which is now known as the TNS Poison Vulnerability, exists in all versions of Oracle Database since 1999 (Oracle 8i) and includes the latest one (Oracle 11g). The vulnerability is in the TNS Listener, which is responsible of for connection establishment. To exploit the vulnerability no privilege is needed, just network access to the TNS Listener.
Since Oracle 8i the database has supported a load balancing feature known as “remote registration” where a remote network listener is used to forward client requests to the actual database server responsible for handling requests for a given database. The problem is that using a man in the middle attack it is possible to trick the database into accepting commands from another rogue listener. This is possible because new requests to register a remote listener, that has already been registered with the database server, are seen as requests from a a cluster from a node after a fail over. The result is that the attacker has full access to the database.
Ironically, Joxean wrote concerning the patch from Oracle: “I didn’t test it myself and, to be honest, I’m very tired of the Oracle world so I did not test it myself. I would not be surprised if the patch doesn’t correctly/completely fix the vulnerability.” And how right he was!