View Profile | Email
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:
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 188.8.131.52.0 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.