Re: Fw: OT - Getting fired for database oops
Date: Tue, 26 May 2009 20:36:44 +1000
Message-ID: <4A1BC63C.1050406_at_iinet.net.au>
Andre van Winssen wrote,on my timestamp of 26/05/2009 3:58 PM:
> That’s the reason I bring it up. Oracle server processes, including TNS
> listener, can be used to write entries into this file, remotely, through
> database calls (using DIRECTORY, java stored procedures that are
> allowed to write to the os, UTL_FILE, UTL_TCP, FTP,..). No protection on
> OS level whatsoever will prevent this because these actions will be run
> in oracle security context and oracle server process owns the
> glogin.sql. Once glogin.sql on the server side is tampered with the
> first (sys)dba user on the server who starts up sqlplus will run the
> statements from glogin.sql without a problem.
I quite don't get this. If someone executes one of these things remotely, don't they have to be logged in anyway? Or are we saying it's possible to execute a UTL_FILE for example without being logged on? And hopefully duly authorized to run it?
>
> Part of the cure for this is to revoke unnecessary privileges from
> PUBLIC and follow CPU patch cycles to get rid of well known
> vulnerabilities. But auditing the glogin.sql is not a bad idea too.
When I was running a Linux net front-end shop a few years ago, one of the script checks we had was a log of the last date changed+size for critical files. Any difference from last time around and we quarantined the system. There are quite a few utility scripts for Linux to do this. Would that be adequate?
-- Cheers Nuno Souto in sunny Sydney, Australia dbvision_at_iinet.net.au -- http://www.freelists.org/webpage/oracle-lReceived on Tue May 26 2009 - 05:36:44 CDT