David Litchfield's Weblog

Home
Archives
NGSSoftware
DatabaseSecurity.com


Greymatter Forums

October 2007
SMTWTFS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

Valid XHTML 1.0!

Powered By Greymatter

RSS 1.0 FEED
RSS 2.0 FEED
Atom 0.3 FEED
Powered by gm-rss 2.0.1
Home » Archives » October 2007 » 0wned by the lowly Oracle rowid pseudo function?

[Previous entry: "Memory-resident backdoors in Oracle / Deepsec conference."] [Next entry: "Inadvertent exposure at root of most breaches?"]

10/31/2007: "0wned by the lowly Oracle rowid pseudo function?"


SQL> select rowid,x from test;
ROWID X
------------------ --------------------
AAAM9ZAABAAAO6CAAA Test1
AAAM9ZAABAAAO6CAAB Test2
AAAM9ZAABAAAO6CAAC Test3
AAAM9ZAABAAAO6CAAE Test5

Notice anything odd? That's right there's no "Test4". Notice anything else? Looking at the last letter of the rowid we see they go from A to B to C to E. There's no D. Now, if the "test" table were protected by a virtual private database we could assume that there *is* a "Test4" but we just can't see it because the VPD isn't letting us. (Or it could mean that the "Test4" row has been deleted but forget that for the moment...assume the row is there.) In other words we can infer something about data we're not allowed to see. This can lead to a security risk. In all fairness this probably affects 0 people out there but it's interesting none the less and when designing database applications, especially those that protect critically sensitive information, we need to be wary of things like this. Even the lowly rowid function can punch a hole through the best laid security plans.