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 like stompy.]
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.
David on 11.01.07 @ 08:55 PM GMT [link]
Inadvertent exposure at root of most breaches?
I've been analysing publicised breaches as part of my research for my upcoming talk at the Information Security Decisions conference in Chicago next Tuesday. Since January 1st 2007, the single largest contributing cause to electronic breaches is not hacking or insider malice but simply inadvertent exposure. Here are the details. Word documents and spreadsheets mistakenly left on a web server or indexed by a search engine account for 20.6% of the 276 breaches, both physical and digital, recorded up to the 23rd of October. This means that a fifth of the breach problem could be solved if companies actively and regularly hunted out such relict documents themselves. Another apsect of the review of breaches is that it seems many of the discoveries were made by well meaning members of the public who found them by accident. This indicates that the real number of breaches is considerably higher: criminals, who we know are actively seeking out such information, aren't going to inform anyone about what they find. The same is true of breaches due to compromise - the number must be higher. Whilst it's impossible to say exactly how many compromises go unnoticed it's easy to ascertain how many compromises go unnoticed for a "long time" before eventually coming to light, for example either through an audit or an investigation of fraudulent activity. That this happens indicates that not all companies have the means to be able to detect a compromise as and when it happens which lends itself to the case that compromises go unnoticed.
David on 11.01.07 @ 10:12 AM GMT [link]
