Re: Fw: OT - Getting fired for database oops

the problem with oracle software is its vulnerabilities which allow privilege elevation to the level where one would be able to use database calls to write to glogin.sql. The further behind with CPU patching the more vulnerabilities that are available for exploiting. lots of websites publish exploit code targeting at oracle.

my favourite would be a preventive control, one which simply does not allow oracle user to change glogin.sql just like that. A drastic but effective implementation is to chown root glogin.sql and make it read only by oracle user (and the world). This would be acceptable because you do not update this file often, only sqlplus reads it every time when called. Checking md5 hashes or date changed+size of critical files on the other hand is only a detective control still requiring someone to action.

Regards,
Andre

2009/5/26 Nuno Souto <dbvision_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-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l