Security Issues in 12c - Protecting Oracle Database 12c - page 94

There are other examples of Oracle's selective interpretation of *nix security. For instance, when *nix calculates
the members of the OSDBA group it adds together the results of local and networked NIS groups into a universal set
of OSDBA users. Oracle, however, only considers the first “ dba ” group entry it finds and does not concatenate multiple
sources to find the total OSDBA membership. Both of these eccentricities actually reduce access so they could be
considered as improving security, however they may also result in accidentally imposed denial of service, which is in
itself a security issue.
So, we know that 12c on *nix and Windows comes with many directories already created. The barrier to a DB user
running privileged DB commands from the OS is the lack of this execute privilege on the directory managed within the
DB. But those with ADVISOR privileges do not need directory privileges, as we have seen. There are other system privileges
that also allow exploitation of already-existing directories, and this affects *nix and Windows equally, as we shall see.

GRANT ANY OBJECT PRIVILEGE Control Bypass
There is a privilege with Oracle Database named GRANT ANY OBJECT PRIVILEGE (GAOP), which is designed for a junior
DBA or senior developer (AKA DevOp) to grant object privileges on application schema objects to other users,
thus avoiding the need to log on as the schema owner to carry out object grants. This was needed due to frequent
ownership privilege issues with PL/SQL releases, the idea being that this will enable object privileges for application
schemas to be tidied up after a release without allowing any changes to the data dictionary, i.e., SYS schema.
O7_dictionary_accessibility was brought in with 9i specifically to separate low-privileged users from the SYS
objects that control privileged access, and it applies to all the *ANY* Oracle system privileges. However, it does not
apply to GAOP.
The security model for GAOP is as follows:

1. GAOP is intended only for object privileges on non-SYS objects.

2. GAOP users cannot grant the object privilege to themselves.

In other words, GAOP is meant to be a controlled lower privilege for junior DBAs and senior developers
(AKA DevOps).
Let's have a look at what can be done with GAOP in terms of bypassing the security model above:

SQL> create user gaoptest identified by lowsec;

grant create session, create table, grant any object privilege to gaoptest;

SQL> conn GAOPTEST/lowsec
Connected.

SQL> grant all on directory OPATCH_SCRIPT_DIR to gaoptest;
grant all on directory OPATCH_SCRIPT_DIR to gaoptest
*
ERROR at line 1:
ORA-01749: you may not GRANT/REVOKE privileges to/from yourself

So control number 1 seems to work. What about control number 2? As shown below, the GAOP user cannot grant
execute on SYS objects.

SQL> grant execute on sys.dbms_sys_sql to public;
grant execute on sys.dbms_sys_sql to public
*
ERROR at line 1:
ORA-00942: table or view does not exist