Pete Finnigan's Oracle Security Forum


    
      
        Pete Finnigan's Oracle Security Forum
        (http://www.petefinnigan.com/forum/yabb/YaBB.cgi)
      

        Oracle Security >> Oracle Security >> Remove tkprof?
        
(Message started by: Pete Finnigan on Jun 15^th, 2007, 7:34pm)

Title: Remove tkprof?
Post by Pete Finnigan on Jun 15^th, 2007, 7:34pm

The security check list at http://www.sans.org/score/oraclechecklist.php recommends "Remove tkprof from production db" stating the threat "tkprof is used to read trace files and should be used off the production server"

I don't understand this. Tkprof just formats the SQL trace files. How can this be a security threat?

Title: Re: Remove tkprof?
Post by Pete Finnigan on Jun 16^th, 2007, 7:45pm

hi Mike,

Because it can be run remotey for someone who creates trace files. Also it formats trace into a more readable form and allows "structure" of an application to be made available. BUT, my reason to add it to the list was because it encourages on-server maintenance and ad-hoc work. This tends to (in my experience from doing a lot of security audits) leave scripts, trace and much more lying around often with passwords in them. It also often encourages use of the oracle software owner account for ad-hoc maintenance.

cheers

Pete

Title: Re: Remove tkprof?
Post by Pete Finnigan on Jun 18^th, 2007, 12:57am

"Also it formats trace into a more readable form and allows "structure" of an application to be made available."

As a counter argument, the raw trace file is more likely to contain confidential data (eg customer details in bind variables) and, since it has the order of SQL statement executions, is more revealing of how the application works.

As such if raw trace files are being copied (perhaps by FTP, which isn't secure), possibly to a less secure location (eg DBA's PC) for tkprof, then there is an equal or greater risk.

Title: Re: Remove tkprof?
Post by Pete Finnigan on Jun 18^th, 2007, 6:26pm

Hi Pete,

It seems like this should be more of a best practice for handling the trace files rather than removing the formatting utility (tkprof). Something like:

1) Ensure trace files are not publicly readable (i.e. _TRACE_FILES_PUBLIC is not set).
2) When using event 10046, remove the raw trace files and tkprof formatted output when done.

I do agree on your statement about ad-hoc work on production but if you are working on a performance problem using event 10046 then of course you have to do this on production.

Since the raw trace does have as much information (and more as "gameyers" points out) as the formatted output, it seems best to go ahead and run the tkprof on the production machine, do the analysis and then remove both the trace files and formatted output.

Tkprof itself doesn't seem any more dangerous than any other utility to look at the raw trace files like vi, grep, etc.

Regards,
Mike