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 - 08:29:46 PST