Call: +44 (0)7759 277220 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: "New version of Fuzzor available"] [Next entry: "Interview with SearchSecurity about Slavik's new Fuzzor"]

Instrumentation - a god send for speed freaks - a god send for data thieves



I saw a nice post today by Chen Shapira via my Oracle blogs aggregator. The post by Chen is called "Psychology of Instrumentation" and whilst it is not a security post; this is an area I cover in my training class on "how to perform a security audit of an Oracle database". I want in my class to emphasise the non-flat world model of accessing data - in other words if your credit cards are stored in a table called CREDIT_CARD do not be simplistic in thinking the only way to read the credit cards is to perform a select statement against the CREDIT_CARD table. It is almost certainly not the only way.

So, I have to add something negative to Chens article - that just goes with the role of being a security person, being negative that is..:-).

Instrumentation is great, I have written in C, PL/SQL, Perl and many more languages over the years and the usual first peice of code i write is some sort of debug/trace/instrumentation interface so i like instrumentation - BUT - in the case of Oracle we do already have a huge amount of instrumentation, traces, data dumps, file dumps, redo dumps, header dumps, sql*net trace, logs, events, statspack, AWR, ASH.... This list simply goes on....

The downside is whilst this stuff is great for understanding how the system works and why it maybe slow often all of these methods of tracing or instrumenting can undo the good security work done. Imagine a case where we protect and harden access to our CREDIT_CARD table. We ensure only authorised users can select from the table; great we are secure. Imagine that most users have the ALTER SESSION system privilege and therefore they can dump data to trace files by running a trace on a process or program that they have access to run but perhaps can only see a very limited set of data via a screen (of course they would need to be able to read the trace file; in my experience this is often not a problem due to file system access, exposure of trace files through the applications (E-Business Suite is a good example), often DBA's may email trace files to people; imagine that we have secured some data in the table using VPD; this same method (trace) allows bypass of VPD by virtue of certain events allowing the dumping of predicates so that the "rules" applied can be determined, maybe the predicate function can be executed.... Imagine we allow users to set trace and the code does not use binds or it does use binds and setting extended trace is possible, again data can be read perhaps that should not be.

Whilst instrumentation is great we should be cautious and even suspicious and not let these mechansisms be used to get at the data.

[Thanks to Christopher Newman's email and Alex's comments for picking up my lax typing and editing issues - i have editied the post to say what I meant originally]

There has been 2 Comments posted on this article


February 6th, 2009 at 07:17 am

Alexander Kornbrust says:

Pete,

I have few questions to your post:

How do you dump the data block of the credit card table with alter session only?
How do you find the block where the credit card information is located?
How can you read the tracefile afterwards?

SQL> grant create session, alter session to eviluser identified by evil user;

SQL> conn eviluser/eviluser

SQL> ?

Regards

Alex



February 6th, 2009 at 09:18 am

Pete Finnigan says:

Hi Alex,

The mistake was the word "block" i meant just data. I wrote half the post before i went out and then half when i came back plus lots of phone interuptions and didnt read it properly, too busy! - it is no excuse though.

I meant that if you have the ability to create trace you can turn on trace when using an application and see more data, i also meant but didn't write that we can use event 10730 and see the vpd predicate. I was not suggesting that the user only had ALTER SESSION. The post is really intended to suggest the main idea that whilst instrumentation is great for tuning and problem solving it also leaves access to data and also potentially leaves the data sitting out side the database in logs or trace files.

cheers

Pete