I'm going to start reposting security notices from Bugtraq here that seem relevant to the community at large. If anybody would rather I not do this, let me know. I used to post these at http://www.arsdigita.com/bboard/q-and-a?topic%5fid=295&topic=Oracle%20administration

Date: Thu, 17 Jan 2002 13:47:16 -0500
From: Jonathan A. Zdziarski jonathan@cafejesus dot com
To: 'Dave Ahmad' da@securityfocus dot com
Cc: 'Dave McKinney' dm@securityfocus dot com, vulq@securityfocus dot
com,
     bugtraq@securityfocus dot com
Subject: RE: Breakable

Considering Oracle's client by default allows connected users to run
arbitrary shell commands, it doesn't surprise me that vulnerabilities
such as this exist.  In fact, Oracle's RDBMS has some very odd default
installation quirks:

1. The SYSTEM and SYS passwords are defaulted (manager and
change_on_install, respectively)
2. The database comes with a handfull of pre-existing "demo" accounts
with preset passwords (e.g. SCOTT/TIGER, and a few others).

To find them, do a 

SELECT USERNAME FROM DBA_USERS;

And look for any names that look like "people" then delete them using
DROP USER.
 
3. Shell commands can by default be executed by a connected sqlplus
user, without any 
particularly special privileges.  For example:

SQL> !pwd
/export/home/jonz

SQL> host
$

I would be curious to know if this shellcode is built into one of the
server-side client libraries or just sqlplus.  The fact that the
behavior of the product is kept in the database is very suspicious. 

To disable this by the way, run $ORACLE_HOME/sqlplus/admin/pupbld.sql
Then run this SQL Statement as DBA:

INSERT INTO PRODUCT_USER_PROFILE 
  VALUES('SQL*Plus','%','HOST',NULL,NULL,'DISABLED',NULL,NULL)
/

4. Auditing is turned off by default

Combining this with a very proprietary protocol, Oracle's perverted
naming service (TNS), and support for sacreligous rituals such as 
supporting plain-text passwords for linking databases together, it's
no surprise that it should be relatively easy to hack someone's Oracle
box.

I think, however, most other DBAs also see these shortcomings which is
why the average Oracle box is locked down pretty tight. Even though
the vulnerabilities exist, finding a way to get your 0's and 1's to
the average production database shouldn't be a trivial task.

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 <jonathan@cafejesus.com>
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.

The more I'm on bugtraq, the more I think just about any piece of complicated code has security issues. Security is just not taken seriously by most programmers (unfortunately, I probably have to include myself in that category). However, I haven't seen any postings of security issues with Postgres on the BUGTRAQ mailing list. If security is a concern for you (and I think it should be for most of us), I suggest joining the BUGTRAQ mailing list (in digest form, for sanity's sake).

I'll repost anything regarding Postgres, Aolserver, ACS, or OpenACS that I see on Bugtraq.

Jon,

If you want any helping testing the bugs you have found I will be happy to
help.  Security is one of my primary interests in OpenACS.

If you're running AOLserver and PG on the same machine, chroot AOLserver and tell PG to only accept local host connections you should be in pretty good shape.  If they can't hack OpenACS into submitted arbitrarily long queries then you shouldn't have to worry too much about buffer overruns in PG, at least.

Let's face it, if they get in and root you and want to ruin your day "rm", not "psql" will be the tool of choice.  Still ... if they've not rooted you but just got into a user account via crack or the like, you'd be safer if psql were removed from your system altogether.  You can do that once you've installed all your packages from the OpenACS4 APM.


The client library for PG does support encrypted communication.  But opening up your db server to the net is asking for trouble, since you then would be vulnerable to any buffer overrun (or other) problems in the PG communications code.

Chroot - is it worth it?

If you run a box that just serves the purpose of running the
Community System an attacker is probably more interested in all the
peoples data - the profiles, the internal addresses, etc. Access to
it is not restricted by the chroot jail. Maybe good file permissions
on file system level offers enough protection.

Chroot or not, the question is how fast the intrusion is found.

I think chroot is overkill for most situations.

Again, if you understand security your box will be hardened. If you don't chroot won't do anything as I can break your chroot in about 1 minute if I want to.

Of bigger security interest is the fact that AOLServer broke recently and now does not honor the -g flag. This implys that you have to run your web services with world read permissions. A big no, no. Why the hell does the world need to read any of your stuff.

Don't you need to get root privileges to break out of chroot?

Yes you need to get root, but I said if you don't understand security....

I had this on my harddrive, don't remember the source.

The quick and dirty of it is that if the process in the chroot jail is a
root process, it'll virtually always be possible to break out of the
jail. If the daemon in question runs with reduced privilleges, the
usefulness of the chroot jail increases dramatically.

To give an example, root is allowed to mknod a device in /dev. What's to
stop him from creating a device node for the local harddisk and doing
all sorts of nasty things (from overwriting, to mounting, checking out
interesting files and then using that to find an easier way in).

It's just another hurdle for a root process. It can truly become a jail
when the daemon runs as non-root, but that isn't always an option...

That was my understanding of chroot'ing. But as far as I understand, Aolserver can be set up as a chroot that's fairly secure, because it doesn't need access to many other programs and libraries.

Jon, do you think that our Aolserver install guide should direct users to install it in a chroot environment by default? It doesn't seem like it'd be much harder to do, and there does seem to be a security gain.

What do the rest of you think? Am I suggesting something that's not really worth doing?

Although I lack the security experience to beef up the install guide for chrooting and these kernel patches, I'd be happy to

1) be a guinea pig for any install guides which include improved security sections. I'll follow the directions step by step and give feedback.

2) open this server up to other to try and hack into, so we could test the security of a default OpenACS installation.

This probably is a little cart ahead of the horse, because the install guide hasn't been released yet for OACS 4. But I'd rather put in the time now than clean up the mess after getting hacked in the future.

I'm just getting back into the community here, so hopefully I'm not stepping on anyone's toes here.

It is still a major security problem when AOLserver doesn't honor the -g flag and requires you to run all your directories world readable.

Rule 1 - If you don't need to see it, I probably won't let you.

According to the AOLserver changelog this was fixed 3-14-2001 happy pi day!

FYI, above, when I was saying I'd heard that Oracle 9i is unstable,
the Oracle version in question was 9.0.1.0.0.  Presumably the next
point revision (9.0.3.0.0) will fix things when it's released - c.
end of March, I think.