A lot has been written in the last week about the Oracle TNS Listener Poison Attack (CVE-2012-1675). Not everything that has been published is correct. I have spent a great deal of time investigating the topic and I want to share my views on the issue.
On April 18th, the security researcher Joxean Koret published the following advisory on the full disclosure mailing list. http://seclists.org/fulldisclosure/2012/Apr/204 . Assuming it was fixed in the April 2012 CPU, he discusses a vulnerability that he discovered in the Oracle TNS Listener in 2008, including proof of concept code. Koret reported the vulnerability to Oracle through iSightPartners.
A few days later on April 26, he again posted to full disclosure, saying the vulnerability is in reality a 0-day, and no patch is currently available. http://seclists.org/fulldisclosure/2012/Apr/343
On April 30th, Oracle released a Security Alert for this vulnerability, including detailed instructions on how to secure the Listener and protect it from attacks exploiting the vulnerability. http://www.oracle.com/technetwork/topics/security/alert-cve-2012-1675-1608180.html
So, to sum it up:
- The vulnerability was discovered and reported to Oracle in 2008 (4 years ago)
- Koret was credited as a Security in Depth contributor in the Oracle Critical Patch Update Advisory – April 2012
- A full advisory, describing the vulnerability and exploit, including proof of concept code is publicly available
- The April 2012 CPU does not contain a fix for the vulnerability
- Oracle’s Security Alert describes a workaround
- To this point Oracle has not released a patch for the vulnerability
- Every Oracle installation that has not applied the workaround, or had been previously configured securely is vulnerable to an attack by a remote unauthenticated attacker
What everybody should know about the vulnerability:
The vulnerability allows an attacker to intercept traffic between the client and the Oracle database. it’s a classic ‘man in the middle’ attack. The attacker can now read all of the data that is exchanged between the client and the server. The attacker can also hijack the connection and inject arbitrary commands or queries and execute them with the privileges of the authenticated user. In short if the attacker intercepts a DBA connection, it is “game over” and the attacker “owns” the database. All current versions of the Oracle Database are vulnerable to the exploit and it is assumed that versions dating as far back as Oracle 8i are also vulnerable. A public exploit is available. As a vulnerability that gives an attacker full control over the database server, this warrants the highest possible CVSS score of 10.
How to protect an Oracle installation from this exploit:
Luckily, some workarounds that change the listener configuration to only accept secure transports are available. To accomplish this, the COST parameter “SECURE_LISTENER_listener_name” needs to be configured according to the details listed in the Oracle Metalink (login required) articles https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1453883.1 for non RAC systems, or https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1340831.1 for RAC systems. In order to keep using TCP as a transport, a patch for bug: 12880299 must also be deployed and for RAC systems, the workaround requires the use of some features that are part of the Oracle Advanced Security – a premium add on. Fortunately, Oracle has changed their licensing to allow the use of the require Advanced Security features necessary to implement the workaround at no charge..
Our recommendation is for all deployments to apply the workaround ASAP. This is especially important if the Oracle Listener and/or the Database are not on dedicated network segments.
Why did this all blow up like this?
Researchers discover vulnerabilities all the time. Software vendors fix them and life goes on. In general, this process has become so smooth that end users barely realize their OS, PDF reader, etc. have been updated.. All major software vendors release patches on a regular basis. Microsoft has Patch Tuesday. Oracle has the quarterly Critical Patch Update (CPU.)
So….what happened that created all the confusion, that led to a responsible disclosure researcher dropping a 0-day, and left Oracle to struggling to get out a workaround?
4.4 What is the Security-In-Depth program referenced in the Credit Section of the CPU Advisory?
Starting with the July 2008 Critical Patch Update, Oracle instituted a Security-In-Depth program to provide credit to people that provide information, observations or suggestions to Oracle pertaining to security vulnerability issues that result in significant modifications of Oracle code or documentation in future releases, but are not of such a critical nature that the modifications would be distributed in Critical Patch Updates.
According to his full-disclosure posting, Koret exchanged e-mails with Oracle after being credited in the CPU and received confirmation of the vulnerability for which he was credited and received confirmation that it was fixed. However, there appears to have been a misunderstanding and what Oracle really meant was that the vulnerability is only fixed in the main code line that will ship with the next major release.
Room for improvements:
There are some important lessons to be learned from this debacle and I sincerely hope that Oracle rethinks some of their security practices.
Oracle’s Critical Patch Update Advisories are notoriously brief when it comes to vulnerability information. I wish that for every vulnerability there was a section, or even better a separate security bulletin, including the following: credit statement, workaround information, mitigation factors, detection guidance, severity rating by affected product version and in addition to the CVSS score, an easy to understand severity rating.
Finally and most importantly I think it is ridiculous that Oracle took 4 years to fix such a critical and easy to exploit vulnerability.