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
At 10:47 AM 17/01/2002, Jonathan A. Zdziarski wrote:
>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.
This archive was generated by hypermail 2b30 : Fri Jan 18 2002 - 12:00:44 PST