Call: +44 (0)1904 557620 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.

[Previous entry: "UKOUG Oracle Data Security Day presentation slides available"] [Next entry: "More oradebug"]


Laszlo has published his slides from Hacktivity in Budapest last weekend where he shows how the Oracle undocumented oradebug command can be used to exploit the database; covering turning off authentication, turning off audit and more. His slides are here. As usual Laszlo's research is excellent. The use of oradebug as a hacker tool is valid but you must be SYSDBA first to be able to use it; this is a sort of oxymoron. It is afterall a debugger interface to the Oracle Engine; any debugger is dangerous as often they include commands to modify running processes; in this case examples are show to modify memory and turn off audit for instance but as such it should be available to the most powerful user only and it is.

There are arguments that there are ways to escalate your privileges to SYSDBA but I doint accept these particular arguments as an issue with oradebug itself; they are of course an issue with whatever escalation technique you use to become SYSDBA not with oradebug. To protect against oradebug you must stop people becoming SYSDBA but that is a seperate task; but that is only part of the story. The valid risk is therefore about people who are authorised to connect as SYSDBA who may then use oradebug to do something naughty such as turn off audit and avoid any existing logging or audit of audit trails. They can of course turn audit off anyway without oradebug but it would be hoped that normal mechanisms are audited and that "turn off" at least would be captured.

The real danger with oradebug is that audit (in this example) can be turned off and its not audited. Therefore there is a risk. The only way to detect this would seem to be to watch trace files and look for oradebug commands but these trace files can be deleted by an attacker or DBA anyway. A network based solution to sniff for oradebug commands will work but not if oradebug is used from a local connection so it is flawed. SYSDBA audit from audit_sys_operations doesnt capture oradebug commands and system triggers do not work for SYSDBA, FGA also will not capture its use, the oradebug command is also not visible in the SGA. It is also not possible to turn oradebug off unless Oracle can provide a supported way to unlink it but i suspect even this could be bypassed if the protocol of the oradebug messages is simulated; based on the assumption that the actual debug hooks cannot be turned off from the server.One method to stop its use would be to "hook" the debugger functions and return without debugging but this would not be supported and unless its done in the server would not be of use.

I suspect Oracle may not see this as a big issue as you need to be SYSDBA but i think the main issue is that its virtually undetectable in its use and genuine SYSDBA users can do naughty things with oradebug. If there was a simpler way to audit oradebug use then yes I would agree its less of an issue but there doesn't seem to be one.

Laszlo has shown various uses for oradebug but what about the command "oradebug event immediate crash" - should be useful for an attacker to simply take down shadow processes or even system processes. Hacking is not always about stealing or escalation but sometimes about damage.

As always, great work from Laszlo!

There has been 2 Comments posted on this article

September 21st, 2011 at 01:55 pm

Pete Finnigan says:


another problem is the fact you can get the offset for oradebug from the database. The following query (something I found when I saw Laszo's research) allows to get the offset to disable auditing and syauditing:

select fsv.ksmfsnam, sga.* from x$ksmfsv fsv, x$ksmmem sga where sga.addr=fsv.ksmfsadr and fsv.ksmfsnam='kzaflg_';

What do you think about the implications for Audit Vault and Database Vault?

According to Oracle AuditVault protects against privileged users.

Audit Fault FAQ: ...Oracle Audit Vault provides powerful built-in reports to monitor a wide range of activity including privileged user activity ...

If you switch of auditing the audit vault agent does not get audit information. This is similar for Oracle database vault, just switch off the authentication and a sysdba user can connect as any user (without DB Vault protection)

September 21st, 2011 at 03:30 pm

Pete Finnigan says:


I have been aware of the query into the fixed area of the SGA since i bought Steves book in 1999/2000; but you can dump the variable value with oradebug itself without needing a select on x$ksmfsv:

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

The above of course works and stopped SYSDBA audit in my database.

The issue is not just limited to audit as other variables can also be turned on/off or set to values in the foxed parts of the (SUP)GA

I agree its bad for audit vault as its too easy to disable the SYSDBA audit as thats what its supposed to collect. But Oracle will argue that the use of Database Vault should protect against privileged access to the database anyway. The whole thing comes down to controlling who connects as SYSDBA. At the end of the day as you point out DV can just be disabled allowing access. A mechanism needs to be created to disable oradebug; it is probably rarely only needed for hardcore debugging / hang analysis / crash etc