Re: Fw: OT - Getting fired for database oops

From: Nuno Souto <>
Date: Tue, 26 May 2009 20:36:44 +1000
Message-ID: <>

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?

Nuno Souto
in sunny Sydney, Australia

Received on Tue May 26 2009 - 05:36:44 CDT

Original text of this message