[Previous entry: "Does Oracle's Database Need More Security?"] [Next entry: "Pete Finnigan speaking about Oracle 11g Security tomorrow at UKOUG DBMS SIG"]
DBMS_SQL new security features and ROWID hacking
November 2nd, 2007 by Pete
Post to del.icio.us
Post to Furl
I saw that David had made a couple of good posts to his blog in the last couple of days. The first is about the hidden parameter _dbms_sql_security_level being added to help control the use of the DBMS_SQL package and also to prevent cursor injection or cursor snarfing by adding security levels, checking effective and actual user IDs and also now generating random cursor ID's to prevent prediction. These are great improvements to this area that effectively closes out a major security hole. David's blog is titled Oracle 11g DBMS_SQL Security Changes.
David's second interesting post is titled 0wned by the lowly Oracle rowid pseudo function? and discusses the use of the ROWID function to predict information that is there but is perhaps not visible because of the use of VPD. This could undermine VPD in some circumstances but would require predictable other data to enable someone with SQL access to use the ROWID function to predict missing records. What is intersting about this post is that it uses the same method I suggested around 4 years ago but from another angle. I used it in Oracle forensics to show how a deleted record from SYS.AUD$ could be identified and also how altered records showed up in the same table when comparing the ROWID and also the timestamps.
November 4th, 2007 at 10:28 am
Gary says:
I read David's post, and had a thought about ROWID. Since he doesn't have comments, I will add it here instead.
I think the file id component of the rowid could be quite revealing in some circumstances. It may, for example, suggest if a table is time-partitioned where old records may be in a read-only tablespace.
Where ROWID analysis indicated partitioning, you'd know you were dealing with Enterprise Edition which may be useful information