Call: +44 (0)1904 557620 Call
Blog

Pete Finnigan's Oracle Security Weblog

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

[Previous entry: "IOUG/Oracle Software Security Assurance Team joint survery"] [Next entry: "0-day and the first security alert for 3 years from Oracle"]

Is Oracle Security getting better or in other words is Oracle Security good enough?

There was a post on my Oracle Security forum a couple of weeks ago that i found very interesting and worthy of a note on this blog. A poster raised a good question "Oracle Security is GOOD enough?" :

"Hi All,

please share your point of view about Oracle security at this moment.

In my opinion, I see less Oracle Security vulnerabilites in the newer Oracle version and less persons researching about Oracle Security (because Oracle is good now).

Oracle security getting better by time so no need to care about Oracle Security anymore, it's right ?"


This is an interesting question. Marcel-Jan added this response:

"You have to ask yourself: why do security leaks occur in Oracle databases:
- Because of passwords (on privileged accounts) that lack complexity and which are never changed.
- Because an application with SQL injection leaks connects to the database with an over-privileged account.
- Because the DBA thought it kinda easier to grant every object privilege to PUBLIC.
- Because the database runs an old version that is never updated (nor CPUs are applied), because you should never change a running system.
- etc. etc.
- or: because Oracle has a vulnerability in the dbms_obscurity package that allows to shutdown the database in certain occasions on certain platforms.

I'm betting that most organisations suffer more from problems like the first four (many variations exist). So Oracle isn't per definition secure after applying the latest patch. A lot depends on work done by the DBA and developers.

Try Project Lockdown (http://www.oracle.com/technology/pub/articles/project_lockdown/index.html) for a better start towards Oracle security."


The poster replied with:

"Agree with you that most vulnerabilities listed existing in the Production Database.

We can clasify the Oracle vuls by two type:
1. Oracle Software vuls: weak PL/SQL packages ... (Update lastest patch can solved this; less vuls in Oracle 10.2.0.3 and 11g, and will be near zero in the next release, hope this )

2. Misusing of Oracle Database: weak password, configurations, coding. (GOOD DBA or Developer can solved this partly, not all)

But in my expierience, Customer who using Oracle product just pay attention in Oracle Security when they see more vulnerabilites in Oracle Software, seem they really not care much about Misusing of Oracle Database.

One thing that cause me thinking that Oracle is GOOD enough at this time and future is not see more public vulns or frequently posted news in David, Alex or Pete blog during several months."


Then I had my go with the following:

"Nice post and answer by Marcel-Jan; I think that there are two answers to this point vpv. The first is that the database software itself is getting better with later versions in regards to vulnerabilities etc. Thats fine and is commendable for Oracle.

The second issue for me is that the CPU application doesnt fix security. In my opinion the CPU/Security patch and therefore bugs actually in the software is a smaller part of the overall security of the database, maybe 20% - 30% and at the end of the day we can either patch or not. If someone finds a bug there are enough vendors now in the Oracle security space that many people will know how to exploit the issues so applying CPU's is important.

The other 70% of security and in my experience where most people / customers of Oracle fall down is around the configuration, data leakage, weak passwords, no network security at the Oracle level, excessive privileges.... and much much more. This is compounded by the fact that most people do default installs and install too much increasing the attack surface.

I dont know if there is one root cause but the issue for me is lack of understanding of database security or often lack of effort at all in this area, so most people have badly configured and managed databases.

So whilst you are right and I agree the software is getting better its also getting bigger and open by default and most do not do anything to close off the configuration so the state of most databases is not secure at all.

Its a complex subject and you certainly cannot ignore Oracle security based on better product/less vulns or lack of blog posts.

I think the upsurge in a large number of vendors in this space such as Sentrigo hedgehog shows that there is a major interest in securing data. regulatory issues such as PCI DSS 1.1, SoX, HIPPA and more also underscore this.

I give clues in my sparce blog posts as to why I dont make many, i.e. I am employed heavily in securing databases, I know Alex is the same and I suspect David as well. I think the lack of blog posts doesnt signify better security; it just means we are busy.. "


I think that this is a very interesting question and a good discussion. My views as you can see above is that the database software itself is getting better, people (customers of Oracle) are starting to embrace the need to secure data in the database itself and there is starting to be a recognition that the products are complex and that most of the issues lie in the realms of configuration not with bugs. Of course Oracle could help us a lot by getting to the point of a "secure out of the box" product rather than the open by default product that caters more towards use and developers rather than security mongers like me.

The poster had an interesing conclusion, the fact that the product is getting better and the fact that known Oracle security bloggers post less should be a reason to ignore Oracle security because based on this its getting better. I hope that people take heed of this post and also do not take the same view as the poster otherwise we would have a data security problem. The conclusion would be (from this point of view) that if no one does research or blogs about the subject the database would be secure? - this unfortunately falls under the "ignorance is bliss" category.

What do other people think?, is Oracle security getting better? or is it good enough?

There has been 2 Comments posted on this article


July 28th, 2008 at 06:22 pm

Pete Finnigan says:

Getting better? Sure. Good enough? No. Pretty, pretty sure.



August 15th, 2008 at 03:27 pm

Pete Finnigan says:

Let me start by saying that Oracle security is improving. I would also like to add that implementation of Oracle feature to secure database is improving as well at a significantly higher rate.

Oracle had features like revoking privileges from public, securing user accounts / schemas (password change, expiration) and more, but if there features are not implemented we cannot blame Oracle for not providing basic security components. These kinds of settings have been available in Oracle for several years and it’s not new.

There are certain security features / tools they being introduced in recent Oracle releases, like ASO, Data / Audit vault. They do offer some advanced security options.

I would like to make a distinction security vulnerabilities carried by poor application design (e.g. SQL Injection) to Oracle (or any other database). If an application passes a poorly written SQL query, any database will process it. We cannot blame a database for executing that query and brining the desired output as asked by faulty query.

To summarize my opinion, Oracle security is improving. Having worked in Information Security / Risk for several years, most organization fail to define a security roadmap, and in this case a database security roadmap / plan and they tend to either use security controls those are not needed, or implement security controls in an unspecific order. Organizations try to address Audit findings in a reactive manner which defies the proactive approach of security.