[Previous entry: "Hacking Oracle made easy"] [Next entry: "A book, a database scanner and a magazine column and a few bugs"]
Bypassing VPD through inference
August 19th, 2009 by Pete
Post to del.icio.us
Post to Furl
Slavik emailed me today to let me know of a guest posting by Roy Fox on his blog with a post titled "Side-Channel Information Leakage using VPD" that describes a way to infer whether VPD is enabled on a particular table.
This is an interesting article with good points but I have some comments. These are not aimed at Roy but at Arups code that he uses as an example - I should say that this is also not knocking Arup as his code is used in a different context here!
Roy has just picked a simple implementation of VPD agains a table by Arup in an article from the Oracle magazine, the code is also very similar to that in his book "Oracle Privacy Security Auditing" so its a bit out of date in terms of its written 6 years ago BUT the code still works. Roy has found a 6.09 time factor gap between a table with or without VPD. Also interestingly he also points out a 3.26 factor time gap between a table that doesnt exist and a table where the user has no rights on it.
So to my comments; as is always the case an Oracle database and its applications are very specific to any particular setup and instance. i.e. load, size, code written, versions, platforms and many more factors. In other words the 6.09 is not locked in stone its particular to Roys unloaded system and also to Arups code. This is not to say that with a factor like this its not a problem, it likely is in most cases. I have not got time to do some tests but my first test would be to do a similar test where the code is more realistic. The code presented by Arup is fine but my experience of VPD in real life systems is that policies are usually split across tables, contexts are almost exclusively used, dynamic policies are avoided like the plague, policy groups are used, in other words performance is king. I would be interested to see what the difference is based on resolving a context which sits in RAM and doesnt need any SQL rather than Arups code which uses SQL in a loop. Also Arups code / example is more realistic in a scenario where OLS would be used where individual records to be protected (or rather opened for view) are sought via controls. This really looks more like OLS rather than a more traditional VPD scenario where records are grouped on some factor.
Also not related to Roys work is the fact that Arups code has another hidden flaw. The code relies on a central security lookup table. This is not protected by VPD and indeed if you try to protect it by VPD you will find issues that make doing so very difficult whilst still allowing access to the data. The scenario is this if "FRED" is not allowed to see the lookup to see what records he can see then he cannot see them! - there are workarounds that allow VPD to be used but they have flaws. the problem in this scenario presented by Arup is that the VPD can simply be bypassed by modifying the access_policy table. We dont know the security settings on this table as they are not shown but they are not likely to be be VPD as this doesnt work.
The bottom line though is that people will copy Arups code into production as there are not that many VPD examples out there. I have seen production databases that use Tom's code for example!
So yes great idea Roy, I would like to see some more general examples on other types/implementations of VPD to compare the results.
I have written on VPD many times in the past; there are two presentations and two articles available on my Oracle security white papers page.
