Forum OpenACS Q&A: Response to Bugtraq: Oracle security

Bugtraq just happens to be having a thread on this right now. Usually it's quite quiet:

Date: Fri, 18 Jan 2002 15:21:31 -0500
From: Jonathan A. Zdziarski 
To: bugtraq@t-swat.com
Cc: bugtraq@securityfocus.com
Subject: RE: Breakable

> To clarify, the "host" command is client-based. 

I sent this email to someone else who already asked me to clarify:

One of the problems with this is that sqlplus assumes that the user must
have had a shell use sqlplus; this is not always the case.  Automated
scripts using sqlplus can be potentially vulerable as well as any web
applications (I've seen a few) that use sqlplus in some part of code
where the OCI isn't used, or the abstraction layer (e.g. DBI or what
have you) doesn't provide the right functionality or speed.  Agreed -
some if not most of this is misuse of sqlplus in the first place, but
there are legitimate circumstances as well.  Users may have been given
permissions to run svrmgrl as the oracle user (under sudo) so they can
connect internal without having to know the privileged passwords.  It's
just plain bad practice IMHO for any program to allow the user to spawn
a shell, as it limits the number of secure uses program has.  Take a
look at vi - I don't want to begin to count the number of people who are
giving privileges to some people to edit certain files as root under vi
not realizing they're giving them shell access (not to mention access to
read/write any other file).  Hence, the existence of 'elvis'.

The bigger issue to me, as I touched on, is this...why - if it's
supposed to affect the environment of the local machine rather than the
oracle server - does sqlplus rely on data kept in the Oracle server to
dictate whether the user should be allowed to get a shell on the machine
they're connecting from?  At the very least, it's an obfuscated
programming philosphy but at its worst, there may be some privileged
access functions that would warrant having to have a data dictionary for
this information existing in the Oracle server (rather than a client
configuration file, for example).

I did a little snooping around the Oracle binaries and libraries and
found that there is shell code in a lot of different places, not just
sqlplus:

libcommon8.a
libsqlplus.a (SQL*Plus's Library)
svrmgrl (Another client)
osfind
osagent
rman
osh

I'm not entirely sure what libcommon8 is linked to, but I can't imagine
needing /bin/sh in these binaries.  A binary shouldn't be calling other
binaries, and even if it needed to for some reason (ctxhx, or what have
you) it can do so without calling /bin/sh, so I'm curious if any of
these (other than the obvious ones) are related to the host command, or
at least pose some other security risks.

Anyway, my point is being able to get a shell from programs like this
isn't exactly the greatest idea Oracle had.  The fact that it's not
noted except in a few obscure places, and allow one to control this from
the database rather than the client also suggests to me that Oracle's
not very concerned with security.

> As to the System and Sys accounts having defaulted passwords, 
> the last time 
> I installed 9i it made me change them at the time of install. 
>  The accounts 
> were also locked, and not accessible, until I went in as INTERNAL and 
> modified them.  I find this to be somewhat acceptable behaviour.

I'm glad they changed it in 9i.  I haven't used 9i yet, so I hadn't
noticed. From the people I've talked to about 9i, most seem to still
prefer 8i at this point.  Most of the Oracle community I've spoken with
about 9i refuses to use it until they fix some bugs.  I don't know the
specifics but I haven't found too many people who are actually using 9i
yet.  Like I said I'm glad they fixed it though.

> I think it comes right down to the fact that Oracle is an extremely 
> complex, yet powerful database, and anyone that is going to 
> do any kind of 
> professional development with it or use it in a "public" 
> environment (as in 
> exposed to the world) should understand how to use auditing, 
> and lock out 
> or remove unwanted accounts, and how to architect 
> applications, systems, 
> and security appropriately.  When you currently perform a 
> default install 
> of Oracle, it is in a "relatively" secure, yet "easy" to use 
> config that 
> allows people to explore and learn about it without having to 
> figure out 
> how to unlock it first.

I agree with you, it's a complex tool that requires the right amount of
talent.  Unfortunately a lot of companies today that are using Oracle
are pushing it on their mid-level sysadmins rather than pay the extra
[high] salary for a DBA.  Oracle could take a more secure approach to
their initial database install - There's no real good reason to have
demo accounts set up, for example, or automatically assume that anyone
using sqlplus can safely have a shell.  My personal feelings on this is
that the demo accounts have a little something to do with Oracle's
licensing agreement giving them auditing privileges, but I'm sure that's
not the only reason they're there.  

If Oracle were to put the literature in their secure server
documentation into their installation guide, it would also help
communicate the need for some basic hardening.  The new "user-friendly"
installations in 8i and 9i are certainly starting to give the user more
of a sense of "out-of-the-box" than they should have with something like
Oracle.

> I think that anyone who is not familiar with Oracle and yet 
> implements it 
> in a vulnerable place without taking the appropriate cautions 
> is almost 
> deserving to be hacked.  (This ain't your fathers Access database!)

A snip right from the front page of their website:

[snip]

Oracle9i Database easier to manage than IBM DB2 
Independent study finds DBAs work 56% faster with Oracle9i Database
  . Can't break it--Reduce downtime with Oracle9i Database.
  . Real Application Clusters made easy: Oracle software pre-installed
on Compaq, Dell, or Sun servers.

[snip]

Also from the top of their page on security:

[snip]
Oracle9i delivers the security software you need to: 

Secure data across the network and within the database 
Protect sensitive data with selective database encryption 
Restrict data access to authorized users only 
Quickly spot and respond to data misuse 
Only Oracle provides concrete security assurance, having successfully
completed 14 independent security evaluatons worldwide.

[snip]

It seems to me that Oracle is putting a significant emphasis on
security, but failing to mention that it takes high-salaried DBAs who
know what they're doing to be able to effectively achieve the level of
security they're emphasizing.  (Although I admit they trapse over
mentioning the word DBA on this ad).  To me, this is the typical
used-car salesman pitch with fine print.  Advertising that it's easy to
use, and that it has extensive security features are somewhat
misleading, as neither of those two have anything to do with eachother
when it comes to Oracle.  It's starting to "feel" like a Microsoft
Access ad.