The Oracle® Hacker's Handbook: Hacking and Defending Oracle

5.7. PL/SQL Race Conditions

PL/SQL objects can be vulnerable to time-of-check, time-of-use (TOCTOU) race conditions. In this scenario, a check is made for which a decision is taken and in the intervening time between the check and the decision being made, the condition being checked for has changed. As an example, let's say there's a PL/SQL procedure called SLUGGISH that first checks to determine whether another procedure called RACER is AUTHID DEFINER before deciding whether to execute it. If RACER is DEFINER, then the SLUGGISH procedure will execute it; otherwise, if RACER is AUTHID CURRENT_USER, SLUGGISH won't execute it because this might introduce a privilege escalation vulnerability. If during the time when the check is made and RACER is being executed, the AUTHID value is switched from DEFINER to CURRENT_USER, then SLUGGISH ends up executing a CURRENT_USER rights procedure when it was programmed not to. Let's look at a contrived example before looking at a real-world vulnerability that reflects this exact problem:

SQL> CONNECT / AS SYSDBA Connected. SQL> CREATE OR REPLACE PROCEDURE RACER AUTHID DEFINER IS 2 BEGIN 3 DBMS_OUTPUT.PUT_LINE('RUNNING RACER!!!'); 4 END; 5 / Procedure created. SQL> CREATE OR REPLACE PROCEDURE SLUGGISH IS 2 HASH VARCHAR2(200):='AAAAAAAAAA'; 3 C NUMBER; 4 AU VARCHAR2(30); 5 BEGIN 6 SELECT AUTHID INTO AU FROM SYS.DBA_PROCEDURES WHERE OBJECT_NAME = 'RACER'; 7 FOR C IN 1..500000 LOOP 8 HASH:=SYS.DBMS_OBFUSCATION_TOOLKIT.MD5(INPUT_STRING=>HASH); 9 END ...