Forum OpenACS Q&A: Bugtraq: Oracle security

Request notifications

Collapse
Posted by Jade Rubick on
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.


Collapse
Posted by Jade Rubick on
Date: Fri, 18 Jan 2002 11:30:43 -0800
From: "bugtraq@t-swat.com" <bugtraq@t-swat.com>
To: Jonathan A. Zdziarski <jonathan@cafejesus.com>
Cc: bugtraq@securityfocus.com
Subject: RE: Breakable

Jonathan-

Just a couple of points:

To clarify, the "host" command is client-based.  For instance, when I 
SQLPLUS into a remote database, and I use the host command, it breaks me 
out into the directory of the local machine, not the server you're 
connected into.  Same goes for any local shell commands.  I don't see that 
as being a security risk.

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.

As to the other accounts (SCOTT/TIGER, etc.), that is a good point, but 
covered quite clearly in the "how to secure your database" documentation.


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 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!)


$0.02


...jeff

Collapse
Posted by Jade Rubick on
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.

Collapse
Posted by MaineBob OConnor on
Does Postgresql have similar security issues?

-Bob

Collapse
Posted by Jade Rubick on
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.

Collapse
Posted by Jon Griffin on
There are potentially several ACS security flaws, but I won't post them until I finish testing.And these aren't root exploits, just minor embarresment type of things

AOLserver is relativly secure, but I think there may be several ways to smash the stack (this was based on a really quick look at the source albeit 3.2 era).

Also, all this code needs to be checked for buffer overflows, especially tcl.

The biggest problem is multiple failure points (potentially). You have

  • the OS (probably the most audited part).
  • Aolserver (I haven't seen any audits)
  • By extension, tcl/tk ( again I haven't seen any audits, but it is probably more checked over than aolserver)
  • Postgres (I haven't looked at that at all)
  • Oracle (definitly has several exploits of varying degrees)
  • OpenACS (this was somewhat audited as ACS 3.something when a HUGE exploit was found by Petru and fixed later with new mechanisms making thier way into the 4.x code. i.e. bind vars, db api changes etc.)
  • Of all the above I feel most confident ( in order) of:
    • OS security (at least thier is a lot written on it and plenty of patches)
    • OpenACS
    • TCL
    • Aolserver
    • Oracle
    • As I haven't looked at PG source I can't say much about it.

Collapse
7: Postgres security (response to 1)
Posted by David Walker on
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.

Collapse
8: OpenACS security (response to 1)
Posted by Jade Rubick on
I think once our install guides are all out and the documentation is in place, we should go through it with a mind for security. Our default install should be as locked down as possible, IMO.

For example: I think Aolserver should probably be installed in a chrooted environment, and why don't we just go ahead and do this in the install guide?

I'm willing to help out with this once the docs are released and we go beta.

And then let's try and hack our own sites. Once I get my OpenACS site up, I'll volunteer to be a target.

Collapse
Posted by Don Baccus on
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.

Collapse
10: Oracle 9i is unstable (response to 1)
Posted by Andrew Piskorski on
I don't know any details, but what I've heard from folks actually
using Oracle 9i internally at Oracle, is that it's unreliable and
unstable, and at least for now, they'd switch back to
8.1.7 in an instant if the choice was up to them.
Collapse
Posted by Jens Strupp on
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.

Collapse
Posted by David Walker on
The attacker may be after your community system or he may just be after
another zombie or a place to hide some files (games or top secret military
documents or whatever).  You want to prevent the attacker from accessing
your system in any unauthorized manner.

Also he could follow one hole into the system, say through openacs, elevates
his access using an exploit, possibly against a binary we don't have in the
chroot system, and then as all powerful root has the power to do whatever he
wants against our community system.

Collapse
Posted by Jon Griffin on
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.

Collapse
Posted by Jade Rubick on
Jon, is it general knowledge how to break out of chroot? Does it protect you to some degree from less sophisticated hackers?

What is the general way you go about doing breaking out of chroot? I'm curious.

Collapse
Posted by David Walker on
Don't you need to get root privileges to break out of chroot?
Collapse
Posted by Tom Jackson on

I don't think a process can get out of the new root. According to Stevens' _Advanced Programming in the Unix Environment_, pg 692

"chroot can be executed only by the superuser, and once you change the root of a process, it (and all its decendants) can never get back to the original root."

Collapse
Posted by Jon Griffin on
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...

Collapse
Posted by Rodger Donaldson on
How easy is it to break chroot?  Google on it.  You'll find source and binaries for Solaris and Linux.

It requires you to get root in the chroot() environment; if your chroot() environment is running a minimal set of tools and libraries  then chroot() is a useful addition to security, protecting the rest of the system from a poorly written daemon - even if the user breaks into the chroot jail, they probably won't be able to elevate privs to the level needed to make breaking the jail easy.

OTOH, if the daemon requires a cast of thousands of libraries and executables (think Oracle, Vignette, etc) and you can't link statically, then all those support files provide ample opportunities for local root exploits, which can then be used to trivially break the chroot() environment.

Finally, think about what you're trying to protect against.  If the stuff the attacker values is available in the chroot() jail, what did you win?

Collapse
Posted by Jade Rubick on
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?

Collapse
Posted by Jon Griffin on
I definitly think it should be chroot, and preferably a section (at least for linux) on adding the grsecurity patches to your kernel to make defeating a chroot even harder.

This is yet another reason to not use RH6.2 as a standard install. Also, I am working on some iptables rules which will help as well.

Collapse
Posted by Jade Rubick on
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.

Collapse
Posted by Don Baccus on
The AOLserver site recommends setting up a chroot environment and tells you how to do so.  AOLserver only runs as root long enough to grab port 80 and then drops to your "-u" user.  So you need to elevate to root to break out AFAIK.

Also AFAIK no one's managed to root aol.com or digitalcity.com, so it's probably worth paying at least some attention to their advice.  I'm sure they've been targets of many attempts (and maybe they've been rooted and  neither they or we don't know it!  aol.com might be the mother lode of warez distribution!)

As far as Oracle goes ... you talk to Oracle via the ora.c and the Oracle client library to the listener, which is running elsewhere (another process, another machine, whatever).

Ditto PG.  The client library is linked with the driver and AOLserver, but it talks to the postmaster daemon (usually via localhost when things run on one machine, at least if you're smart).

So not all that much needs to go into your chroot()'d process.

When all is said and done the non-AOLserver stuff you forget to turn off is most likely to get you.  I got rooted two weeks ago because I never got around to updating ssh on a server of mine (bad bad bad).

The good news is most of the script kiddies are just looking for someplace to dump pirated software in order to distribute it using your bandwidth.  I've had several friends get rooted over the years (including photo.net, tee hee!) and the machines have never been taken down or harmed.  Instead they start up ftp and you find your machine pegged running as many ftp downloads as it can handle without running out of swap space.  Your system gets *very* slow.

I caught these guys before that happened to this particular server (two days after they broke in) and I'm pretty sure that's what they were up to.  They didn't harm my site, database, etc.  They installed a rootkit that included versions of ps and top that hid all but a handful of processes, and a hacked ssh that apparently lets you have root access with a known password (not roots real password).

When I discovered that they didn't do anything else because I shut it down and upgraded to a much newer set of software from the ground up before plugging in the internet hose again.

Of course, if they had gotten started my bandwidth bill could've been a major embarrassment ...

Collapse
Posted by Jon Griffin on
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.

Collapse
Posted by Jens Strupp on

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.

Hi John,
as the "-g" thing is a very import one I wonder what's the problem for the AOLServer folks to fix this? Is this an open bug?

Collapse
Posted by carl garland on
According to the AOLserver changelog this was fixed 3-14-2001 happy pi day!
Collapse
Posted by Jon Griffin on
Well it wasn't.

I have a 3.4.2 tarball that I just downloaded from aol's site and using -g mygroup doesn't work.

All files/directories are owned by nsadmin.mygroup. If you do a chmod -R o-rxw, You will get no pages and a nice permission denied in your logs.

I took a running earlier ad-12 (I believe) that had ALL world permissions stripped and when the aolserver was upgraded it stopped.

Collapse
Posted by Andrew Piskorski on
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.