Database Reference
In-Depth Information
Given the new definer's role feature it should be possible for developers to avoid PUBLIC altogether. By
discounting the mass of PUBLIC INHERIT privileges a job can be set up to simply check that the result of the above
query stays the same. This will alert you to GAOP privilege escalation as described in Chapter 10, and also act as a
nice little change management control. The state-check should be done after the classic PUBLIC revokes have already
been done on
utl_file
and so forth.
Achieving simplicity by reducing the attack surface is the aim of dropping the unused directories in 12.1.0.1.0 so
that privilege escalation cannot occur through those directories, either via the
ADVISOR
privilege or GAOP. Following
are the directories to drop:
Drop directory OPATCH_LOG_DIR
Drop directory OPATCH_SCRIPT_DIR
Drop directory ORACLE_HOME
Drop directory XSDDIR
Of course it is prudent to cover one's self when dropping directories by raising an SR support ticket to rubber
stamp the act with Oracle Support. In order to check that changes do not affect the working of a system, it is also a
good idea to set up a logging rule that will capture interaction with the chosen objects to be removed, to ensure they
are not used beforehand.
In the case of the already present directory and external table security issue in 12.1, we should set up an audit
rule on those external tables to check that nothing uses them. Do that as follows:
SQL> Audit all on OPATCH_XML_INV;
Audit succeeded.
To stop users writing to the OS, we should check who has the ADVISOR privilege. These are the normal holders of
that privilege:
SQL> select grantee from dba_sys_privs where privilege='ADVISOR';
GRANTEE
-----------------------------------------------------------------
SYS
OEM_MONITOR
EM_EXPRESS_ALL
DBA
OEM_ADVISOR
Holders of that privilege could write
glogin.sql
and
login.sql
scripts to multiple directories with unauthorised
commands in them, to be ran by unsuspecting DBAs. We can use the
locate c
ommand on Linux to find spurious
login.sql
files. For example:
root@orlin $ updatedb
root@orlin $ locate login.sql
/home/oracle/app/oracle2/admin/orcl3/dpdump/login.sql
/home/oracle/app/oracle2/product/12.1.0/dbhome_2/apex/core/generic_login.sql
/home/oracle/app/oracle2/product/12.1.0/dbhome_2/apex/core/wwv_flow_login.sql
/home/oracle/app/oracle2/product/12.1.0/dbhome_2/sqlplus/admin/glogin.sql
/usr/lib/oracle/11.1/client64/lib/glogin.sql
