> 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.
This archive was generated by hypermail 2b30 : Fri Jan 18 2002 - 15:53:03 PST