Responsible disclosure!

David Litchfield of NGS Software recently gave a presentation at Black Hat DC 2010 entitled "Hacking Oracle11g". In this presentation he discloses a couple of vulnerabilities that allow an unprivileged database user to execute arbitrary commands on the database host. In Linux/Unix environments this mean running commands as the Oracle owner (normally "oracle") and on Windows environments as "Administrator". Subsequently this also means that the database itself is completely comprised, which David goes on to demonstrate.

Now I'm not here to repeat the details of the vulnerabilities or exploits, you can easily find these on other Oracle Security blogs or via a quick Google for DBMS_JVM_EXP_PERMS.IMPORT_JVM_PERMS. Or even go to the Black Hat website yourself and download the video of David's presentation.

The vulnerabilities are very interesting and not your usual SQL inject or buffer overflow problems. No no, these are inherent design flaws where someone hasn't properly considered the correct default privileges for powerful internal packages.

It is a bit lapse of Oracle, however my big concern is that David says that he informed Oracle of these problems last year and that Oracle haven't released a fix yet. But then goes and demonstrates them at a major conference.

Now David admits that he and Oracle have been "Bashing heads for some time." Which is an understatement, as this is not the first time he's released details of vulnerabilities before a fix is available.

I am not sure if David intented to make this public. During his presentation he does say "I reported this back to Oracle last year and was hoping that it was going to be patched in the [last] CPU but since we're a limited audience I decided to go ahead with the talk. There is going to be a White Paper that will be released to the general public at a much later date when Oracle have actually released fixes for this. But until such time the actual paper will not be made public. So you're getting a sneak preview so... shhhhh!"

Whether he knew that the video and audio of his presentation would be made available for download on the Black Hat site we don't really know.

The net result is that now the vulnerabilities are public, Oracle hates him even more than they did before and millions of Oracle customers are now panicking (or should be).

I appreciate that he's spent many hours of research to find these problems and quiet rightly wants credit for his hard work. And that it must be frustrating waiting for vendors to investigate, fix and test reported problems. I'm sure it seems like Oracle have been moving at a glacial pace, but we don't know what the Oracle Security Team has on their plate or what other issues the resolution causes. At the end of the day we all want a fix that has been fully tested... don’t we?

Of course this raises the age old issue of “What is responsible disclosure?” Some say that it’s responsible to disclose vulnerability issues following a certain timeframe after informing the vendor (e.g. a year, a month or a week). Some say it’s ok to disclose vulnerabilities to a “Select few” (e.g. a government working group, some paying customers or a trust worthy looking bloke in the bar). But really, disclosing vulnerability details to anyone other than the vendor before a solution is released is just bragging rights. It serves no purposes, other than to massage the egos of researchers and expose countless sites to attack.

And before you say “That it forces vendors to take bugs seriously and fix them as a priority”, I can assure you that Oracle’s Security Team do take these issues seriously, but they also take product stability seriously. Not to mention all the other stuff they have to deal with. I know for a fact that only a small number of issues reported to them actually turn out to be valid, but they have to treat each one as a potential serious bug and spend vast amounts of time trying to reproduce the problem. They also have far more issues reported via internal sources than from external researchers. Although I do concede they may have been a little overworked since Larry went on a spending spree.

Anyway what’s done is done, and you can’t take back what’s been said. So if you haven’t already, I strongly recommend you revoke public access on the following packages:

· DBMS_JAVA

· DBMS_JAVA_TEST

· DBMS_JVM_EXP_PERMS