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

[oracle@orlin ~]$ sha1sum /home/oracle/app/oracle2/product/12.1.0/dbhome_2/sqlplus/admin/glogin.sql
fc49f17fe2a435744103e91e39210507851def10
Another method of “phisyshing” is enabled through the CREATE PUBLIC SYNONYM privilege, which also implicitly
infers the DROP PUBLIC SYNONYM ability, as a user can do a CREATE OR REPLACE public synonym statement. If a user
with CREATE PUBLIC SYNONYM were to change a synonym that SYS uses and redirect it to their own object they will
be able to use that SYS privilege in their own code to grant themselves DBA. To address this problem in 12c, Oracle
has designed the new INHERIT privilege. INHERIT is a object privilege that an object owner is granted automatically
and enables their object to inherit the privileges of invoking users. The key is that other users can revoke that specific
INHERIT privilege from the object owner. By default the INHERIT privilege is granted to public on every object creation,
hence the 10,000 increase in public privileges, and so current_user behavior for inheritance of invoker privileges is
still in place by default (i.e., still vulnerable). Given that monitoring and controlling public is half of the security battle,
I think that the current INHERIT privilege's implementation can be improved upon. We need to move away from using
PUBLIC in the DB.
Client-side scripts like glogin.sql and cloud control web access represent additional threats to DBA security
from their client's OS, especially when forced to log in as SYS remotely. Cloud control puts the DB privilege into the
web browser so a whole gammit of web browser security issues are opened up regarding cookie security, with HTML
email phishing links representing a potential threat to DB security.
Another issue with privilege escalation similar in concept to the GAOP self-granting issue is the ability of users to
bypass VPD. To bypass VPD the 'EXEMPT ACCESS POLICY' privilege is required.
SQL> select * from SYSTEM_PRIVILEGE_MAP where name ='EXEMPT ACCESS POLICY';
PRIVILEGE NAME PROPERTY
---------- ---------------------------------------- ----------
-235 EXEMPT ACCESS POLICY 0
SQL> select grantee from dba_sys_privs where privilege ='EXEMPT ACCESS POLICY';
no rows selected
SQL> sho user
USER is "SYS"
No users are granted this privilege, so does that mean no one can bypass VPD? Not really, as users can simply
grant it to themselves as shown here:
SQL> create user vpdtest identified by lowsec;
User created.
SQL> grant create session, em_express_all to vpdtest;
Grant succeeded.
sqlplus vpdtest/lowsec@192.168.1.3/pdborcl
SQL*Plus: Release 12.1.0.1.0 Production on Mon Aug 12 21:31:02 2013