Alex also refers to a previous post but doesn't link to it. I found the previous post titled http://www.pythian.com/blogs/352/calling-definer-rights-procedure-as-sysdba-security-hole - (broken link) Calling Definer-Rights Procedure as SYSDBA - Security Hole?. There seems to be some slight issues with the later post (both are quite old posts), the first is that the end game of the post is to grant SYSDBA to U1. The end connection shows a connection as sysdba as U1 but the previous code in the procedure give_sysdba grants the DBA role to U1 not the SYSDBA privilege. The connection in SQL*Plus AS SYSDBA would work in some cases without the grant taking place (i.e. the OS does the authentication) like so:
SQL*Plus: Release 11.1.0.6.0 - Production on Wed Jun 4 18:02:42 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Enter user-name: system/oracle1
Connected to:
Personal Oracle Database 11g Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> connect system/manager as sysdba
Connected.
SQL> select * from v$pwfile_users;
USERNAME SYSDB SYSOP SYSAS
------------------------------ ----- ----- -----
SYS TRUE TRUE FALSE
SCOTT FALSE TRUE FALSE
SQL> sho user
USER is "SYS"
SQL>
The code in the article may or may not have granted the DBA role to U1, there is no check to test this. Although the earlier article mentions that invoker rights/define rights differences depend on compile time and run time system privileges, roles and object access privileges the second doesn't cover it and the first not in enough detail. The basic difference is that definer rights procedures are resolved at compile time and no privilege gained through a role is available. Of course the privileges and access rights used at compile time are those assigned to the owner (and subtely to PUBLIC; any system or object privilege granted to PUBLIC is as good as a direct privilege granted to the user). In the case of Invoker rights the owner must have access to referenced objects to compile but the resolution of privileges is done at run time and roles are available (where they are not in definer rights) as granted to the invoker. This can lead to strange circumstances where code can fail for one user and not another due to lacking grants. This is one of the strenghts and powers of invoker rights code and why they need to be designed correctly.
The second issue I have with Alex's post is that whilst privilege escalation can be attained/obtained it is actually a trojan in essence that is used to gain the privileges. The fact that this issue relates to SYSDBA connections is immaterial as we can arange for any privileged user to run code for a lesser user in any similar circumstance using invoker rights or other methods. A method I suggested in a paper I wrote in 2001 when working at Pentest called Exploiting and protecting Oracle (search with CTRL-F for "identified by" to locate it) shows how a script from the $ORACLE_HOME/rdbms/admin directory could be modified to replace a statement
1alter session set sql_trace true:
to
1alter user sys identified by sys:The result is similar in nature and is also a trojan. Alex's paper is interesting and there is an anomoly that should be looked into an understood but there but there are also some inconsistencies in the paper as above. Thanks for the pointer Paul!
