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: "Listener security guide"] [Next entry: "An interesting SQL Injection paper"]

A tuning book and security?



I went to Leeds yesterday and bought the new book "Oracle wait interface: A practical guide to performance diagnostics and tuning" ISBN 0-07-222729 published by Oracle press and written by Richmond Shee, Kirtikumar Deshpande and K Gopalakrishnan. This is an excellent book, the bible on the Oracle wait interface. I like to buy most books on Oracle if they are well written or useful. Although as you know my main interest is Oracle security and security in general, I am also very interested in internals and undocumented features particularly of Oracle. This book covers some of these areas, hence my interest and also why I am writing about it here.

I have only skimmed the book so far but there are a lot of areas of interest to me. The first is the fact that direct SGA access is mentioned in the main text as a method of gathering system statistics and appendix D presents a good discussion on how this method works and how it can be used. The appendix culminates in a presentation of Kyle haileys C programs for accessing the SGA directly. I was already aware of this method as I have links to Kyles presentation on the same subject and also Miladin Modrakovic's paper Reading and storing data directly from the Oracle SGA. The second paper goes a little further with Kyles technique and shows how the results may be stored in another Oracle database. This technique should have applications for security researchers or hackers as well. There are a number of security based fixed tables that could be queried without accessing the database such as :



SQL> connect sys/a@sans as sysdba
Connected.
SQL> select name
2 from v$fixed_table
3 where name like '%KZ%';

NAME
------------------------------
X$KZDOS
X$KZSRO
X$KZSPR
X$KZSRT
X$KZRTPD
X$KZEMAEA
X$KZEMAIE

7 rows selected.



Only parts of the SGA are exposed through the X$ tables and again only parts of the X$ tables are exposed through the V$ views. Any Part of the allocated shared memory can potentially be sampled. This issue should prompt admin staff to prevent the installation of C compilers, execution of processes and access to shared memory other than by authorised staff.

The second area of interest to me from a security perspective in this book is the explanations of the oradebug tool. This again is covered in detail in one of the appendixes. The tool can be used to perform tracing and dumps. There are other ways of course to get trace and perform dumps. I actually wrote a short paper some time back that covered hopefully every way possible to set trace for your own session, others sessions and to also control the trace level. This paper can be found here. The area of trace files is of use to the security researcher. Trace files can reveal many details about the structure of applications, details of row level security implementations and in some cases passwords. Oracle enables people to perform many dumps of memory structures and files.

I used these techniques a few years ago to find passwords stored in the SGA from previous users sessions where someone had changed a password or added a user. This has only recently been fixed by Oracle. The paper describing this is available here. The final interesting thing from a security angle is that the event syntax is explained in detail. Events can be used to dump data from the database or to generate trace files, the results of either of these can be of use for security research.

This is an excellent book, remember to understand Oracle security you need to sometimes diversify from pure Oracle security sources.