Pete Finnigan's Oracle Security Forum


    
      
        Pete Finnigan's Oracle Security Forum
        (http://www.petefinnigan.com/forum/yabb/YaBB.cgi)
      

        Oracle Security >> Oracle Security >> Many ways to becom DBA
        
(Message started by: Pete Finnigan on Nov 23^rd, 2005, 12:52am)

Title: Many ways to becom DBA
Post by Pete Finnigan on Nov 23^rd, 2005, 12:52am

Hello Pete,

I have read with interest your above paper.

You provide two techniques for Scott/tiger to become DBA. The first using validate_stmt and the second usint authid current_user + get_dll.

Are you saying that these types of hacks are potential hacks, or real? If they are real, have they been patched in Oracle? Are there ways prevent them through configuration? Or are you saying these have been patched but there are many more like them?

Otherwise what you are saying is that Oracle does not, in practice, have meaningful role based security.

Thanks,

Anthony

Title: Re: Many ways to becom DBA
Post by Pete Finnigan on Nov 24^th, 2005, 6:50pm

Hi Anthony,

Thanks for your comments. Yes both types of attack are real and documented elsewhere. I was careful to not post new exploits, henice I used existing ones. They have both been fixed. The DRILOAD bug is widely published and is in fact the bug that has not been correctly fixed in CPU October (David can jump in here, as he found the issue!).

There are literally hundres more of these types of bugs. Alex has just reported some 250+ of them to Oracle, there are others reported by other researchers as well. There are also quite a lot of others like these that have been fixed and patched.

It is not an issue of role based security but vulnerabilities.

cheers

Pete

Title: Re: Many ways to becom DBA
Post by Pete Finnigan on Nov 24^th, 2005, 8:56pm

Hi Anthony

the ctxsys.validate_stmt bug is old. I found and reported this bug nearly 2 years ago ( jan-2004).

Oracle fixed this bug 7 months later with alert 68.

More details here
oracle_sql_injection_via_ctxsys_driload.html

Even in a fully patched Oracle 10.1.0.4 (with CPU October) there are different ways available for a user like scott to become DBA.

Regards

Alexander Kornbrust

---

Title: Re: Many ways to becom DBA
Post by Pete Finnigan on Nov 24^th, 2005, 9:18pm

I think I should clarify that Alex found the driload bug but David found that it was still vulnerable in subsequent CPU's for certain operating systems. Basically he found that the fixed package was not installed correctly. If you follow some of the posts in my blog and some of the news articles that are referenced you can research some of the background to this issue.

cheers

Pete

Title: Re: Many ways to becom DBA
Post by Pete Finnigan on Nov 24^th, 2005, 11:58pm

Thanks for the clarification. It is obviously a complex API that has not been thrashed by undergraduate students!

I suppose that Oralce security largely depends on the database being behind the firewall and behind an application. And warehouses have limited data and a small number of users generally can access all of the data.

It makes techniques such as TDE and Oracle Vault less appealing. You really want to encrypt sensitive data before it gets into the database.

But I'm glad to here that at least your published holes have been (belatedly) plugged.

Thanks,

Anthony

Title: Re: Many ways to becom DBA
Post by Pete Finnigan on Nov 25^th, 2005, 8:13am

on 11/24/05 at 20:56:10, kornbrust wrote:

...
...
Even in a fully patched Oracle 10.1.0.4 (with CPU October) there are different ways available for a user like scott to become DBA.

Regards

Alexander Kornbrust

---

Alex, from a security point of view which Oracle version is better protected against simple accounts like Scott becoming DBA? Oracle 10 release 2? or perhaps good old 7.3.4?
Or are the problems you mention (users becoming DBA through sql injection, buffer overflow) fundamental problems deep in the Oracle kernel?

Ivan

Title: Re: Many ways to becom DBA
Post by Pete Finnigan on Nov 25^th, 2005, 8:46am

Ivan

Using Oracle 10g Release 2 is a good decision from the security perspective. Not 100% secure but not easy to hack.

At the moment most approaches to become DBA are SQL Injection bugs in internal Oracle Packages (like ctxsys.driload or dbms_metadata). Oracle fixed (most of?) these problems in 10gR2.

But even in 10g R2 it is possible to escalate privileges via Oracle programs like the import-utility or htmldb.

To harden an old database (< 10.2.x) you should do at least the following

* Sanitize the connect role (just create session and alter session)
* revoke public privileges from utl_*, dbms_lob, dbms_advisor
* Use the least privilege principle (be careful with the resource role)
* apply the latest Oracle CPU
* set the tns listener password
* change accounts with default/weak passwords

Regards

Alex

Title: Re: Many ways to becom DBA
Post by Pete Finnigan on Nov 25^th, 2005, 9:28am

on 11/25/05 at 08:46:19, kornbrust wrote:

Ivan

Using Oracle 10g Release 2 is a good decision from the security perspective. Not 100% secure but not easy to hack.

To harden an old database (< 10.2.x) you should do at least the following

* Sanitize the connect role (just create session and alter session)
* revoke public privileges from utl_*, dbms_lob, dbms_advisor
* Use the least privilege principle (be careful with the resource role)
* apply the latest Oracle CPU
* set the tns listener password
* change accounts with default/weak passwords

Regards

Alex

Alex,

Thank you for responding. I use 10G release 2 at the moment and like very much its new security features.
I've never used the connect and resource role in my instances. I've allways created an own role, application_user, with only create session. And for schema owner an application_owner role with some create <thing> privs.
Yesterday Pete talked about the DOD document in his blog and also about the Oracle security checklist. This two documents are indeed very good and useful and if we add Oracle's Defense-In-Depth Security, Oracle's principle of least privilege, the CIS benchmark, your advices and white papers found on your web-site, Pete's papers/advices, David Litchfield (NGSSoftware) papers/advices, Argeniss papers, etc people have very good material to understand Oracle security and convert pontential security crises into challanges and device an appropiate defence for their Oracle databases.
But there is allways a last frontier: defeat politics inside an organisation, defeat lack of interest in Oracle security.
Many people think that Oracle security is a synonym of OS/Network security: just throw a firewall into the equeation and you are ready!
So management is not allways willing to put extra effort (=money) in securing the database.
Oracle databases are more and more communicating with other databases outside the own organisation. Sometime directly, sometime indirectly through (eg) web-services. So it's not enough to just protect your own database but you must be able to trust some elses database. Therefore people have to speak the same security language. Ergo: we need an Oracle Security Standard!

Ivan