RE: Fw: OT - Getting fired for database oops
- From: "Andre van Winssen" <dreveewee@xxxxxxxxx>
- To: "'Jared Still'" <jkstill@xxxxxxxxx>
- Date: Tue, 26 May 2009 07:58:42 +0200
>> In the case of glogin.sql, .. as anyone . can already logon as sysdba
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.
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.
Regards,
Andre
From: Jared Still [mailto:jkstill@xxxxxxxxx]
Sent: maandag 25 mei 2009 17:46
To: dreveewee@xxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Fw: OT - Getting fired for database oops
On Sat, May 23, 2009 at 10:42 AM, Andre van Winssen <
<mailto:dreveewee@xxxxxxxxx> dreveewee@xxxxxxxxx> wrote:
And protect/audit your login.sql and glogin.sql (on the oracle server side
in particular) otherwise some bad person might inject "grant dba to public"
into it without you noticing it :-)
I wonder how much of a threat that actually is?
In the case of glogin.sql, probably not much, as anyone with the ability
to modify that file can already logon as sysdba.
login.sql could be vulnerable however, if you are lax with your home
security settings. (check your umask)
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
Other related posts:
