RE: Fw: OT - Getting fired for database oops

From: Andre van Winssen <dreveewee_at_gmail.com>
Date: Wed, 27 May 2009 20:01:20 +0200
Message-ID: <000601c9def5$244168b0$6cc43a10$_at_com>



glogin.sql owned by root is not a panacea, it's just a simple, cheap and quick 'control' against this attack vector. But there's much more attack surface in oracle.

I have always found the presentations from red-database-security and David Litchfield's books very informative, and I assume others have too.  

What about a new thread 'OT - Getting fired for leaving database unsecured'  

From: Tanel Poder [mailto:tanel_at_poderc.com] Sent: woensdag 27 mei 2009 19:15
To: 'Andre van Winssen'
Cc: dbvision_at_iinet.net.au; oracle-l_at_freelists.org Subject: RE: Fw: OT - Getting fired for database oops  

Hi Andre,  

So there's an assumption that Oracle database or listener can write into files in Oracle home.  

When you can write to any file in Oracle home remotely, then all bets are off, making glogin.sql owned by root is not going to make the system fundamentally any more secure.  

It would protect only against that guy who knows no other way to "hack in" than tampering glogin.sql, but obviously there are many other ways to break in when you can modify files (scripts,binaries,libraries) in Oracle home.  

--
Regards,
Tanel Poder
 <http://blog.tanelpoder.com/> http://blog.tanelpoder.com 

 


  _____  


From: Andre van Winssen [mailto:dreveewee_at_gmail.com] 
Sent: 27 May 2009 16:56
To: tanel_at_poderc.com
Cc: dbvision_at_iinet.net.au; oracle-l_at_freelists.org
Subject: Re: Fw: OT - Getting fired for database oops

Hi Tanel,

 

the root ownership of ?/sqlplus/admin/glogin.sql prevents the oracle
database (& listener) process from writing into glogin.sql. What I want to
achieve is that no one remotely can tamper with glogin.sql through database
calls or listener manipulation, remotely. A dba logged on to the box can do
the things you mention for sure.

 

 

Regards,

Andre

2009/5/27 Tanel Poder <tanel_at_poderc.com>

Well the root ownership doesn't prevent you from renaming the original
sqlplus/admin directory to something else and cloning that directory back
using cp -rp, which would lose the root ownership bit.

If you set the whole tree as owned by root - then you can just clone your
whole directory to /tmp and run from there.

Also there are other tricks like using LD_PRELOAD env variable to redirect
some file opens to your custom files without the application knowing about
it.

So the setting the root ownership wouldn't be a secure solution, it would be
"security by obscurity" at most.


--
Regards,
Tanel Poder
http://blog.tanelpoder.com <http://blog.tanelpoder.com/> 


> > 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
>
>
> Good idea, and applicable to a lot of others as well.
> Thanks!
>
> --
> Cheers
> Nuno Souto
> in rainy Sydney, Australia
> dbvision_at_iinet.net.au
> --
> http://www.freelists.org/webpage/oracle-l
>
>
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l
Received on Wed May 27 2009 - 13:01:20 CDT

Original text of this message