Auditing an Oracle database for security issues is very important. provides all of the information and tools that you will need Click here for details of Limited's detailed Oracle database security audit service Click here for details of Limited's Oracle Security Training Courses
Cookie Policy:We only use essential cookies on small sections of this website. For details see here.

Welcome, Guest. Please Login.
Mar 20th, 2018, 2:13am
News: If you would like to register contact the forum admin
Home | Help | Search | Members | Login
   Pete Finnigan's Oracle Security Forum
   Oracle Security
   Oracle Security
(Moderator: Pete Finnigan)
   Exploiting iAS/OHS - DB Hackers Handbook reference
« Previous topic | Next topic »
Pages: 1  Reply | Notify of replies | Send Topic | Print
   Author  Topic: Exploiting iAS/OHS - DB Hackers Handbook reference  (Read 2223 times)
Joshua Wright Newbie

View Profile | Email

Gender: male
Posts: 6
Exploiting iAS/OHS - DB Hackers Handbook reference
« on: Aug 5th, 2005, 8:31pm »
Quote | Modify

Naively I suppose, I thought that when you created a DAD for a database user account that will serve up stored procedures from the database, the specified DAD was limited to objects owned by the DAD user.
Apparently, this is not the case.  When you create a DAD for OHS/iAS and point it to the database, users who can access the DAD can run *any* procedures on the database with the privileges of the DAD user, without being limited to the objects in the DAD user's schema.
Of course, this exposes the database to the problem of PUBLIC procedures.  In the Database Hackers Handbook, this is clearly illustrated by exploiting the CTXSYS.DRILOAD.VALIDATE_STMT procedure:
http://myohs:7777/pls/mydad/ctxsys.driload.validate_stmt?sqlstmt=CREATE+ OR+REPLACE+PROCEDURE+WEBTEST+AS+BEGIN+HTP.PRINT('Hello%20ctxsys');+END;
http://myohs:7777/pls/mydad/ctxsys.driload.validate_stmt?sqlstmt=GRANT+E XECUTE+ON+WEBTEST+TO+PUBLIC;
I spewed ice coffee on my keyboard after the last URL when my web browser said "Hello ctxsys".  Because we are using ctxsys.driload.validate_stmt for something it wasn't intended to be used for, it returns an error which caused mod_plsql to return a 404 to the client.  Even though we get a 404, the database is actually executing the commands we specify.  Nasty, nasty.
By default, OHS/iAS excludes several packages from being accessible by web users including sys.*, dbms_*, utl_*, owa_util.showsource, and owa_util.cellsprint.  This is all fine and good, but wouldn't it make more sense to have an inclusive option where I can specify only a limited number of packages that are accessible?  Otherwise, this is the problem we have to deal with for securing the database from unauthenticated web attacks:

select t.owner || '.' || t.table_name ohs_accessible
from dba_tab_privs t, dba_objects o
where t.table_name = o.object_name and
t.grantee = 'PUBLIC' and t.privilege = 'EXECUTE'
and t.owner <> 'SYS' and t.table_name not like 'DBMS_%'
and t.table_name not like 'UTL_%'
and t.table_name <> 'OWA_UTIL'
and o.object_type in ('PROCEDURE', 'FUNCTION', 'PACKAGE')

This query returns 196 rows on my Linux EE installation, from the OLAPSYS, LBACSYS, WKSYS, XDB, MDSYS and ORDPLUGINS schema owners.  NOTE: This query takes a long time to execute as it joins dba_tab_privs and dba_objects.  Don't run this in the middle of the day on your production databases.
One would think that the preferrred configuration option would be to allow the DAD user to only execute objects that he owns.  Sadly, I continue to be disappointed with the configuration and flexibility of Oracle security.
IP Logged
Pages: 1  Reply | Notify of replies | Send Topic | Print

« Previous topic | Next topic »

Powered by YaBB 1 Gold - SP 1.4!
Forum software copyright 2000-2004 Yet another Bulletin Board