Forum OpenACS Q&A: Bugtraq: Oracle security
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.
Date: Fri, 18 Jan 2002 11:30:43 -0800 From: "email@example.com"
To: Jonathan A. Zdziarski Cc: firstname.lastname@example.org 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
Date: Fri, 18 Jan 2002 15:21:31 -0500 From: Jonathan A. Zdziarski
To: email@example.com Cc: firstname.lastname@example.org 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.
I'll repost anything regarding Postgres, Aolserver, ACS, or OpenACS that I see on Bugtraq.
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.)
- OS security (at least thier is a lot written on it and plenty of patches)
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.
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.
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.
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.
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.
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.
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.
What is the general way you go about doing breaking out of chroot? I'm curious.
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."
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...
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?
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?
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.
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.
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 ...
Rule 1 - If you don't need to see it, I probably won't let you.
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.
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?
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.
the Oracle version in question was 184.108.40.206.0. Presumably the next
point revision (220.127.116.11.0) will fix things when it's released - c.
end of March, I think.