Pete Finnigan's Oracle Security Weblog

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!