Re: Fw: OT - Getting fired for database oops
- From: Frits Hoogland <frits.hoogland@xxxxxxxxx>
- To: dreveewee@xxxxxxxxx
- Date: Wed, 27 May 2009 21:37:09 +0200
But even if it's done in the most perfect way, if not *all* components
involved (network, operating system, database, applications) are tightly
secured, a mistake in another layer could easily lead to compromise. Also,
in the cases I encountered, the security auditor has no/little technical
knowledge, which means that with some suggesting and some omitting of
details it's quite easy to pass the audit.
It reminds me of a saying in the network world about firewalls: 'the harder
on the outside, the softer on the inside'. At least until two years ago, the
default operator interface of networking components like switches and
routers, but disturbingly even firewalls is telnet. SSH (encrypted) access
is an option...
frits
On Wed, May 27, 2009 at 8:01 PM, Andre van Winssen <dreveewee@xxxxxxxxx>wrote:
> 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@xxxxxxxxxx]
> *Sent:* woensdag 27 mei 2009 19:15
> *To:* 'Andre van Winssen'
> *Cc:* dbvision@xxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
> *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
>
>
> ------------------------------
>
> *From:* Andre van Winssen [mailto:dreveewee@xxxxxxxxx]
> *Sent:* 27 May 2009 16:56
> *To:* tanel@xxxxxxxxxx
> *Cc:* dbvision@xxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
> *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@xxxxxxxxxx>
>
> 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
>
> > > 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@xxxxxxxxxxxx
> > --
> > //www.freelists.org/webpage/oracle-l
> >
> >
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
>
Other related posts:
