ora-29471:Oracle 11g DBMS_SQL Security Changes

 "Oracle 11g DBMS_SQL Security Changes"

Late last year I published a paper describing a new class of vulnerability in Oracle I called"cursor snarfing". This involves causing an exception to occur in a PL/SQL package that uses DBMS_SQL and cursors but fails to close them in exception handling code. An attacker can then steal or snarf this cursor and potentially use it to compromise the security of the server outside of any application logic. Then in February this year I published a paper on"Cursor Injection" that showed how an attacker with only CREATE SESSION privileges could fully exploit any SQL injection flaw to execute entirely arbitrary DDL SQL - for example GRANT DBA TO PUBLIC. This is achieved by creating a cursor with DBMS_SQL and parsing the DDL statement. The cursor is then injected into the attack vector using the DBMS_SQL.EXECUTE function where it is executed with the privileges of the definer of the vulnerable code.

For Oracle 11g, Oracle has introduced some security changes to the DBMS_SQL package to help mitigate the risk of the problems presented in the two papers.

Firstly, cursors (which are referenced just by a number) are no longer created predictably. In 10gr2 and earlier the 1st cursor had a number of 1, the 2nd had a number of 2 and so on. When closed the number would be free to be used again. The point is it was trivial to guess or brute force the number and a cursor's value would typically be between 1 and 300 . 11g no longer generates cursor numbers so predictably - indeed they seem much more random:

1240272433
313122561
2112412728

These are three example cursors created via DBMS_SQL.OPEN_CURSOR. I haven't yet looked to see just how random these numbers and they may or may not be predictable [*] but regardless this is an excellent step forward.

The next improvement has been to shut off access to DBMS_SQL if someone passes an invalid cursor to one of the DBMS_SQL functions or procedures. This is also true of DBMS_SYS_SQL. Thus if I try to inject

dbms_sql.execute(1234567)

and 1234567 is invalid then I'll get an access denied:

ORA-29471: DBMS_SQL access denied
ORA-06512: at "SYS.DBMS_SYS_SQL", line 1528
ORA-06512: at line 1

The only way I can get access to DBMS_SQL again is by logging off and logging back on. The only function that can be called multiple times with impunity is the OPEN_CURSOR function. * Therein potentially lies a weakness. If the random number generator used when a cursor is created is weak then the ability of an attacker to quickly generate a large of cursors and get their values means that an attack could take place by prediciting the next value to be generated. A lot of good work has been done in the area of predicting PRNGs. [See my colleague Chris Anley's paper and Michal Zalewski's work likestompy.]

Further, a hidden parameter "_dbms_sql_security_level", which is turned on by default affects the OPEN_CURSOR function. A new addition to DBMS_SQL in 11g is the ability to specifiy a security level when opening the cursor:

curs = dbms_sql.open_cursor(level);

level can be 0, 1, or 2. 0 turns off security checking in DBMS_SQL but can only be specified if "_dbms_sql_security_level" is turned off. Opening the cursor with a level of 1 requires the executing/binding and parsing user IDs to be the same. Level 2 is more strict and requires id and roles are the same for all operations like binds, describes, executes, fetches etc.

A third change to DBMS_SQL is checking the user ID executing the query and the user ID of the person that parsed the query. If the two don't match an error is generated:

ORA-29470: Effective userid or roles are not the same as when cursor was parsed
ORA-06512: at "SYS.DBMS_SQL", line 1501
ORA-06512: at "SYS.DBMS_SQL", line 1506

Thus, if someone parses their attack query and then injects into the vector their SQL will not be executed.

As is, these three changes put a stop to the abuse that DBMS_SQL was susceptible to. Good work, Oracle. These changes show that someone over there's paid these problems serious attention.